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

[Paul Kyzivat <pkyzivat at cisco.com>]

Elwell, John wrote:
> > From: Cullen Jennings [mailto:fluffy at cisco.com] 

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

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.

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

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.

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

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip