Subject: [Sip] Rejecting connected identity

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:25:14 -0800

We are going to have to thing very carefully about the security  
implications of section 4.6 in the latest 02 version - I'm worried we  
are removing the information that would allow a downstream sip device  
to make the appropriate authorization decision - anyways - lets talk  
in San Diego.

On Oct 29, 2006, at 1:41 AM, Elwell, John wrote:

> Cullen,
>
> See below.
>
> John
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: 28 October 2006 16:42
>> To: Elwell, John
>> Cc: Jon Peterson; SIP; Paul Kyzivat
>> Subject: Re: Rejecting connected identity (was RE:
>> draft-ietf-sip-connecte d-id entity-01 comments)
>>
>>
>> This is clearly hard and I would like to talk about it in person and
>> see if we can sort it out. A few things I was thinking about ...
>>
>> a) are there any practical scenarios where the initial invite
>> identity would have worked then the later mid dialog one fails in
>> this way
> [JRE] Yes, the initial mid-dialog request will be in the reverse  
> direction,
> so a different Authentication Service and a different Verifier.
>
>>
>> b) If the authentication verification fails and I have an
>> authorization policy at proxy that says don't accept unverified
>> calls, then clearly it needs to fail - even if it is retried
> [JRE] Agreed.
>
>>
>> c) should we consider something like, in the case of an error like
>> this, a UA could retry as an anonymous call
> [JRE] I guess the UAC would need to use anonymous.invalid - then I  
> think it
> could work. Using [email-masked] would not work, since a
> proxy-located Authentication Service for example.com might still  
> add an
> Identity header field.
>
>>
>> Let's talk in San Diego...
> [JRE] Yes, indeed, we should try to chat before the SIP session, which
> fortunately is late in the week.
>
>>
>> On Sep 26, 2006, at 1:02 PM, Elwell, John wrote:
>>
>>> 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