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

From: "Mark Watson" <[email-masked]>
Date: Sat, 15 Jun 2002 17:20:01 +0100

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.
 
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.
 
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.
 
Finally, the reliance on IPSEC for the first hop to avoid re-authentication
on subsequent messages is not exactly 'outside the internet model'.
 
...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

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 16 Jun 2002 22:41:16 -0700

On Saturday, June 15, 2002, at 09:20 AM, Mark Watson wrote:

> 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.
>  
> 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.

Sure you want to reuse the SIM card as an authentication mechanism, but 
when you map this authentication onto SIP Digest authentication, there 
is no reason the SIMs private ID has to be 1:1.  Why can't it correspond 
to multiple digest usernames?  For example, say my private ID is 
12345678, i could set the username to 12345678 to login and use the 
default "account", and use username 12345678.personal or 12345678.1 for 
my personal identity/account, and 12345678.2 or 12345678.work for my 
work identity/account.

So, I don't think anyone has provided a technical reason my such a 
mechanism couldn't work, just that a separate header is more natural or 
elegant or better in some philosophical way which is hard to measure.  
There is a baseline mechanism available to solve this problem. Several 
folks want a separate header anyway.  Since the benefits of a separate 
header are impossible to quantify at the moment, we can use a P-header 
in its "provisional" sense of the word to get some operational 
experience. Six-months or a year from now we may discover that this 
mechanism really should be a general purpose header, or we may discover 
that the "unnatural" mechanism works just fine and really isn't so 
unnatural after all.

Also, I'd like to observe that the reason we are probably having trouble 
coming to consensus, is that we have no common set of requirements.  
Therefore I'd like to invite you all to quit bickering about this and 
write one or more requirements drafts before draft cutoff on Friday.  
Like all requirements drafts, these should get submitted with a 
draft-lastname-sipping prefix and discussed on the SIPPING list.  
Otherwise I expect this thread will continue to go nowhere.

thanks,
-rohan

> 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.
>  
> Finally, the reliance on IPSEC for the first hop to avoid 
> re-authentication on subsequent messages is not exactly 'outside the 
> internet model'.
>  
> ...Mark
>
> 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.
>
> > 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. 
>