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

[Euchner Martin ICN M SR 3 <[e-mail]>]

Now I'm confused even more as this sounds like the Spec(T) example is in
fact of more mandatory nature.

11.2 Authentication requirements
   Users MUST be authenticated using SIP Digest Authentication.

First of all, I do not see any reason why to mandate SIP digest
Authentication for this draft.

Doing that would tie this draft forever to digest, but would not allow any
other SIP authentication mechanism. I recommend to reword as a SHOULD at
least and offering a MAY for other (SIP-09) authentication methods.
I guess what is perhaps intended is simply that "Users MUST/SHOULD be
authenticated".

My understanding of this draft is, that the draft assumes that users have
been authenticated (although even this can be weak in a trusted domain). The
draft describes a means how to populate the privacy-ID information but
certainly does not describe how to secure SIP.

11.3 Security requirements
   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.

Further, I really do not understand and do not see any value why this drafts
actually profiles TLS cipher suites allowing only RSA_AES128, but does not
allow any other defined TLS cipher suites. The defined TLS cipher suites
have been chosen with care and for good reasons; TLS has its inherent
security capability negotiation, that works just fine.

Then, as pointed out by Michael, the MUST mandate for mutual TLS is
counterproductive: if there is mutual TLS authentication, then digest
authentication is completely redundant. On the other hand, it >>should<< be
allowed to have proxy-sided TLS authentication combined with some other
authentication, and of course other authentication methods should not be
ruled out.

Finally, I completely agree with Michael's proposal, that sections 11.2 and
11.3 be completely revised, making them aligned with what SIP-09 spec says
about authentication and security (although that is problematic as well) and
leaving sufficient degree of freedom for future extensions. This privacy
draft shall not attempt to define its own SIP Security baseline.


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: [phone]
| Siemens AG.....................Fax  : [phone]
| ICN M SR 3                     mailto:[e-mail]
|                                mailto:[e-mail]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[e-mail]] 
Sent:	Thursday, July 04, 2002 10:03 PM
To:	Michael Thomas
Cc:	Peterson, Jon; [e-mail]
Subject:	Re: [Sip] p-asserted-identity security harmful

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.

Michael Thomas wrote:
> 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
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[e-mail]                 FAX: [phone]
http://www.jdrosen.net                  PH:  [phone]
http://www.dynamicsoft.com


_______________________________________________
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