Subject: [Sip] Re: Some comments on RFC 3329 (Security Mechanism Agreement for the S ession Initiation Protocol)

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Apr 2003 12:00:02 +0300

Keith,

thanks for your comments. Answers inline.

Drage, Keith (Keith) wrote:
 > 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.

Yes, when you were discussing these issues within 3GPP, I already 
acknowledge this error. PRACKs should not be an exception. The only 
exceptions are CANCELs and ACKs.

We have two choices here.

1) Since you and we know that it is an errata, you add a note to your 
3GPP spec accordingly and when/if we release a revised version of 
sec-agree, we will correct it. This is what we have done with RFC3261 
and bugzilla so far.

2) We publish this errata at http://www.rfc-editor.org/errata.html

For such a small thing, I would go for option 1, although I will be glad 
to publish the errata if you feel more comfortable.

 > 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...
 >

Yes, I agree that adding such a clarification would help people 
understand. However, I consider this as an editorial comment, rather 
than a technical one, so I do not see a need for publishing an errata 
about this. In any event, I will log your comment and this will be 
clarified in future potential revisions of the document. Thanks.

 > 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).

There is no distintion. Status code is the original term, but response 
code is probably better understood by many. We may want to clarify this 
in future revisions of RFC3261.

 > Unlike other codes in
 > RFC 3261, this RFC does not define any semantic meaning to the status
 > code.

The semantics may not be defined explicitily, but they are clear by 
reading the document.

 > 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."
 >

Again, I agree with your comment, but I consider this to be an editorial 
one (clarification requested). I believe that it is clear that you have 
to re-try the same request, since this is standard behaviour in SIP. for 
example, I send a REGISTER and I get back an error code saying that the 
server cannot decrypt the request. I re-try the REGISTER, not any other 
random request...

In any event, I log your comment in order to clarify this in future 
potential revisions. Thanks.

 > 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.
 >

This is actually a thing that would be good to clarify. The reason why a 
proxy can remove a sec-agree tag from a Require header is that the 
Proxy-Require header contained the sec-agree tag as well. Therefore, 
since the proxy understands sec-agree, it is safe for it to remove it. 
But in general, it would be unsafe for a proxy to remove any other tag 
in the Require header.

And the reason a client needs to add tgs to both, require and 
proxy-require is that it wants to make sure that its next hop, no matter 
if it is a proxy or a UA, uses sec-agree.

Thanks for the comments,

Cheers,

Gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Apr 2003 04:27:53 -0500

> if it is a proxy or a UA, uses sec-agree.

Interrestingly, RFC3329 is not the first RFC to have a proxy remove a 
proxy-require header. RFC 3323 (Privacy extensions) does the same thing 
for much the same reason. As such, I agree that this is probably a bug 
in RFC3261, and that evil table 2/3 should be modified to amr, with 
explanatory text explaining under what conditions. I don't think proxies 
can modify Require, however.

I've logged the bug into bugzilla:
http://bugs.sipit.net/sipwg/show_bug.cgi?id=707

THanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 03 Apr 2003 13:01:52 +0300

Jonathan,

> can modify Require, however.

In general, proxies cannot modify Require. However, sec-agree is a very 
special mechanism that is inteded to be used *only* with the next hop. 
That's why the UAC adds both Proxy-Require and Require to the request. 
To cover the case where the next (first) hop is already the UAS (which 
would ignore the proxy-require header).

In any event, sec-agree lets the proxy remove the Require tag because 
the same tag (sec-agree) appears in the proxy-require, and this ensures 
that the proxy understands sec-agree and knows what it is doing when is 
removing the Require tag.

Of course, Require header removal by proxies in any other scenario would 
be very bad.

Gonzalo