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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Jun 2002 12:44:06 -0500

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