Subject: RE: [Sip] TLS section

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

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. Similarly, I would think there would have
to be some story for key exchange.

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.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 3:39 PM
> To: Peterson, Jon
> Cc: 'Rosen, Brian'; 'Michael Thomas'; [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> Peterson, Jon writes:
>  > Thanks Brian, I'm actually really interested in this topic as well.
>  > 
>  > I think it would be interesting first to learn who on this 
> distribution
>  > prefers to provide lower-layer security for SIP with IPSec 
> rather than TLS,
>  > and then moreover whether those that do prefer IPSec would 
> rather use
>  > transport mode (host-by-host, integrated with SIP 
> applications) or tunnel
>  > mode (not integrated with SIP applications, using security 
> gateways).
> 
> I think the important question to ask here is how
> many people are implementing UDP UA's.
>  
>  > Just to be clear about a couple of things surrounding this 
> proposed IPSec
>  > profile:
>  > 
>  > - Can we spell out a bit what we mean by HMAC-MD5-NULL? 
> The string doesn't
>  > appear in 2406, anyway. For example, is the NULL for 
> authentication, or
>  > encryption, or both?
> 
> NULL encryption transform. RFC 2410 describes it.
> 
>  > - Will implementations supporting this profile by be 
> compliant with the
>  > minimum conformance requirements in rfc2406 section 5?
> 
> Not to the letter of the law. The only encryption
> manadatory is DES and NULL; you can say that DES
> is forbidden by policy and optimized out of the
> code (many do, actually). Beyond that, you'd need
> SHA-1, though I frankly think that might have been
> overkill.
>  
>  > - This assumes pre-shared keys, and entails no key 
> exchange capabilities
>  > (i.e. IKE), right?
> 
> Right. As in, you punt on key exchange.
> 
> 	  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 16:21:02 -0800 (PST)

Peterson, Jon writes:
 > 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.

 > Similarly, I would think there would have

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.

 > we're specifying a more encompassing minimum ciphersuite) is more likely to

I think SIP mainly needs to mind its own business.
Picking winners and losers in the authentication
game is *wildly* out of charter, IMO.

	Mike