Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol (HTTP) Digest Aut hentication Using Authentication and Key Agreement (AKA)

From: [email-masked]
Date: Fri, 24 Oct 2003 14:25:41 +0300

Hi,

I think you are right that in a 3GPP system, registering multiple contacts that point to different terminals would have problems because of the way the SA establishment is done as part of the authentication challenge/response exchange. Obviously, a request forking to a terminal that has no valid SA would fail. However, what would be the use case for doing this sort of thing?

This is also not a 3GPP deficiency per se, but has implications in other systems as well. If I register a contact address that I'm not in possession of myself, there are many things that can potentially go wrong. What if the target UA's lease on that address runs out, and someone else claims it? What if that UA doesn't support the capabilities advertised in the contact I registered?

In any case, I think RFC 3310 (which specifies the AKA protocol based Digest authentication) has quite nothing to do with this, and neither does any other IETF specification that I can think of off the top of my head.

Cheers,
Aki   

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of ext Xin
 > Chen
 > Sent: 24 October, 2003 12:53
 > To: 'Dean Willis'
 > Cc: [email-masked]'
 > Subject: RE: [Sip] Question on rfc3310 Hypertext Transfer Protocol
 > (HTTP) Digest Aut hentication Using Authentication and Key Agreement
 > (AKA)
 > 
 > 
 > Hi Dean,
 > 
 > Thanks for your answer. Exactly, that the questions are from 
 > my study in
 > 3GPP specifications. 
 > 
 > I think there is a problem in 3GPP to support multiple 
 > contact addresses in
 > a single REGISTER. Since more likely, each contact address 
 > will be another
 > terminal, however, only the terminal which initiates the 
 > REGISTER could be
 > authenticated successfully and have a security association 
 > established after
 > the registration. However, terminals representing other 
 > contact addresses do
 > not have that SA, so if forking happens, messages to the 
 > other terminals
 > will be unprotected or even dropped off in the network.
 > 
 > You suggest to address this question in sip implementer, 
 > thanks. However, I
 > am not sure this is purely an implementation issue or not. 
 > We would like to
 > see some general guidelines on solving this problem perhaps.
 > 
 > Hope see you again sometime in 3GPP again:-)
 > 
 > Regards
 >  
 > Xin Chen
 > Mobile Network Division
 > Fujitsu Laboratories Europe
 > Tel: +44(0)2086064453
 > Mobile: +44(0)7775741020
 > 
 > 
 > -----Original Message-----
 > From: Dean Willis [mailto:[email-masked]] 
 > Sent: 23 October 2003 20:29
 > To: Xin Chen
 > Cc: [email-masked]'
 > Subject: Re: [Sip] Question on rfc3310 Hypertext Transfer 
 > Protocol (HTTP)
 > Digest Aut hentication Using Authentication and Key Agreement (AKA)
 > 
 > 
 > On Thu, 2003-10-23 at 05:38, Xin Chen wrote:
 > > Hi,
 > > 
 > > My question is that if REGISTER procedure is used to 
 > authenticate the 
 > > user agent, then it can only authenticate the device which 
 > initiate 
 > > the REGISTER.
 > > 
 > > 
 > > What happen if the REGISTER contains multiple contact 
 > addresses which 
 > > possibly represent multiple devices, does that mean all the other 
 > > devices are authenticated also?
 > > 
 > > If forking happens, how to provide confidentially and 
 > integration to 
 > > the SIP messages towards the other contact addresses?
 > > 
 > > I am not sure whether these questions are within the scope 
 > of the RFC 
 > > or not, but your comment and thoughts are appreciated.
 > > 
 > 
 > 1) This type of question is probably better-addressed to the SIP
 > Implementors list. Perhaps we should even include it in the FAQ?
 > 
 > 2) In the typical case, authentication of a REGISTER request simply
 > establishes that the request in question came from a user agent with
 > credentials to authenticate against the address-of-record in 
 > question. It
 > does NOT establish anything about future requests coming 
 > from that user
 > agent, or about contacts registered by that request.
 > 
 > Authentication of a REGISTER request does NOTHING to provide 
 > confidentiality
 > or message protection of traffic back toward the registering 
 > UA, nor to any
 > other UA for which a "Contact" exists. That's why we have 
 > "sips" and TLS.
 > And the ability to authenticate EVERY request, not just REGISTER.
 > 
 > 3GPP has done something "special" here -- during the registration
 > transaction, they establish keying for a transport-level 
 > integrity-protected
 > (and optionally encrypted) tunnel between the UA and its 
 > edge proxy. This
 > tunnel then protects future messages between the two, and 
 > since the edge
 > proxy is trusted (and every other proxy, for that matter), allows for
 > transitive trust all the way through the system. This isn't 
 > a general case
 > solution, but they feel it works in a telecom operator 
 > environment. This is
 > why there are all sorts of applicability statement and scope 
 > warnings in the
 > RFCs defining 3GPP P-headers -- if used in the outside 
 > world, the sensistive
 > information therein would be likely to be compromised.
 > 
 > --
 > Dean
 > 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 24 Oct 2003 12:43:30 -0500

On Fri, 2003-10-24 at 04:52, Xin Chen wrote:
> I think there is a problem in 3GPP to support multiple contact addresses in
> a single REGISTER. Since more likely, each contact address will be another
> terminal, however, only the terminal which initiates the REGISTER could be
> authenticated successfully and have a security association established after
> the registration. However, terminals representing other contact addresses do
> not have that SA, so if forking happens, messages to the other terminals

Admittedly, I haven't been to 3GPP in a while, and maybe you folks have
changed something. I suppose if people start spenidng lots of money
buying IMS systems, I'll be compelled to show up and find out . . .

But, here's how I understand it to work. 

Each mobile sends a REGISTER containing only its own Contact. Each
registration accumulates a Path, which is stored in the registrar along
with the Contact. The registration transaction sets up session keying
for a security association between the P-CSCF and the mobile, and the
P-CSCF learns (by observing the transaction) enough about the identity
of the mobile to assert the identity of the mobile on future
transactions on that security association.

Now, here's the interesting bit (and this part may have changed). The
mobile actually registers with a "private" identity, and it may request
(p-requested-identity) any one of a number of possible public identities
on future transacations. How does the P-CSCF know that the mobile is
allowed to request the given public identity, and that it (the P-CSCF)
should assert this identity on behalf of the mobile by replacing the
p-requested-identity header field with a p-asserted-identity header
field? At one time (and 3GPP may still work this way) the 200 OK in
response to the authenticated REGISTER carried a list of "allowable
public identities" associated with the privtae identity that had
registered. Both the mobile (some debate here, they may have decided to
provision this data in the mobile rather than send it between the P-CSCF
and the mobile) and the P-CSCF would store this set of public identities
in association with the security association. In a later transacation,
the mobile could reference one of these identities in a
p-requested-identity header field, and iff that identitiy was known to
the P-CSCF and associated with this security association, the P-CSCF
would replace the p-requested-identity header field with a
p-asserted-identity header field having the same value.

So, how would the mobile associate an external address-of-record with
itself? It seems that the correct procedure would be to do what would
effectively be a third-party registration, setting the mobiles'
Address-of-Record (NOT Contact) as the Contact for the foreign
Address-of-Record. By doing this, requests for the foreign AOR would be
directed toward the mobile's AOR (its serving S-CSCF), and thence to the
mobile's Contact, along the recorded Path and its associated security
association.

This begs the question of "How do we associate just this mobile's
Contact, not the mobiles AOR, with a foregin AOR?" The answer, as far as
I know, remains unresolved. I suspect a "clean" answer here will depend
on the resolution of the GRUU/device identity work in IETF.

--
Dean