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

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Aug 2006 00:03:43 -0700

End to end certificates seem like they would be used with the S/MIME  
portion of SIP. I don't think anyone has been suggesting one should  
mandate that. I don't think we should confuse the TLS stuff with end  
to end security.

With the TLS stuff you only compare the name in the certificate to  
the next hop that you are routing too. I think this is fairly well  
defined and lots of people have implemented that part of 3261. (I  
agree there are problems with implementing sips but again, I don't  
think anyone is talking about using sips here).

I will note that many enterprises today peer IM with folks like MSN/ 
Yahoo/AOL using SIP and it is mostly done over TLS.

Anyways, it sounds like we are coming to some agreement for the type  
of TLS thing we are interested - which is TLS transport and not end  
to end and not sips, RFC 3261 is adequately specified and implementable.

Cullen

On Jul 27, 2006, at 6:37 AM, Lee, Yiu wrote:

> 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

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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 1 Aug 2006 10:24:08 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 3:04 AM
> To: Lee, Yiu
> Cc: [email-masked]
> Subject: Re: TLS for peering (wasRE:Comments

Yes but that is edge to edge, not end to end.

I'm convinced that we are going to make very little progress unless we state
that the first iteration here of speerming is really edge to edge oriented.

I agree that anything that looks like end to end is rat hole #32

> to end and not sips, RFC 3261 is adequately specified and implementable.

Yes ..

---

From: Andrew Newton <[email-masked]>
Date: Tue, 01 Aug 2006 14:11:07 -0400

> that the first iteration here of speerming is really edge to edge oriented.

I'm lost.  What problem is being solved by this solution?

-andy

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 02 Aug 2006 10:50:14 +0200

Cullen Jennings wrote:
> ...
> I will note that many enterprises today peer IM with folks like 
> MSN/Yahoo/AOL using SIP and it is mostly done over TLS.
> 
> Anyways, it sounds like we are coming to some agreement for the type of 
> TLS thing we are interested - which is TLS transport and not end to end 
> and not sips, RFC 3261 is adequately specified and implementable.

Yes. But I still vote against some SIP layer domain validation 
(comparing the domains in the certificate with the domains in the URIs) 
as suggested in RFC3261.

regards
klaus

>>> a TLS session between A and T and a TLS session between T and B. So we
>>
>>>> the call.  We all agree that TLS is underspecified in 3261.  There is
>>
>>>> it authenticates B as a peer with whom it can send calls destined for
>>> B.
>>>
>>> When using SSL/TLS to secure a transport connection, there are several
>>
>>> 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
>>
>>> If B receives a call from T, which is originally from an other service
>>
>>> RFC3261 and Rohan's draft) must be removed as it does not work in many
>>
>>>>>> agreement on a CA, then each peer can have a certificate that other
>>
>>>>>> peers can verify.
>>>>>> I
>>>>> the L5 validation (validate the certificate domain names against the
>>
>>>>> domains in the SIP headers) does not work without mandating a B2BUA.
>>>>>
>>>>> alone should have people think a little more before defining TLS for
>>> SIP.
>>>>> provider too. As transit will happen I will use the transit scenario
>>
>>>>> 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
>>>>>
>>>>> validates T's certificate, the validation will fail. IMO this can be
>>
>>>>> How should T's certificate be validated? Probably against the domain
>>
>>>>> it's call to C. The suggested L5 validation will fail (except B uses
>>
>>>>>> This does not assume sips works (whatever that means), and does not
>>>>> assume
>>>>>> standardization).  Thus, I personally think mandating TLS is a good
>>>>> thing,