Subject: [Speermint] TLS related requirements for speermint ID

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 09:38:20 -0600

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

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 15:26:40 +0200

Hi Jean-Francois!

Great that the TLS stuff is getting a shape.

comments inline

> server cert is rooted in a well-known CA.

Please keep in mind 2 different scenarios:
1. certificates signed by well known/trusted CAs (e.g. Thawte)
2. self-signed certificates

In case 1, a VSP installs the root CA of the trusted CA.

In case 2, usually the VSP does not install the peers CA, but rather 
signs the peers certificate with its own CA cert.

> order to allow a VSP/ASP to control which peer's CAs are trusted for TLS

ACK. At best this should be allowed on a per-call basis, not globally 
for all TLS connections.

<shameless advertisement>
At the openser summit during VON Europe I will give a talk how to do 
this with openser. 
http://www.openser.org/index.php?option=com_content&task=view&id=60&Itemid=72
</shameless advertisement>

> servers to inspect and verify the identity provided in SIP requests per

This can be done either implicitly via federation policies or explicitly 
via dedicated policy NAPTRs (draft-lendl-speermint-technical-policy)

> X.509 certificates and they should listen on the SIP TLS port for

Maybe "valid" should be described in more detail. not expired, not self 
signed, hostname in the cert vs. hostname of the server, CA, ...?
> 	+ The server-side session timeout (default 300 seconds)
is this the time until an idle TLS conenction is closed?
> 	+ list of trusted root CAs
maybe also the certificate itself. Maybe a VSP has different 
certificates for different purposes.

more next week. have a nice weekend
klaus

-- 
Klaus Darilion
nic.at

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 17:49:20 +0200

Here Part 2 :-)

> production of the From header URI." (from Rohan's I-D)

We MUST NOT enforce this check, as it does not work with retargeting and 
transit scenarios.

> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt?

Does that mean that as soon as one of the identities in the certificate 
matches the hostname or SIP domain the validation is sucessful?

By no means we may prevent the following example:
- user has SIP URI [email-masked]
- user hosts the SIP service at itspA

Thus, user's SRV points to itspA's ingress point:
_sips._tcp SRV 10 10 5060 sip.itspA.com

RFC3261 requires that itspA needs to present a certificate for user.com. 
But this is not scalable and not desirable - I won't give my private key 
to my ITSP, no, never.

Thus, it should be sufficient that the hostname matches the identity 
inthe certificate.

> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt:

draft which become RFC can be referenced. Drafts which will not become 
RFCs should be reused.

> certs should not be trusted unless prior key exchange has occurred?

IMO self-signed certificates are not different to certificates signed by 
3rd parties - you have to trust the CA. Thus, usually self-signed 
certificates are not signed by the certificate owner, but by the peer 
which authenticates.

> Given the goals of speermint, should there be more guidance on the use

IMO yes, because this confuses people a lot.

> - should there be a minimum set of ciphersuites to recommend or leave it

IMO I would leave it open. Are there similar requirements for https 
....? AFAIK not, but it works.
> Is this on the right track and what folks had in mind?

Yes, this is the right track.

thanks
klaus

-- 
Klaus Darilion
nic.at