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

From: Xin Chen <[email-masked]>
Date: Fri, 24 Oct 2003 10:52:53 +0100

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