Subject: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 comments)

From: "Elwell, John" <[email-masked]>
Date: Mon, 02 Oct 2006 20:33:05 +0100

Thinking further on this, perhaps there is a 4th way:

4. Specify that if a UAS rejects a mid-dialog request with 436, 437 or 438,
then it MUST NOT invoke the verifier for a subsequent request on the same
dialog unless the From header field URI has changed, and in such cases
SHOULD NOT make use of the unverified connected-identity. Then a UAC, on
receiving 436, 437 or 438, MUST repeat the request once. This would allow
business as usual on this dialog (but without the benefit of connected
identity, therefore no worse than at present). It avoids any change to RFC
4474, because verification is optional anyway.

Would this work?

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 26 September 2006 21:02
> To: Cullen Jennings; Jon Peterson
> Cc: SIP; Paul Kyzivat
> Subject: FW: Rejecting connected identity (was RE: 
> draft-ietf-sip-connected-id entity-01 comments)
> 
> Cullen, Jon,
> 
> In case you missed this (it wasn't addressed directly to 
> you), I would greatly appreciate an opinion from each of you 
> on this remaining issue in connected-identity. Just to 
> summarise, RFC 4474 leaves it up to policy whether to return 
> a 428 response if Identity is missing, but mandates the 
> sending of a 436, 437 or 438 response for certain errors 
> arising while verifying the signature. It seems that for mid 
> dialog requests this behaviour could be harmful. What does 
> the UAC for the mid dialog request do if it receives 436, 437 
> or 438? If the mid-dialog request was solely for the purpose 
> of connected identity, it can give up and allow the call to 
> continue as is. But if the request was for some other purpose 
> (e.g., renegotiating the session because of hold, say, or 
> session timer refresh), the UAC really wants it to work. For 
> the normal case where the Authentication Service is at a 
> proxy, not at the UAC, the UAC cannot force the 
> Authentication Service to refrain from putting this 
> unverifiable signature in the mid-dialog request, so any 
> attempts to repeat the request would most likely be doomed to 
> getting the same response.
> 
> It seems there are three things we could do, none very attractive:
> 1. Get connected-identity to modify the procedures of RFC 
> 4474 for a verifier by softening the requirements for sending 
> 436, 437 and 438 in response to mid-dialog requests. But then 
> a mid-dialog request from a rogue source would be accepted.
> 2. Say that the Authentication Service should omit the 
> signing of mid-dialog requests if a previous attempt has 
> resulted in 436, 437 or 438. But this implies statefulness at the AS.
> 3. Accept the fact the mid-dialog requests can fail in this 
> way and therefore things like session refresh and session 
> renegotiation cannot be done, probably resulting in call 
> failure. Sounds bad, but it is no different from an initial 
> INVITE request, where there is nothing the UAC can do if the 
> AS inserts an Identity header that gets rejected with 436, 437 or 438.
> 
> John
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]] 
> > Sent: 22 September 2006 19:26
> > To: Elwell, John
> > Cc: Cullen Jennings; SIP
> > Subject: Re: Rejecting connected identity (was RE: 
> > draft-ietf-sip-connected-id entity-01 comments)
> > 
> > John,
> > 
> > I want to hear what others, especially Jon and Cullen, have 
> > to say about 
> > this.
> > 
> > It is of some concern to me that a call might fail because of some 
> > problem with the identity mechanism when the same call might have 
> > succeeded in the absence of any identity.
> > 
> > But possibly the solution to this is policy in the 
> > implementation of the 
> > verifier. What to do in the case of the conditions that 
> lead to these 
> > errors could be configurable in the verifier: either to 
> generate the 
> > error or simply to remove the identity info from the 
> message. And the 
> > policy could conceivably vary based on attributes of the 
> > message, such 
> > as whether it is in-dialog or not.
> > 
> > Does it require a change to 4474 to permit that kind of policy?
> > 
> > It would be annoying if the end user had no control over the 
> > insertion 
> > and verification of identity, and it resulted in calls 
> > failing that the 
> > user would like to permit. But I suppose that is itself a policy 
> > decision. There are certainly enterprises that want to exert 
> > that kind 
> > of control over what users are permitted to do.
> > 
> > 	Paul
> > 
> > Elwell, John wrote:
> > > Paul,
> > > 
> > > I agree with most of your points, and on reflection I think 
> > I agree that the
> > > solution has to be with the verifier.
> > > 
> > > I think RFC 4474 is not a problem as far as sending a 428 
> > 'Use Identity
> > > Header' response is concerned, because that is left to 
> > policy, so we could
> > > say in connected-identity that policy should be to not send 428.
> > > 
> > > However, 436, 437 and 438 responses are all a problem, 
> > because RFC 4474 says
> > > that they MUST be sent under respective conditions. 
> > Interestingly, though,
> > > there are other failure scenarios that can arise from the 
> > procedures of
> > > section 6 of RFC 4474 for which no normative statement is 
> > given on how to
> > > respond, e.g. invalid Date header field, signer not 
> > authoritative for the
> > > domain.
> > > 
> > > So one way to solve the present problem would be for the 
> > connected-identity
> > > draft to modify verifier behaviour in RFC 4474 in the case 
> > of mid-dialog
> > > requests. I guess this would mean that it would update RFC 
> > 4474 as well as
> > > updating RFC 3261. But I don't like this, because it seems 
> > to remove some of
> > > the security properties of RFC 4474.
> > > 
> > > Another way would be to accept that 436, 437 and 438 
> > responses will be sent,
> > > and failure to verify a signature will therefore result in 
> > inability to
> > > process the UPDATE or re-INVITE request, and hence if the 
> UPDATE or
> > > re-INVITE request was for some other purpose such as 
> > session timer refresh
> > > or modifying the session, that action will fail. Then the 
> > call will fail (in
> > > the case of inability to refresh the session timer) or the session
> > > modification will fail. I guess this is somewhat analogous 
> > to caller ID
> > > verification failure in an INVITE request - it is 
> > impossible to establish a
> > > call if verification fails. Moreover, the UAC has no 
> > ability to rectify the
> > > situation, since it is at the mercy of a proxy-based 
> > Authentication Service
> > > that puts a rogue Identity header field in every request. 
> > In the connected
> > > identity case, the only difference is that the call is 
> > already established
> > > but is likely to fail if verification fails.
> > > 
> > > Of course, if the mid-dialog request is indeed from the 
> > wrong source, then
> > > sending a 436, 437 or 438 response is indeed the correct 
> > thing to do, and
> > > overriding the verification procedures of RFC 4474 would 
> > indeed be the wrong
> > > thing to do. So perhaps we just have to accept that these 
> > response codes can
> > > be received and will lead to failure.
> > > 
> > > So, my preferred way forward is simply to recommend not 
> > sending a 428 and
> > > accept the consequences of other responses that the 
> > verifier might send.
> > > 
> > > John
> > > 
> > >> -----Original Message-----
> > >> From: Paul Kyzivat [mailto:[email-masked]] 
> > >> Sent: 22 September 2006 15:13
> > >> To: Elwell, John
> > >> Cc: Cullen Jennings; SIP
> > >> Subject: Re: [Sip] RE: 
> > draft-ietf-sip-connected-identity-01 comments
> > >>
> > >>
> > >>
> > >> Elwell, John wrote:
> > >>>> From: Cullen Jennings [mailto:[email-masked]] 
> > >>>> 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 [email-masked] for questions on current sip
> > >> Use [email-masked] for new developments on the 
> application of sip
> > >>
> > > 
> > 
> 

_______________________________________________
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: Mon, 02 Oct 2006 20:44:03 -0400

Elwell, John wrote:
> then it MUST NOT invoke the verifier for a subsequent request

This assumes that the verifier is invoked by the UAS, and not by some 
proxy in front of the UAS. Isn't it valid to have a verifier in a proxy 
before the UAS? This rule would forbid that, because it would cause that 
proxy to be call stateful.

I think it would just be better to update the RFC, even though that is a 
bit more trouble than not to.

	Paul

> on the same