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

[Michael Thomas <[e-mail]>]

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

Peterson, Jon writes:
 > 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:[e-mail]]
 > > Sent: Wednesday, July 03, 2002 8:41 AM
 > > To: [e-mail]
 > > 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 [e-mail] for questions on current sip
 > > Use [e-mail] 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 [e-mail] for questions on current sip
 > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip