Subject: RE: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraftsubmitted))

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 21 Jul 2006 06:31:25 -0700

I agree with Klaus and would like to add that the IETF success recipe
MUST (!) be maintained: Have running code and deployment experience
first before promoting anything to RFC status, even to informational RFC
status.

Only deployment is the link between a standards proposal and its
confirmation in the market, since we cannot capture or even articulate
the business models that drive a specific proposal.

One wonders how many RFCs listed at http://rfc3261.net/ are based on
running code, more than one implementation and experience from
deployment. 

Thanks, Henry

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 7:46 AM
To: [email-masked]
Subject: RE: TLS for peering (was RE: Comments
(RE:[speermint]requirementsdraftsubmitted))

Hi!

Lots of people in this group discuss the pro and cons of TLS. I wonder: 
who of you has already used SIP and TLS. Who has configured it's SIP 
proxy or client with certificates?

I have doubts that there were SIP+TLS implementations when RFC3261 was 
written - the whole TLS part in 3261 is incomplete and raises more 
questions than it solves. There are several call scenarios (e.g. a 
simple forward) in which certificate validation will fail.

Don't get me wrong - I'm a TLS fan! Thus I know there might be several 
problems with TLS which we should think about before defining TLS as
MUST.

I would really like that people use TLS for their SIP phones and proxies

BEFORE defining if TLS is MUST or SHOULD.

regards
Klaus

_______________________________________________
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: David Meyer <[email-masked]>
Date: Fri, 21 Jul 2006 07:00:31 -0700

> first before promoting anything to RFC status, even to informational RFC

	Did you notice that routing area isn't going to be
	requiring interoperable implementations (read: running
	code) for DS status anymore (or so I understand)?

	--dmm

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 21 Jul 2006 14:01:07 -0400

The part of that which confuses me is what does a MUST IMPLEMENT but not
must deploy mean in a BCP from Speermint?  Typically IETF RFCs are written
from the perspective of manufacturers of equipment. (ok, that's a gross
generalization, but you know what I mean)  So for them a MUST IMPLEMENT
means something which must be supported, but can be disabled through
configuration or some such.  

But IMO, Speermint BCPs are really written for the operators - so what does
MUST IMPLEMENT but not must deploy mean for them?  Isn't it meaningless?

-hadriel

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, July 21, 2006 12:08 PM
> To: 'Klaus Darilion'; [email-masked]
> Subject: RE: TLS for peering (was RE:Comments
> Having lived with protocols that offered options like IPsec and VPNs and
> other mechanisms, I think that despite the fact that you can, in theory,
> create a satisfactory security arrangement, it is exceedingly hard to make
> it actually work except for cases where there is an entity that completely
> controls all aspects of the peering.  That just isn't the case for what I
> think we are trying to specify here (such cases don't need IETF
> standardization).  Thus, I personally think mandating TLS is a good thing,
> achievable, and reasonable.  That's a MUST IMPLEMENT, not a must deploy;
> it's really hard to control actual deployments, and I don't think we try
> hard to do so.
> 
> Brian
>

---

From: "Klaus Darilion" <[email-masked]>
Date: Mon, 24 Jul 2006 01:48:43 +0200 (CEST)

Hi Brian!

On Fri, July 21, 2006 18:08, Brian Rosen said:
> I believe it is the case that the link from one peer to another, which is
> generally between two proxies, can very reasonably be protected with TLS,
> with many current implementations, and with reasonable assumptions about
> PKI.  Specifically, if one of the parts of a federation was an agreement
> on
> a CA, then each peer can have a certificate that other peers can verify.
> I
> believe all operations, including forwarding, if they work at all across
> the
> peering system would work if it was TLS protected.

Using TLS for encryption and TLS certificate validation works - but the L5
validation (validate the certificate domain names against the domains in
the SIP headers) does not work without mandating a B2BUA.

TLS/SSL was invented for a very simple client-server system - HTTP. Let's
compare HTTP with SIP:

HTTP:
1 request - 1 (or more) responses.
L5 validation: verify domain in browser's location bar against the domain
in the server certificate - this is straight forward

SIP:
Multiple - bidirectional requests
L5 validation: There are several headers which are used for routing and
thus can be used for validation: requestURI, From, To, Via, Route,
Contact.
We can have in-dialog requests which are initiated in reverse direction of
the original dialog setup. And each of this domain resolves to several
domains (due to NAPTR, SRV, A resolution). This alone should have people
think a little more before defining TLS for SIP.

I am a fan of forwarding - and probably every transit service provider
too. As transit will happen I will use the transit scenario (simple
forwarding without a B2BUA) to show that L5 validation is broken - and I
would be very very happy if someone can show that I'm wrong.

A want to call B. There is no direct peering agreement. Thus A sends the
call to it's transit provider T. (only the signaling between the proxies
is shown)

A->T
INVITE sip:B@B
From: sip:A@A
To: sip:B@B
Contact: user@phone
Record-Route: sip:A

Cert validation according to RFC3261 section 26.3.2.2:
T will show a TLS certificate for T (not for B) - thus, when A validates
T's certificate, the validation will fail. IMO this can be fixed by adding
a Route: header with sip:T, but this is nowhere mentioned in RFC 3261.

T->B
INVITE sip:B@B
From: sip:A@A
To: sip:B@B
Contact: user@phone
Record-Route: sip:T
Record-Route: sip:A

Cert validation according to RFC3261 section 26.3.2.2:
B should validate the domain in the From header (A) aginst the domain in
the client's certificate (T) --> it will fail.

Now let's assume the previous validation have succeeded and B sends a BYE
request to A, and the TLS connection was dropped and must be
re-established:

B->T
BYE [email-masked]
From: sip:B@B
To: sip:A@A
Route: sip:T
Route: sip:A

How should T's certificate be validated? Probably against the domain in
the topmost Route header - but again: This is nowhere specified.

T->A
BYE [email-masked]
From: sip:B@B
To: sip:A@A
Route: sip:A

Again, probably T should use the domain in the Route header for
certificate validation. But A can't validate the certificate's domain (T)
against the From header (B) - it will fail.

Similar problem arise in a forwarding scenario - A-->B which forwards it's
call to C. The suggested L5 validation will fail (except B uses a B2BUA,
and IMO a B2BUA should not be mandatory).

> This does not assume sips works (whatever that means), and does not assume
> endpoints implement TLS, or either the originating or terminating domains
> deploy TLS anywhere else.
>
> It does provide a reasonable degree of protection across the peering
> point,
> which I think is a good thing.

Yes, TLS provides protection, but we should not specify a broken L5
certificate validation.

> achievable, and reasonable.  That's a MUST IMPLEMENT, not a must deploy;

Yes, I agree. I want TLS in the specs too - but we have to specify the
validation more precisely and it has to work in other scenarios than a
basic call too. Otherwise people wont use it.

regards
Klaus

---

From: Duane <[email-masked]>
Date: Sun, 23 Jul 2006 19:55:49 -0400

> TLS/SSL was invented for a very simple client-server system - HTTP. Let's

I fail to see the difference, HTTPS requests can go via intermediate 
servers as well (aka proxy servers like squid for example)...

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

---

From: "Klaus Darilion" <[email-masked]>
Date: Mon, 24 Jul 2006 07:50:54 +0200 (CEST)

Hi!

You do not see the difference?
- Have you ever seen a web server connecting to your web browser?
- HTTP is stateless - there are no in-dialog requests (that's why we have
HTTP cookies).
- Regarding TLS: When using HTTPS, the TLS tunnel is end2end, the proxy
can't see the payload. SIP uses TLS on a hop-by-hop basis.

Do you need more differences?

regards
Klaus

---

From: Duane <[email-masked]>
Date: Mon, 24 Jul 2006 02:52:29 -0400

> Do you need more differences?

RTP can be pass through (ie untouched like https and proxy) or can 
bypass proxies and be point to point as well...

-- 

Best regards,
  Duane

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 24 Jul 2006 10:10:16 +0200

> bypass proxies and be point to point as well...

I thought we were taking about SIP. RTP has nothing to do with the L5 
certificate validation in SIP.

Regarding RTP: I can be direct or via an RTP proxy. If you use SRTP it 
can also be direct or via an RTP proxy, and depending on the method used 
to deliver the SRTP key, the RTP proxy might be able to look into the 
payload (e.g. if the key is in plaintext in the SDP). But again - 
RTP/SRTP has nothing in common with the TLS problems in SIP.

regards
klaus

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 24 Jul 2006 10:12:21 -0400

I think you are misinterpreting 3261.  Section 26.3.2.2 is illustrating a
simple SIP trapezoid call where the call goes from atlanta.com to
biloxi.com.  If there is another intermediary, biloxi.com would not be
checking the From to see that it matched the domain of the T proxy handling
the call.  We all agree that TLS is underspecified in 3261.  There is some
effort to address this shortcoming underway.

If the path is A -> T -> B, then the mutual TLS cert validation is A <-> T
and T <-> B.  In a peering system, the peers authenticate each other within
the peering regime.  If T accepts a call from A destined for B, then it
authenticates A as a peer which it accepts transit calls for B, and it
authenticates B as a peer with whom it can send calls destined for B.

Brian

> Sent: Sunday, July 23, 2006 7:49 PM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 24 Jul 2006 17:27:51 +0200

> checking the From to see that it matched the domain of the T proxy handling

How will biloxi's proxy know if the request comes directly from atlanta 
or via an intermediary? You suggest that in this case the From: 
validation is not used. Then we should remove the From: validation 
completely and validate only the Identity signature.

The only thing I want to say is that Rohan's suggested From: validation

    .... 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....

can't be mandated.

> and T <-> B.  In a peering system, the peers authenticate each other within

Yes.

> authenticates B as a peer with whom it can send calls destined for B.

Yes - but the L5 domain validation can't be used.

Maybe I express myself a little bit unclear. Thus, I describe it more 
detailed.

When using SSL/TLS to secure a transport connection, there are several 
validation steps. Some of the are done in the SSL stack, some of the are 
done in the application. I'm speaking of experience in using openssl and 
openser.

During the TLS handshake, the peers verify the certificate presented by 
the other peer. The TLS stacks of the certificate is signed by a (to the 
stack) well known CA and it is valid (not expired). Let's call this L4 
certificate validation.

Once the TLS connection is setup, the application can further validate 
the certificate, e.g. if the domain presented in the certificate equals 
the domain in the request URI. Let's call this L5 certificate validation.

To authenticate a peer, L5 is NOT necessary. For example, T and B are in 
the same federation. (B trusts T, T trusts B, and both of them trusts 
the federation's CA)

If B receives a call from T, which is originally from an other service 
provider (which T trusts), the domain in the From header is not 
important, as the authentication is based on the certificate. And B and 
T can bill each other because they were both authenticated (although 
there was no L5 validation).

Conclusion:
IMO TLS should be MUST, but the L5 domain validation (as suggested in 
RFC3261 and Rohan's draft) must be removed as it does not work in many 
scenarios and further is not needed. Nevertheless, in scenarios where it 
is useful it should be used. But a MUST is wrong.

regards
Klaus