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

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Sep 2006 17:41:47 +0100

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: Fri, 22 Sep 2006 14:26:03 -0400

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

---

From: Shida Schubert <[email-masked]>
Date: Fri, 22 Sep 2006 19:42:00 -0700

Hi;

I thought about this a bit, and with connected-identity even 428
seems to be somewhat problematic.

Imagine a scenario where call with SIP-identity+"id-change" tag
gets forked to 2UAs served by different domains. UA1 whose
domain provides Identity service and UA2 whose domain does not
provide identity service. (Both UAs are compliant to connected-identity)

UA2 beats the race and established the call and sends back an UPDATE
without SIP-identity and gets rejected with 428 because its domain does
not provide identity services.

If there was a way to indicate the need of sip-identity in return, we
might be able to avoid this problem as call can be forwarded using this
indication to the domain supporting the identity services but as of now I
don't think there is anything we can do to avoid this. So I am leaning
towards
changing the verifier's behavior a bit more lenient when it's dealing with
mid-dialog identity.

Regards
Shida

Paul Kyzivat wrote:
> John,
>
> I want to hear what others, especially Jon and Cullen, have to say
> about this.
>
> 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.
>
> 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
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 22 September
>>> 2006 15:13
>>> To: Elwell, John
>>> Cc: Cullen Jennings; SIP
>>>>> 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
>>> 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.
>>>
>>> A UA that imposes such a requirement will be limited in what it can
>>> do, but that may still be right in some cases.
>>>
>>> sender of the request. This may require a way for the UAC to tell
>>> the authentication service not to act.
>>>
>>> I think that the remedy to these is in the verifier. The purpose of
>>> the verifier is ultimately to drive an authorization decision. If
>>> 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.
>>>