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

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Oct 2006 08:03:44 +0100

Paul,

So your proposal is that the connected-identity RFC should update RFC 4474
to somehow relax rules at a verifier. Correct?

So the next question concerns the way in which these rules should be
relaxed. One problem with the verifier not being located at the UAS but at
some proxy is that the UAS might be configured always to trust identities
received in requests via the verifier's proxy if an Identity header field is
present, on the assumption that the signature has been checked by the
verifier. Therefore it sounds like the verifier, if it does not reject a
request with a bad signature, should remove the Identity header field (and
also Identity-Info) before forwarding the request towards the target.

Under what conditions should a verifier remove an Identity header field
rather than rejecting with 436/437/438? My inclination would be to leave it
as a matter of policy as far as the update to RFC 4474 is concerned, and
then make more precise statements concerning mid-dialog requests.
Alternatively the update to RFC 4474 could just relax the rules for
mid-dialog requests. I think there is some merit in relaxing the rules in
general, because otherwise there might be situations where a legitimate
caller cannot establish a call because an Authentication Service (outside
the UAC's control) is inserting an unverifiable signature (e.g., in
Identity-Info placing a URL that the Verifier cannot dereference for some
reason).

One consequence of the Verifier being separated from the UAS is that we
don't want to rely on stateful behaviour at the Verifier or its proxy (for
similar reasons that you cited for the Authentication Service earlier). So
for mid-dialog requests we would need to mandate, or at least recommend,
that 436/437/438 should not be sent.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 03 October 2006 01:44
> To: Elwell, John
> Cc: Cullen Jennings; Jon Peterson; SIP
> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: 
> draft-ietf-sip-connecte d-id entity-01 comments)
> 
> 
> 
> Elwell, John wrote:
> > 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
> 
> 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
> > 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
> > 
> 

_______________________________________________
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: Thu, 05 Oct 2006 11:28:45 -0400

> to somehow relax rules at a verifier. Correct?

Yeah, I think so.

> also Identity-Info) before forwarding the request towards the target.

(I think I have seen someone propose combining the use of Identity and 
P-Asserted-Identity, though I don't recall the details, or which draft 
it was. So what I am about to say might bear no relationship to that.)

I could see how Identity might be used between trust domains, while 
P-Asserted-Identity is used within a trust domain. In that case, a 
verifier might run at the entry point to a trust domain and if 
verification succeeds, insert a P-Asserted-Identity header with a 
corresponding identity. It then might, or might not, remove the Identity 
header. Recipients within the trust domain could then use 
P-Asserted-Identity as the source of identity info. (In this scenario, 
an identity header would only be added to requests when they leave the 
trust domain.)

In this kind of environment, it is only necessary for the verifier to 
omit the P-Asserted-Identity header when verification fails.

> Identity-Info placing a URL that the Verifier cannot dereference for some

What you say sounds reasonable to me.

There is however some risk to having a verifier remove identity. The 
problem would be when there are potentially multiple verifiers that 
don't trust one another. If an early one removes the header, then it 
prevents a subsequent verifier from doing its own verification.

This could come up if a request transits a domain on the way to another 
domain. Each domain may wish to do its own verification.

That is an advantage to having the verifier add something to the request 
to indicate the result of its verification.

> that 436/437/438 should not be sent.

Right.

	Paul