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

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 27 Jul 2006 09:37:50 -0400

Hi Klaus,

Sorry for mis-understanding your previous post. I agree that using the
domain for the end-to-end certification is broken in federation.

Thanks for the clarification.

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 2:55 AM
To: Lee, Yiu
Cc: Brian Rosen; [email-masked]
Subject: Re: TLS for peering (was RE:Comments
(RE:[speermint]requirementsdraftsubmitted))

Lee, Yiu wrote:
> Hi,
> 
> We agree that it is difficult to enforce hop-by-hop TLS session for 
> SIPS in federation. I think we can't mandate SIPS, but we can require 
> a TLS session between A and T and a TLS session between T and B. So we

> can relax the requirement of SIPS but still provide some security to 
> transport SIP messages.

H!

Looks like I'm still not clear enough - it was not talking about SIPS. 
Only SIP which uses TLS between providers. IMO, TLS as transport is a
MUST, but the L5 certificate domain validation must not be a MUST.

regards
klaus

> 
> Thanks,
> Yiu
> 
> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Monday, July 24, 2006 11:28 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: TLS for peering (was RE:Comments
> (RE:[speermint]requirementsdraftsubmitted))
> 
> Brian Rosen wrote:
>> 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
> 
> 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.
> 
>> 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
> 
> Yes.
> 
>> 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.
> 
> 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
> 
> 
> 
>> Brian
>>
>>> -----Original Message-----
>>> From: Klaus Darilion [mailto:[email-masked]]
>>> Sent: Sunday, July 23, 2006 7:49 PM
>>> To: Brian Rosen
>>> Cc: [email-masked]
>>> Subject: RE: TLS for peering (was RE: Comments
>>> (RE:[speermint]requirementsdraftsubmitted))
>>>
>>> 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.
>>>
>>>> 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;
>>> 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
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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