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

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 19 Oct 2006 09:36:46 -0600

Mike,

   Thanks for the comments.

Mike wrote:
> 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

Do we consider these as part of best current practices or even something
worth logging in a requirement doc?
I originally wondered whether we should mention this. Folks will do this
anyway and it keeps re-inforcing the small clubs/federation models with
limited scale as opposed to open, flexible and dynamic peering.

That said, I'm open to adding a sentence to mention this case if folks
believe it should be explicitly captured as a possibility.
 
> The end result would then just be a much shorter certificate path to
> follow, while leaving the general process for validation the same.

Jean-Francois.

> 
> 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: "Reinaldo Penno" <[email-masked]>
Date: Thu, 19 Oct 2006 12:58:41 -0400

Hello Jean,

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.

Regards,

Reinaldo

> > --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed 
> > upon as part of session peering policies:

> Sent: Thursday, October 19, 2006 8:37 AM
> To: Michael Hammer (mhammer); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Speermint] TLS related requirements for speermint ID
> 
> Mike,
> 
>    Thanks for the comments.
> 
> Mike wrote:
> Do we consider these as part of best current practices or 
> even something worth logging in a requirement doc?
> I originally wondered whether we should mention this. Folks 
> will do this anyway and it keeps re-inforcing the small 
> clubs/federation models with limited scale as opposed to 
> open, flexible and dynamic peering.
> 
> That said, I'm open to adding a sentence to mention this case 
> if folks believe it should be explicitly captured as a possibility.
>  
> > > 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.
> > > 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).
> > >
> > >
> > > 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.
> that the 
> > > server cert is rooted in a well-known CA.
> > > 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:
> > > 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 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)
> > > 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:
> 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?
> > >
> > >

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 18:00:25 +0200

> wrong way but it seems stating the obvious. 

IMO it makes sense to define a TLS port overruling the default (rfc3263) 
port - e.g. if you need to present different certificates to different 
peers you need different sockets. Using "portoverride" allows it to 
redirect certain peers to certain ports.

> RFCs and/or going through a basic server-server configuration process

TLS guidelines are very important because the standards are not enough 
(as drafts like draft-gurbani-sip-domain-certs proove).

> peering. I'm sure there are others.

I thought these are the settings for dedicated peering policies - e.g. 
bilateral or federation peering. Then IMO it makes sense to tell the 
peers that they should agree on a CA.

regards
klaus

-- 
Klaus Darilion
nic.at