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

["Elwell, John" <[e-mail]>]

Cullen,

Perhaps I don't recall all of the earlier discussions, but I don't see
where Outbound comes in. Can you give me an idea of what might be
involved? Or was it simply that, without Outbound, TLS is not deployable
in many situations on the first/last hop?

One mechanism I could see working would be for digest authentication to
be applied to responses based on a nonce given in the request or in an
earlier message. Another mechanism would be to bind a digest signature
to a TLS client, by including a fingerprint of the certificate in the
digest signed information. The latter mechanism would also be useful for
requests. I agree such enhancements to digest would need to be done as a
separate task (in the SIP WG). Is this the sort of thing you had in
mind?

Having done something of this nature, then the proxy could use digest
authentication to support a PAI or Identity assertion.

The question is, do we need to hold up the update-PAI draft waiting for
such work, or can we proceed with suitable warnings about needing to
have authenticated the UAS and the pitfalls involved?

John


> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]] 
> Sent: 19 August 2008 15:01
> To: Elwell, John
> Cc: Paul Kyzivat; Jonathan Rosenberg; Peterson, Jon; SIPPING LIST
> Subject: Re: [Sipping] draft-ietf-sipping-update-pai-05 - 
> responseauthentication
> 
> 
> 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