Subject: RE: [Sip] p-asserted-identity security harmful

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 4 Jul 2002 14:27:24 -0500

Um, did you perhaps not see the word 'Example' in the title of section 11?
The document only requires that a Spec(T) be defined, and provides one in
section 11 for illustrative purposes. Or as it says in the beginning of
section 11:

   The remainder of this section presents an example Spec(T), which is
   not normative in any way.

Thanks as always for your reasoned analysis of our work in this group.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2002 8:41 AM
> To: [email-masked]
> Subject: [Sip] p-asserted-identity security harmful
> 
> 
> 
> From Section 11.3 of draft-ietf-sip-asserted-identity-01:
> 
> >    Connections between nodes within the Trust Domain and 
> between UAs and
> >    nodes in the Trust Domain MUST use TLS using a cipher suite of
> >    RSA_WITH_AES_128_CBC_SHA1.  Mutual authentication 
> between nodes in the
> >    trust domain MUST be performed and confidentiality MUST 
> be negotiated.
> > 
> 
> 
> It's just come to my attention that TLS was
> mandated in the asserted identity draft. Not only
> was TLS mandated, but certain cipher suites and
> _AUTHENTICATION_ mechanisms were made necessary
> not only to implement, but to deploy. This is
> utterly bogus. This also places new requirements
> on UA's, which are not part of the base SIP spec.
> That too is bogus, and has been slipped in with
> no discussion.
> 
> First, it ignores the possible use of IPsec as an
> alternate mechanism to protect the bits on the
> wire, but far more bogus doesn't allow for the
> proper latitude with authentication mechanisms
> needed in real life. I know that a lot of people
> here think that the PKI kool aide is going to
> solve world thirst, but reality has shown that to
> be a complete myth. SIP should not be mandating
> things for *deployment* which are manifestly
> undeployable as the only possible mechanism.
> Thirdly, it places new requirements on UA's of not
> only implementation, but *deployment* as
> well. This is extremely harmful.
> 
> This section should either be struck in its
> entirety, or refer back to the base SIP spec's
> proxy requirements (which are likely to be harmful
> too, but at least the damage will be limited to a
> single document).
> 
> 	Mike
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 4 Jul 2002 12:37:36 -0700 (PDT)

Jon,

I am not the only one who was confused by this and
before you start copping attitude you might
consider whether REQUIREMENTS LANGUAGE in EXAMPLES
is a recipe for an understandable document.

	    Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Jul 2002 16:03:01 -0400

You are, of course, correct that requirements language in examples is 
odd and potentially confusing. However, spec(T), of which this is an 
example, is supposed to be a specification itself - defining exactly 
what it means for an identity to be asserted.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com