Subject: [Sip] RE: draft-ietf-sip-connected-identity-01 comments

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Sep 2006 11:29:54 +0100

Cullen,

Thanks for your review. See below. Also others should take a look at the
first point below in particular.

John 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 09 September 2006 19:51
> To: SIP; Elwell, John
> Subject: draft-ietf-sip-connected-identity-01 comments
> 
> 
> John thanks for the work on this - it is looking really good and I  
> like how you have solved the issues. WIth my AD hat on, I 
> really like  
> how this draft it going and looks good. The rest of the comments are  
> sent with  my individual hat on and some of them are far more nit  
> picky that I would feel was appropriate for an IESG comment.
> 
> Few things ....
> 
> When an Update is sent. Are there any conditions under which 
> it might  
> be rejected. Bad identity for example. I think that might need a  
> little discussion and also what the UA does when it sends an update  
> with a no identity and it gets rejected.
[JRE] A very good point. We don't want to get to a situation where it is
impossible to perform a mid-dialog request (e.g., for purposes such as
session timer refresh or session re-negotiation) just because  connected
identity fails. My proposed fix is as follows:
1. Say that a UAS SHOULD NOT reject a mid-dialog request with 428 'Use
Identity Header'.
2. Say that an Authentication Service MUST NOT add an Identity header field
to a mid-dialog request if a previous request on that dialog has resulted in
436 'Bad Identity-Info', 437 'Unsupported Certificate' or 438 'Invalid
Identity Header'.
3. Say that a UAC MUST repeat a mid-dialog request that results in one of
these responses if the mid-dialog request was not solely for the purpose of
connected identity. If solely for the purpose of connected identity there is
no point in repeating it, so I will say "SHOULD NOT take any further
action".
Comments?

> 
> There is a lot of background information about how we got to this  
> decision, other ways that one might do this etc. If this was 
> moved to  
> an appendix, it would probably help implementers focus on the 
> key stuff.
[JRE]OK, I bow to pressure - a couple of others have made similar comments.
Essentially I have moved sections 3 (existing mechanisms for conveying
identity) and 4 (existing mechanisms for authenticated identity) to an
appendix.

> 
> The security section could probably use more work around the 
> issue of  
> what you can trust here and what you can't. Might want to reference  
> history as a possible solution to some of the stuff that this does  
> not solve.
[JRE] I have referenced history-info and also added something about the
possibility of terminating the call if a UA is really not happy with the
absence of a valid Identity header.

> 
> 
> Nits
> 
> In the Header on first page, needs to day updates 3261
> 
> Somewhere in draft need a describe exactly what this changes in 3261
[JRE] I thought this was covered in the existing section 5, but I have
enhanced it slightly. It now says: "This document therefore deprecates
mandatory reflection of the original To and From URIs in mid-dialog requests
and their responses, which constitutes a change to RFC 3261."

> 
> The name of the option tag "id-change" sort of bugs me. What is  
> allowed to change here does not really have to do with identity as  
> much as the from URI. I would prefer the name "from-change" as what  
> this is saying is only that part of 2543 was not required by the UA.
[JRE] Well, the URI is the identity, so I don't really understand your
point. It was changed to "id-change" from something rather longer a draft or
so back, so I would be reluctant to change it again. Any other opinions?

> 
> I computed the Identity Strings - I have a program to do this 
> and can  
> update if the messages change. Make sure we regenerate and check  
> these in in Auth 48.
> 
>   invite(2) base64 identity is xN6gCHR6KxGM 
> +nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G 
> +VwY13uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/ 
> fFGBrpBSjztmfffLTp6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzK
> DNjlYlmmc=
> 
>   update(8) base64 identity is g8WJiVEzrbYum+z2lnS3pL 
> +MIhuI439gDiMCHm01fwX5D8Ft5Ib9tewLfBT9mDOUSn6wkPSWVQfqdMF/ 
> QBPkpsIIROIi2sJOYBEMXZpNrhJd8/ 
> uboXMl9KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=
> 
>   update(4) base64 identity is  
> AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywOUuObcwZI3
> qhJReZCN7y 
> bMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5cD26HrmitU 
> +OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=
> 
>   reinvite(6) base64 identity is  
> KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gpal8ckVM2vd1zqH/ 
> F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U3kGg8To/ 
> 6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=
[JRE] Thanks. The examples have not changed during WGLC, so these are still
valid, but we should check them during Auth48.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Sep 2006 10:13:07 -0400

> identity fails.

> My proposed fix is as follows:

I'm not sure about this. At the least I think this one needs some clear 
explanation of the SHOULD NOT - about the conditions when it can be 
violated.

I see this as somewhat analogous to doing a digest challenge on an 
in-dialog request. In some cases it is the right thing to do.

A UA that imposes such a requirement will be limited in what it can do, 
but that may still be right in some cases.

> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or 438 'Invalid

This requirement would force the authentication service to be dialog 
stateful, which is not ideal. Better to push the state back into the 
sender of the request. This may require a way for the UAC to tell the 
authentication service not to act.

> no point in repeating it, so I will say "SHOULD NOT take any further

This seems wrong to me.

I think that the remedy to these is in the verifier. The purpose of the 
verifier is ultimately to drive an authorization decision. If 
authorization would succeed in the absence of the identity, then the 
request should be permitted to continue as if the identity was not present.

Unfortunately this would seem to require a revision to 4474 even though 
the paint is hardly dry on it.

If this is done, then there is no need of a mechanism to cause the 
authentication service *not* to authenticate. If this is *not* done, 
then that need remains, which will still require a change to 4474.

	Paul