Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Jan 2002 18:31:17 -0600

Yet still more below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 4:21 PM
> To: Peterson, Jon
> Cc: 'Michael Thomas'; 'Rosen, Brian'; [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> Peterson, Jon writes:
>  > While I don't know what the IESG favors for security 
> profiles, I have to say
>  > that a profile that requires no minimum algorithm for 
> confidentiality and no
>  > key exchange mechanism doesn't exactly sound like a recipe for
>  > interoperability. While I understand your reluctance to 
> require DES (the
>  > minimum encryption algorithm mandated by 2406), I would 
> think you'd have to
>  > require something for encryption. 
> 
> Not at all. Remember, the original IPsec only had
> AH. ESP and then ESP with NULL Encryption came
> much later. Lack of message integrity is at the
> root of almost every threat. Plus, lots of other
> protocols have minimum requirements for just
> message integrity.

Known threat models against SIP motivate a need for confidentiality,
regardless of what IPSec is minimally capable of supporting, or what other
protocols require.

> 
>  > Similarly, I would think there would have
>  > to be some story for key exchange.
> 
> I don't think SIP needs to boil the ocean here. We
> need a base level mechanism to make the transport
> of secured SIP messages. Picking one in fact
> complicates the matter by unnecessarily
> constraining the design space of what is really a
> system architecture issue.

The idea isn't to pick one and say you can't use any alternatives - just to
pick one so that SIP entities will be interoperable; then system architects
can use others as they like to streamline deployments, but without
threatening interoperability.

Again, TLS has no need to boil any oceans over this. You may not favor its
key exchange mechanisms, but it does have mechanisms that all endpoints will
support.

> 
>  > Or at least, in the absence of concrete mechanisms for 
> these I'd think there
>  > would be a significant argument that the bis06 profile of 
> TLS (for which
>  > we're specifying a more encompassing minimum ciphersuite) 
> is more likely to
>  > be interoperable.
> 
> I think SIP mainly needs to mind its own business.
> Picking winners and losers in the authentication
> game is *wildly* out of charter, IMO.

I thought that we were charged by the IESG to identify the tools could be
used to secure our protocol - not to put out a protocol and assume somebody
else in the IETF, or worse various vendors/service providers, must determine
how to apply security to it before it can be deployed. 

I understand that we need to choose something, not exclusively but
minimally, that goes into our Security Considerations section. Again, this
is perhaps something for the IESG to clarify.

> 	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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 17:00:07 -0800 (PST)

> regardless of what IPSec is minimally capable of supporting, or what other

   I don't actually care a lot about this. That is,
   picking an encryption algorithm would be acceptible
   to me too. I'm just trying to point out that a
   minimum which didn't encrypt would be a lot better
   than nothing, and would be acceptible as a minimum
   must implement to me.

 > threatening interoperability.

   Specifying one will not get you any closer
   to interoperability if you want meaningful
   access control. You run into the infamous
   "global PKI" as the next on the agenda. I
   think steering well clear of this is by far
   the most prudent.

 > how to apply security to it before it can be deployed. 

   The Security Area doesn't even talk with a
   single voice in this area. Why should SIP?

 > is perhaps something for the IESG to clarify.

   A MUST IMPLEMENT implies that it is required
   for interoperability. As I said before, that is
   a false illusion; you will be stopped cold by
   the mythical global PKI. This cannot be
   settled in the IETF except to provide the tools
   to let reality decide.

		Mike

---

From: Allison Mankin <[email-masked]>
Date: Tue, 29 Jan 2002 04:15:10 -0500

> how to apply security to it before it can be deployed. 

Jon has this exactly right.  The IESG has required the SIP spec to
describe a threat model and provide security mechanisms to address
the threats, otherwise bis will not be approved.

> is perhaps something for the IESG to clarify.

IESG requires the spec to provide a minimum interopable set of
mechanisms.  Each, where appropriate, must define minimum mandatory-to-
implement encryption and authentication algorithms.  Other security 
implementations are not excluded; also IETF specs do not mandate use or 
how security is configured in use, just the presence in products of
interopable implementations.

A minimum interoperable IPsec specification for SIP is a TODO 
item (for the sip security design team, I think), because
those who expect to deploy SIP with IPsec will benefit from
shared recommendations on it.  An IPsec profile includes specific
minimum algorithms, as well as keying techniques/modes, and 
statements of limitations.

Allison
Transport Area Director for SIP