I've come across interop issues with various SIP UAs and now a commercial SBC (Cisco ASR 1000 Series SBC SP Edition) and SIPXecs, which stems from the SIPXecs use of the "Tag" parameter in the "From" Header for generating nonce values for SIP digest authentication.
Basically the position of SIP Foundry is as follows (quoted from http://interop.sipxecs.org/): "The authentication nonces provided by sipX are specific to the from-tag in the request. Section 8.1.3.5 of RFC 3261 requires that a re-sent request has the same from-tag as the original request, so the nonce that sipX returns in a 401/407 response can always be used in a re-send of the request. However, some UAs will incorrectly use a different from-tag when resending a REGISTER. These UAs will not be able to register." This is what Section 8.3.1.5 of RFC actually states: "In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous." The key word above being "SHOULD" - i.e. it is not a requirement but a recommendation. Based upon this being a recommendation, not a requirement, in the interests of greater interoperability for SIPXecs, it would ideal if the developers could provide the capability to configure whether or not nonce validation is based upon the from-tag parameter. Also, a relevant draft IETF report is located at http://ietfreport.isoc.org/all-ids/draft-smith-sipping-auth-examples-01.txt-48149.txt- in here Section 2.3 addresses specifically the issue of interoperability failures related to nonce invalidation, although I'm not sure if SIP registration is considered a dialog-creating request: "2.3 Invalid validation of a nonce It has been observed that some implementations create, and then attempt to validate, nonces based on the contents of the request that has been challenged. This causes implementation problems where the partner does not maintain certain SIP header fields between the original and later, authenticated, request. RFC 3261 does not specify a mechanism for creating a nonce for use in an authentication challenge. An implementation is free to generate a nonce in whichever way it sees fit and may choose to do so such that it may be validated and stale nonces detected to avoid replay attacks. RFC3261 [1] section 8.1.3.5 describes how to act on receipt of a 4XX class response, including 401 and 407 challenges, and states the following: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. This has been interpreted by some implementations to mean that an authenticated request can be relied upon to always contain the same Call-ID, To and From as the previous request. However this assumption is wrong in the case of dialog creating requests. If an initial dialog creating request fails, the dialog has ended. Reusing the same Call-ID and From tag appears to indicate that the dialog is expected to still exist. It does not and thus reuse of the same Call-ID and From tag should not be assumed. Nonces SHOULD NOT be generated based on information such as the Call- ID and tags unless a dialog has successfully been established and the request is therefore in-dialog." Any thoughts? Even better, any ideas on example modifications to current source code to enable me to get interoperability working in my environment? Regards Justin
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
