Subject: [Sip] Re: draft-ietf-sip-identity-03

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Nov 2004 20:03:11 -0500

Jon,

Just catching up on my reading. A few questions/comments about the draft:

There is allusion to using this mechanism with redirect servers. But 
there are no examples of this. At least one small thing might not work 
great in such a case. The authentication service is required to add a 
Date header if not already present, and then use in in the signature. 
This won't work well for a redirect lacking Date.

  It may have need/requirement to use some other server as first hop, 
and may or may not even have way to know which one is the auth 
server.Requirement for UA to directly connect to auth server seems 
unrealistic. And requirement to send auth request over a tls connection 
seems insufficient if there are other hops. UA can't really be sure that 
the auth server with be the first hop. And it can't necessarily use sips 
to guarantee hop by hop security till it gets there. How about having 
the *UA* generate an identity header (or variant) signed somehow with 
its digest key to protect the message on the say to the auth server? 
(I'm not a crypto guy - maybe there is no way to make this work.)

You strongly discourage use of tel: in from:. But there are advantages 
of tel: - that recipient can render it as a phone number, which isn't 
really kosher if it is a sip url, even with user=phone. And return calls 
to it are obligated to use sip via the stated domain, while with tel the 
caller has more options.

Hash includes digit and method portions of CSeq. Digit portion could 
have leading zeros. As it passes thru other intermediate nodes it is 
possible this would be parsed and regenerated, losing the leading zeros. 
To avoid, value used here should drop redundant leading zeros.

Above are really small stuff. This is looking quite feasible now.

	Paul

_______________________________________________
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