Re: [Sipping] draft-ietf-sipping-update-pai-05 - responseauthentication

[Cullen Jennings <[e-mail]>]

For several years we have discussed that it would be nice to have a  
way to tie the previous authentication of a UA to a security channel  
and use that binding for response authentication. Outbound + TLS  
seemed like one way to do this. The plan was to get basic outbound  
done before starting this type of work. It will be a major piece of  
SIP security work to get this done. It will need it's own draft and it  
probably needs to happen in the SIP WG.

Cullen

On Aug 19, 2008, at 24:31 , Elwell, John wrote:

> Paul, Jonathan,
>
> Yes, I failed to mention that this is a problem impacting requests  
> too,
> but with the big difference that each request can be digest
> authenticated. I agree with Paul, that unless you have some way of  
> tying
> together the client of a TLS connection with the client of an earlier
> digest authentication over that same TLS connection, then you have no
> business asserting identity. I am sure practice differs from this! Can
> one of the IMS experts explain how this is achieved?
>
> So the question (to the whole group, and particularly to Cullen and  
> Jon)
> is, should we add some words (for both requests and responses) that
> explains that in order to assert an identity based on an earlier  
> digest
> authentication over the same TLS connection, you must have some  
> means of
> tying together the two clients? Would this be sufficient? Or is it
> necessary to give at least one example of how this might be achieved
> (and AFAIK, there are no standardised examples).
>
> John
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: 18 August 2008 23:37
>> To: Jonathan Rosenberg
>> Cc: Elwell, John; SIPPING LIST
>> Subject: Re: [Sipping] draft-ietf-sipping-update-pai-05 -
>> responseauthentication
>>
>>
>>
>> Jonathan Rosenberg wrote:
>>> I don't understand why this issue is unique to responses.
>> You have the
>>> same problem with requests. If a proxy authenticates a
>> client over TLS,
>>> and then later on does not re-authenticate each request, it
>> is possible
>>> that subsequent request might actually come from clients
>> further upstream.
>>>
>>> Since we have not viewed this as a problem for requests I
>> don't see why
>>> we should consider it for responses.
>>
>> Or, maybe it really *is* a problem for requests as well!
>>
>> I always viewed the workable use of this in requests to be
>> for the first
>> trusted node to authenticate, perhaps using digest, and then
>> to insert a
>> PAI. The IMS folk always asserted that they had some magic
>> way to verify
>> that the sender of a message was the same one that earlier sent a
>> REGISTER that had been authenticated. If they in fact do not
>> have a way
>> to do that, then they have no business inserting a PAI
>> assuming they do.
>>
>> I agree the response side is only different to the extent
>> that the magic
>> mechanisms differ.
>>
>> 	Thanks,
>> 	Paul
>>
>>> -Jonathan R.
>>>
>>> Elwell, John wrote:
>>>> During discussion of 04 in Dublin, concerns were raised about the
>>>> conditions in which it is possible to assert identity in a
>> response. The
>>>> present text says:
>>>>
>>>> "        <t>The proxy behaviour specified in RFC 3325 is
>> applicable to
>>>> responses with the following qualifications. A proxy that
>> receives a
>>>> response from a node outside the Trust Domain cannot directly
>>>> authenticate the UAS by SIP means. Therefore it MUST NOT include a
>>>> P-Asserted-Identity header field when forwarding the
>> response unless it
>>>> has authenticated the UAS by other means.</t>
>>>>        <t><list>
>>>>          <t>One possible circumstance in which a proxy
>> can include a
>>>> P-Asserted-Identity header field when forwarding a
>> response from a node
>>>> outside the Trust Domain is when the proxy has direct TLS
>> connectivity
>>>> with the UAS and has authenticated the UA by some other
>> means (e.g., SIP
>>>> digest authentication) during that same TLS session.</t>
>>>>        </list></t>"
>>>>
>>>> A concern raised was as follows. How does the proxy know
>> that it has
>>>> **direct** TLS connectivity with the UAS, as opposed to
>> going through
>>>> some intermediary (e.g., an edge proxy)? If there is an
>> intermediary,
>>>> the response may not have come from the UA that was earlier
>>>> authenticated, since the intermediary may have sent a
>> response from a
>>>> different UAS over the same TLS connection (or even
>> responded itself
>>>> over the same TLS connection). Unless the intermediary is
>> also a trusted
>>>> node (in which case the provisions of the paragraphs above do not
>>>> apply), it is important for the proxy to know that there is no
>>>> intermediary, i.e., that the TLS connection is with the
>> UA. Although
>>>> there are signalling mechanisms possible to achieve this,
>> they are not
>>>> standardised. Therefore a proxy can only rely on prior
>> knowledge (e.g.,
>>>> configuration) to know whether to assert an identity in such
>>>> circumstances.
>>>>
>>>> Do people consider this to be a sound basis for accepting asserted
>>>> identity in responses from untrusted nodes? Is it
>> realistic to assume
>>>> that there will be situations where it would be safe to configure a
>>>> proxy to assert an identity when a response is received over a TLS
>>>> connection over which digest authentication has already
>> taken place? The
>>>> existing wording in the draft would then be basically
>> correct, but might
>>>> benefit from some additional explanation, particularly in
>> the Security
>>>> Considerations section.
>>>>
>>>> John
>>>>
>>>>
>>>> _______________________________________________
>>>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use [e-mail] for questions on current sip
>>>> Use [e-mail] for new developments of core SIP
>>>>
>>>
>>

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP