[Sip] Some comments on RFC 3329 (Security Mechanism Agreement for the Session Initiation Protocol)

["Drage, Keith (Keith)" <drage@lucent.com>]

In looking at this RFC we detect some issues that ought to be resolved even though this is a published RFC. There is also an issue that is raised with regard to RFC 3261.

1)	Section 2.6, table 1. The Security-Verify header is not included in the PRACK according to the table. It is our belief that the header should be applicable to all methods except ACK and CANCEL, where we agree that it makes no sense. 

2)	Section 2.3.1, 9th paragraph. In relation to the above comment, this text states:

   All the subsequent SIP requests sent by the client to that server
   SHOULD make use of the security mechanism initiated in the previous
   step.  These requests MUST contain a Security-Verify header field
   that mirrors the server's list received previously in the Security-
   Server header field.  These requests MUST also have both a Require
   and Proxy-Require header fields with the value "sec-agree".

This text should explicitly exclude the ACK and CANCEL requests. Something along the lines of:

   All the subsequent SIP requests except the ACK request and the CANCEL 
   request sent by the client to that server...

3)	Section 6.4 defines the new status code 494 (By the way what is the distinction between the term "status code" and "response code" - RFC 3261 seems to use both interchangeably). Unlike other codes in RFC 3261, this RFC does not define any semantic meaning to the status code.

While obviously we should not define user action on receiving status codes, one idea we would like to convey is that any recovery by the user caused by a 494 being sent in response to a Security-Verify header check, specified in 2.3.1 as follows:

   The server can proceed processing a particular request if, and only
   if, the list was not modified.  If modification of the list is
   detected, the server MUST respond to the client with a 494 (Security
   Agreement Required) response.  This response MUST include the
   server's unmodified list of supported security mechanisms.  If the
   list was not modified, and the server is a proxy, it MUST remove the
   "sec-agree" value from both the Require and Proxy-Require header
   fields, and then remove the header fields if no values remain.

should be appropriate to the security mechanism that is being agreed, rather than a matter of sticking the appropriate headers in the next method to be sent. Thus if the security architecture used specifies doing the security agreement over the REGISTER method, then that is the method that must be used for the recovery.

Some extra words in 6.4 to this effect would be useful.

I would suggest something along the lines of:

   "The server received a request which either requires a security agreement
   to be made, or the security agreement indicated did not match that already
   made. In order to continue, the UAC will need to make a new security 
   agreement using requests appropriate to the security mechanism for which
   agreement is made. Any existing dialogs can have been terminated as a 
   result of the loss of the security agreement."

4)	General. The document is inconsistent in its use of the Require and Proxy-Require headers compared to RFC 3261. As a result I believe changes are probably required to both documents.

The current situation in RFC 3261 is that proxies use the Proxy-Require header, and that UAs user the Require header. Neither entity is allowed to remove items from either header.

RFC 3329 currently seems to allow proxies to read and react to contents of the Require header, and both Proxy-Require and Require headers have the sec-agree option-tags removed by a proxy.

What I believe should happen is that RFC 3261 should be modified to specify "d" for proxies in the table that Jonathan dislikes - I mean table 2 and 3 of RFC 3261 for both these headers. Text concerning these headers should be modifed such that where a proxy is reacting and providing capabilities in accordance with the extension/application described in the Proxy-Require header, then the application/extension can define procedures for the deletion of option-tags relating to that extension/application in both the Require and Proxy-Require headers. Unless this is defined in the extension/application, then the proxy must not remove option-tags.

What needs to change in RFC 3329 is that proxy procedures should react only to the Proxy-Require header contents, and UAs should react only to Require header contents, strictly in accordance with RFC 3261. The procedures currently define the modification of Proxy-Require and Require headers for this extension.

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip