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

From: "Mahey, Sonit" <[email-masked]>
Date: Wed, 3 Jul 2002 12:01:46 -0400

Folks,

Pardon me for jumping in late in this discussion. I am missing the rationale
behind the choice of TLS as opposed to IPSec.
However, one issue still remains pertinet to both - that of PKI. 
Packet Cable incidently, adopts Kerberos as key management on a few
interfaces. 
First off, is SIP trying to mandate something for security? If yes, why not
adopt IPSec and use Kerberos for Key management, just like PacketCable? 

Thanks.

- sonit

Sonit Mahey,
Systems Architect,
Siemens TGOS,
*: 10 Technology Park Dr., Westford, MA 01886
': 978.923.3271
*: [email-masked] 
http://www.siemens.com

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, July 03, 2002 11: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