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

From: "Mark Watson" <[email-masked]>
Date: Fri, 14 Jun 2002 15:22:32 +0100

I have a different reason from Juha as to why I think Digest does not fully
solve this problem, as suggested by Jon.

In the case that there is a secure connection between the user and the proxy
(e.g. TLS) then when I have performed Digest authentication once, I do not
need to perform it again for subsequent messages on the same connection. The
SIP spec fairly strongly encourages the use of secure connections.

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.

I suppose I could maintain separate TLS connections for each identity but
this does then just become a judgement call between increased complexity
(multiple TLS connections) and PDD (extra RTTs - which are l o n g in
wireless) vs the addition of a new header.

In my view, particularly in high-latency applications, the reduced
complexity and PDD justifies the introduction of the new header.

Regards...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 13 June 2002 23:11
> To: [email-masked]'
> Cc: [email-masked]
> Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01
> 
> 
> I have a feeling that this is the last email in this thread 
> that I will
> respond to. Some (most likely wasted) notes below.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, June 13, 2002 11:38 AM
> > To: Peterson, Jon
> > Cc: [email-masked]
> > Subject: RE: [Sip] draft-ietf-sip-asserted-identity-01
> > 
> > 
> > Peterson, Jon writes:
> > 
> >  > Your users can have multiple identities and a single 
> password with the
> >  > existing SIP Digest authentication system. Groups of 
> identities can
> simply
> >  > use the same password (users do it all the time today 
> when they are
> known by
> >  > multiple names):
> > 
> > this is not acceptable to our users nor to us.  we have a 
> user database
> > that includes one unique username and password per user.  
> that database
> > is not sip specific, but is used for all services that we may be
> > providing for the user.  it would thus be totally out 
> question to start
> > introducing new users to the user database if one user wants to have
> > more than one sip identity.
> > 
> 
> Your back-office implementation details are not a persuasive 
> argument for
> why we should design a protocol one way or another. As I said 
> in my last
> mail, it would be trivial to derive a unique username (like 
> 'juha') from a
> hinted identity (a telephone number) in your back-office - 
> the protocol
> design question (concerning P-Preferred-Identity) is only 
> about what needs
> to be carried over the wire. Anyway, the system I described 
> does not require
> you to 'introduce' any new usernames.
> 
> [snip]
> >  > Why is it important that the user be able to choose
> >  > one of these 15 identities on the fly when they 
> originate (anonymous)
> >  > calls?
> > 
> > the user simply does want to remain anonymous when he 
> places a certain
> > call, i.e., doesn't want to show any of its 15 sip 
> identities.  the user
> > most likely still wants the calling party number to be one 
> that belongs
> > to the same area code to which he is calling to in order to 
> save long
> > distance charges.
> > 
> 
> So, you're honestly trying to tell me that users will save on 
> long-distance
> charges depending on how they hint at their calling party 
> number? Do you
> actually work for a telephone company?
> 
> Accepting for a moment the insane proposition that phone 
> companies will
> allow you to select among multiple identities in order to 
> manipulate the
> rate that they charge you, why would this be an end-user 
> function at all?
> Wouldn't the end user always just want the cheapest rate? Why 
> not have the
> phone company just choose the best phone number for you - 
> after all, they
> know the set of valid hints (i.e. calling party identities) 
> that a given
> user can supply. Based on inspecting the numbers themselves, 
> consumers might
> not always know how to select the cheapest identity. This application
> doesn't require any support in the SIP protocol, anyway.
> 
> I'm sorry, Juha, but I don't think this is worth the working 
> group's time
> anymore. I'd like to ask you to let this (now transparently 
> silly) matter
> rest.
> 
> > 
> > -- juha
> > 
> 
> _______________________________________________
> 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, 14 Jun 2002 10:39:16 -0500

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