On Thu, 2009-12-10 at 13:11 +1300, Justin Menga wrote:
> 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.
That's not what SHOULD means when used in an RFC. RFC 2119 defines
SHOULD:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
In this case, the full implications include the fact that it won't work
when the server is taking a conservative approach to protecting against
replay attacks.
> 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:
SIP registration is explicitly not a dialog-creating request, but the
same rules for retries for authentication apply.
That is a draft that expired almost 5 years ago. It never did have any
authority as a reference - see the boilerplate at the top of that (and
every other) I-D:
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
_______________________________________________
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/
