Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 17 Jun 2002 17:51:11 -0500

A few inline notes below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Saturday, June 15, 2002 9:20 AM
To: 'Peterson, Jon'; 'Dean Willis'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Ok, so I am not particularly bothered about Preferred Identity being a
P-header. But I think it is fair to argue the point that if several users of
SIP have found the need to 'diverge' from the standard SIP architecture in
this respect, then perhaps it is worth considering enhancement of the
standard architecture. There is an assumption in SIP that a given user (from
an authentication point of view) has only a single identity/service profile
etc. We are just talking about relaxing that assumption.
[Peterson, Jon] Just to be clear, there is no assumption that a single user
has only a single identity in SIP's baseline authentication mechanism. I may
have many usernames and passwords that I can provide for different 'realms'.
In fact, SIP even has a concept that a given response (a 407) can aggregate
challenges from multiple realms, and that a user can provide different
credentials to each one of these challenges in a single retried request (so
I can cryptographically claim to be both [email-masked]
<mailto:[email-masked]>  and  [email-masked]
<mailto:[email-masked]>  in the same request, if I have the
proper credentials). Also, as we've argued here many times before there are
a number of other SIP headers that can all carry identity information at
variance with one another in a single SIP message.
 
In the case of 3GPP, then the requirement arises from the desire to re-use
the SIM-card based authentication mechanism which has already been scaled to
.5 billion users or whatever. I think this makes this mechanism just a
little more successful than any other authentication scheme of equivalent
security that I know of. This in my view is a reasonable case for re-use,
even if a slight divergence from the SIP architecture is involved.
[Peterson, Jon] More successful than TLS and Digest in HTTP?
 
The properties of this mechanism, and the functional split between the home
SIP proxy and the repository of the shared secret make it difficult to use
the cached nonce approach.
[Peterson, Jon] That isn't clear to me, actually. Nonces are cached on a
per-realm basis. Assuming that you intend to prove identities within the
same realm, you can re-use the nonce. The split between a home proxy and a
repository of shared secrets (brokered by some kind of AAA protocol, I'd
guess? - the concept of realms carries over into many such systems)
shouldn't impact that either way.
 
Finally, the reliance on IPSEC for the first hop to avoid re-authentication
on subsequent messages is not exactly 'outside the internet model'.
[Peterson, Jon] Yes, well, I did acknowledge that 'Internet model' is a
loaded term, especially when used to describe SIP (cough). The real issue
seems to be the way in which these 3G models segregate authentication from
assertion of identity - you provide credentials at some lower layer which
are linked, in the back office, with a set of identities that you can
legitimately assert in the application layer. In any event, the
authentication takes place outside of SIP, so it can at least be said to be
outside the scope of the 'SIP model' - SIP is expected to take it on faith
that the security properties of authentication are handled appropriately
elsewhere (much as it is expected to take confidentiality and integrity on
faith when IPSec with security gateways is used). It is also my
understanding that 3G's architecture requires that some properties of sub-IP
layers in the network contribute to security services.
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 14 June 2002 18:44
To: 'Dean Willis'; Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Well, this begins to speak to the matters that in my mind actually motivated
the P-Preferred-Identity header - namely, the fact that PacketCable-derived
networks did not want to use the baseline SIP authentication mechanisms. If
per-request authentication (which, as Dean correctly points out, can use
cached nonces to avoid the extra RTTs) is infeasible for some reason, you
may need a alternate way to express the identity that would ordinarily be
presented by the SIP authentication system. I have always viewed
P-Preferrred-Identity as an authentication header with no cryptographic
properties - something like an unsolicited Proxy-Authorization with no hash
- since the cryptographic properties are being staged elsewhere.
 
When you start to turn your back on the baseline SIP mechanisms, and instead
rely on mechanisms outside the Internet model (yes, loaded term) for
security and authentication, you have entered into the realm of P- headers.
Ultimately, that is what this thread is about - whether or not
P-Preferred-Identity should be a P- header.
 
Maybe this is really the crux of the matter - if your architecture diverges
enough from the SIP model that you can't get access to SIP authentication as
a way of expressing your identity to the network, then clearly your
architecture is not 'baseline', and any argument that we need some baseline
SIP mechanism (as opposed to a P- header) to express identity in your
architecture is going to seem a little suspect.
 
I agree, anyway, that inquiries along these lines are more likely to provide
profitable new arguments for doing this one way or another than some of the
other branches in this thread.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, June 14, 2002 8:39 AM
To: 'Mark Watson'; 'Peterson, Jon'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01

Mark suggested: 
> If I allow subsequent sessions on the same connection, then this 'hint'
becomes useful. Performing Digest authentication again every time (requiring
an additional RTT) seems a heavy price just to communicate a few extra
octets. 
 
Er, you COULD just include the appropriate credentials using the cached
nonce on future requests, and not bother to actually rechallenge . . .
 
but it does seem cleaner to use a preferred-identity indicator.
 
--
Dean