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

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 26 Jul 2006 16:41:07 -0400

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.

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

---

From: Klaus Darilion <[email-masked]>
Date: Thu, 27 Jul 2006 08:54:53 +0200

> relax the requirement of SIPS but still provide some security to

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