Subject: RE: [Speermint] TLS related requirements for speermint ID

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 11:23:37 -0400

This looks to be a good start.

Re: self-signed certs

If bi-lateral, possible manual setups are considered, you might also
look at the possibility that the two parties simply cross-certify each
other.

A signs a certificate for B and 
B signs a certificate for A 

The end result would then just be a much shorter certificate path to
follow, while leaving the general process for validation the same.

Mike

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 11:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] TLS related requirements for speermint ID
> 
> All,
>  
> --- pre-amble
> At the interim meeting, we had a consensus that the goal of 
> the requirement document is not to mandate the use of any 
> protocol mechanisms, but when those mechanisms are in use, we 
> should describe what's required to guarantee some levels of 
> interoperability.
> While the focus of this msg is TLS, it was also noted that 
> other mechanisms intended to secure the lower layers of 
> session peering like IPSec or L2/L3VPNs may exist or co-exist 
> with L5 session security based on the threat models, keying 
> exchange capabilities and trust relationships... FFS based on 
> threat model.
> (just wanted to note upfront this so that the thread does not deviate)
> 
> --- TLS:
> At the wg's interim meeting, folks thought it would be good 
> to add more details on what's required for 2 VSP/ASPs to 
> "turn on" or use TLS (if/when it is enabled). The comment was 
> that the BCP/requirement draft should go a level deeper than 
> just saying "MUST support TLS". 
> 
> Here is some very first text to propose some directions. This 
> is for review based on the SIP and SIPPING work on Identity, 
> use of TLS, and the 2 I-Ds from Rohan and Vijay referenced below.
> 
> The intent here is to capture what 2 VSPs/ASPs should discuss 
> and agree on in order to establish a TLS connection for sip 
> session peering (pending the threat analysis document).
> 
> 
> --- 1. Peers SHOULD mutually trust each other's root CAs
> - Motivations:
> A VSP/ASP should have control over which root CA it trusts; 
> this may imply creating a certificate trust list to include 
> the peer's CA for each authorized domain.
> This requirement allows for the initiating side to verify 
> that the server cert is rooted in a well-known CA.
> - Derivative requirement:
> SIP servers SHOULD allow the configuration of certificate 
> trust lists in order to allow a VSP/ASP to control which 
> peer's CAs are trusted for TLS connections.
> 
> --- 2. Peers SHOULD indicate whether their domain policies 
> require proxy servers to inspect and verify the identity 
> provided in SIP requests per RFC 4474.
> 
> --- 3. When TLS is used between peers, SIP servers involved 
> in the session establishment MUST have valid X.509 
> certificates and MUST be able to receive a TLS connection.
> 
> Motivations:
> If TLS is supported for session peering, SIP servers must have valid
> X.509 certificates and they should listen on the SIP TLS port 
> for incoming connections.
> 
> --- 4. The following TLS/SIP Protocol parameters SHOULD be 
> agreed upon as part of session peering policies:
> 	+ The version of TLS (TLSv1, TLSv1.1)
> 	+ The SIP TLS port (default 5061)
> 	+ The server-side session timeout (default 300 seconds)
> 	+ The list of supported or recommended ciphersuite
> 	+ list of trusted root CAs
> 
> 
> --- 5. SIP entities involved in the session establishment 
> exchanges MUST follow the following requirements:
> 		+ check certs : 
> "the client certificate MUST contain a DNS or URI choice type 
> in the subjectAltName which  corresponds to the domain 
> asserted in the host production of the From header URI." 
> (from Rohan's I-D)
> 		+ check identity in cert per section 4 of 
> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt?
> 		+ add details and pointers to the use of RFC 
> 4474 inter-domain.
> 
> ==> open questions:
>     These are best current practices that should be followed. 
> We can either reference the work-in-progress IDs or paste 
> some of the most relevant text and then refer to the I-Ds.
> 
> REFERENCEs:
> 	- Rohan's direct peering draft
> http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct
> -peering-0
> 0.txt,
> 	- Vijay's
> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt:
> 
> --- 6. A session peering policy SHOULD include details on SIP 
> session establishment over TLS (see above, to be briefly 
> summarized1111).
> 
> 
> --- Open questions:
>  - should we re-iterate the requirement of RFC 4474 that 
> self-signed certs should not be trusted unless prior key 
> exchange has occurred?
> Given the goals of speermint, should there be more guidance 
> on the use of self-signed certs?
> - should there be a minimum set of ciphersuites to recommend 
> or leave it open?
> 
> 
> Is this on the right track and what folks had in mind?
> 
> Comments and input are appreciated.
> Jean-Francois.
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 27 Oct 2006 10:02:02 -0600

Hi,

Reinaldo wrote:
> For TLS specifically, isn't it better just to say peers should follow
> RFC4346 (or 2246) it they want implement TLS? Is there a need to say
> that peers need to agree on a port?! This is a built-in requirement
> for
> DNS/ENUM, SIP, and any layer 4 protocol out there. Do not take it the
> wrong way but it seems stating the obvious.
> 
> As for the more security related things, TLS already have built-in
> capabilities for cipher negotiation and mutual-challenge. If something
> fails they will get an error saying "negoiation failed", "cipher suite
> invalid", or something like it. Specifying the minimum set of cipher
> suites is a slippery slope (remember the minimum codec thread...).
> 
> It _seems_ to me we are compensating the general lack of TLS
> understanding by trying to summarize the most basic TLS requirements.
> IMHO we should only mention those things that somebody after reading
> the
> RFCs and/or going through a basic server-server configuration process
> cannot figure out.
> 
> A "list of trusted root CAs" is something less obvious and specific to
> peering. I'm sure there are others.

Suggestions welcome.

On your point about not listing the obvious things, I would tend to
disagree. The intent was to get into a little bit more details and
starting with the obvious does help get quick agreement to focus on the
harder things.
First, we all tend to take some shortcuts when implementing things (side
note, check this:
http://www.ietf.org/internet-drafts/draft-ietf-tls-interoperability-00.t
xt ).
Second, having a list of parameters that should be statically or
dynamically negotiated (and hence dynamically configurable on sip
routing server engines on a per route basis) could help many folks. 
As an enterprise sysadmin trying to configure TLS parameters for an
outbound SIP proxy aimed at terminating sip sessions to 2 different
peers, the first things you ask yourself are those basic questions for
each peer. And the answers are "it depends to the host you want to
connect to".

Jean-Francois.