Subject: [Simple] Re: Addition to security section draft-ietf-simple-message-sessions

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Dec 2005 10:28:14 -0800

Thanks - Made both theses changes in next version of document.

On 11/28/05 1:44 AM, "Hisham Khartabil" <[email-masked]> wrote:

> 
> On Nov 26, 2005, at 7:26 PM, Cullen Jennings wrote:
> 
>> 
>> During a review of this draft by a security AD, we got feedback that we
>> needed to add more about how to use TLS where there was no relays. I am
>> proposing we add an additional section 14.3 with some proposed text
>> below.
>> If you want to see this in the context of the draft, you can look at
>> what it
>> might look like at:
>> 
>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>> message-s
>> essions.html
>> 
>> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-
>> message-s
>> essions.txt
>> 
>> The text I am proposing to add is ....
>> 
>> 14.3.  Using TLS in Peer to Peer Mode
>> 
>> TLS can be used with a self signed certificate as long as there is a
>> mechanism for both sides to ascertain that the other side used the
>> correct
>> certificate.  When used with SDP and SIP, the correct certificate can
>> be
>> verified by passing a fingerprint of the certificate in the SDP and
>> ensuring
>> that the SDP has suitable integrity protection.  When SIP is used to
>> transport the SDP, the integrity can be provided by the SIP Identity
>> mechanism.  The rest of this section describes the details of this
>> approach.
>> 
>> If self-signed certificates are used, the content of the subjectAltName
>> attribute inside the certificate MAY use the uniform resource
>> identifier
>> (URI) of the user.
> 
> 
> Can you make it clear here that you are talking about the AoR?
> 
>>   This is useful for debugging purposes only and is not
>> required to bind the certificate to one of the communication
>> endpoints.  The
>> subjectAltName is not an important component of the certificate
>> verification.  If the endpoint is also able to make anonymous
>> sessions, a
>> distinct, unique certificate MUST be used for this purpose.  For an
>> client
>> that works with multiple users, each user SHOULD have its own
>> certificate.
>> The generation of public/private key pairs is relatively expensive.
>> Endpoints are not required to generate certificates for each session.
>> 
>> A certificate fingerprint is the output of a one-way hash function
>> computed
>> over the distinguished encoding rules (DER) form of the certificate.
>> The
>> endpoint MUST use the certificate fingerprint attribute as specified
>> in [23]
>> and MUST include this in the SDP.
> 
> 
> A bit more text on how to include it in SDP would be good. Example
> would be great.
> 
> Thanks,
> Hisham
> 
>> The certificate presented during the TLS
>> handshake needs to match the fingerprint exchanged via the SDP and if
>> the
>> fingerprint does not match the hashed certificate then the endpoint
>> MUST
>> tear down the media session immediately.
>> 
>> When using SIP, the integrity of the fingerprint can be ensured
>> through the
>> SIP Identity mechanism [22].  When a client wishes to use SIP to set
>> up a
>> secure MSRP session with another endpoint it sends an offer in a SIP
>> message
>> to the other endpoint.  This offer includes, as part of the SDP
>> payload, the
>> fingerprint of the certificate that the endpoint wants to use.  The SIP
>> message containing the offer is sent to the offerer's sip proxy which
>> will
>> add an identity header according to the procedures outlined in [22].
>> When
>> the far endpoint receives the SIP message it can verify the identity
>> of the
>> sender using the identity header.  Since the identity header is a
>> digital
>> signature across several SIP headers, in addition to the body or
>> bodies of
>> the SIP message, the receiver can also be certain that the message has
>> not
>> been tampered with after the digital signature was added to the SIP
>> message.
>> 

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

---

From: Aki Niemi <[email-masked]>
Date: Tue, 13 Dec 2005 14:42:06 +0200

I took a look at the version with the added text. First of all, the 
fingerprint SDP attribute is not defined anywhere in the document. It 
should.

Second, seems to me that sdescriptions would be the correct place to 
negotiate any security related data like the cert fingerprint in SDP; I 
don't understand why MSRP has to (again) invent its own mechanism. Then 
again, if the described mechanism works, I guess it is ok...

Also, I'd like the text to at least mention, that there are other 
ciphersuites available in TLS that could potentially be used with MSRP. 
For example, ciphersuites defined in RFC 4279 come to mind as something 
worth exploring along with sdescriptions, or MIKEY perhaps. (This should 
be its own specification, though.) I can propose some text, too, if 
you'd like.

Last (but not least), seems like e2e TLS is only possible when there are 
no relays, right? Then, doesn't that mean that NAT/FW traversal and e2e 
security don't work together? Doesn't that really suck, if you have to 
choose one or the other?

Cheers,
Aki

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Dec 2005 10:08:37 -0600

> security don't work together? Doesn't that really suck, if you have to 

This is a principle worthy of the IETF :-) Thanks, Aki, for sending it!

Spencer

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Dec 2005 11:04:18 -0600

Of _course_ TLS only gives us e2e when there are not intermediaries  
terminating the TLS relationship.
This additional section of text is describing how you can use TLS to  
your advantage in exactly that case.
It is not defining a new e2e mechanism for the draft, nor is it  
claiming this is the only e2e mechanism
available.

 From elsewhere in the document:

    Since MSRP carries arbitrary MIME content, it can trivially carry
    S/MIME protected messages as well.  All MSRP implementations MUST
    support the multipart/signed MIME type even if they do not support
    S/MIME.  Since SIP can carry a session key, S/MIME messages in the
    context of a session could also be protected using a key-wrapped
    shared secret [26] provided in the session setup.  MSRP is a binary
    protocol and MIME bodies MUST be transferred with a transfer  
encoding
    of binary.  If a message is both signed and encrypted, it SHOULD be
    signed first, then encrypted.  If S/MIME is supported, SHA-1, RSA,
    and AES-128 MUST be supported.

On Dec 13, 2005, at 10:08 AM, Spencer Dawkins wrote:

>> Last (but not least), seems like e2e TLS is only possible when  
>> there are no relays, right? Then, doesn't that mean that NAT/FW  
>> traversal and e2e security don't work together? Doesn't that  
>> really suck, if you have to choose one or the other?
>

---

From: Aki Niemi <[email-masked]>
Date: Thu, 15 Dec 2005 13:13:29 +0200

> terminating the TLS relationship.

That doesn't mean you couldn't deploy relay-type NAT/FW traversal while
preserving end-to-end TLS. HTTP proxies do it all the time, TURN
supports that.

> It is not defining a new e2e mechanism for the draft, nor is it claiming 
> this is the only e2e mechanism
> available.
> 
>    protocol and MIME bodies MUST be transferred with a transfer encoding

Then why specify this additional e2e mechanism based on TLS, if the 
"real" e2e security story anyway is based on S/MIME?

Cheers,
Aki

---

From: Robert Sparks <[email-masked]>
Date: Thu, 15 Dec 2005 09:21:52 -0600

On Dec 15, 2005, at 5:13 AM, Aki Niemi wrote:

>
> ext Robert Sparks wrote:
>> Of _course_ TLS only gives us e2e when there are not  
>> intermediaries terminating the TLS relationship.
>
>> This additional section of text is describing how you can use TLS  
>> to your advantage in exactly that case.

This text doesn't specify anything new. It is explanatory text,  
highlighting a possible way to use the
protocol that already existed in the document. We added this  
explanatory text at the request of one
of our Security Area ADs.

---

From: Aki Niemi <[email-masked]>
Date: Thu, 15 Dec 2005 21:04:43 +0200

ext Robert Sparks wrote:
> protocol that already existed in the document. We added this explanatory 
> text at the request of one

Well, to my reading it is specifying a new feature (á la comedia-tls) to 
enable this out-of-band cert validation for TLS. At least I haven't seen 
the fingerprint SDP attribute used in MSRP before, but I could've just 
missed it.

But thinking about this a little more, the new feature seems like a 
useful and small addition. I would still like to see TLS work e2e even 
with one or more relays, but that's not going to happen with this or 
with the relay specs. Maybe in some future extension; one can only hope. :)

The only thing that the draft should maybe elaborate a bit is to say 
when exactly this feature will work. That is, that if the SDP answer 
contains a path with more than one msrps URL, then the client shouldn't 
send a certificate in the TLS handshake (because it won't validate at 
the relay).

If the answer has a single path entry, but no fingerprint, then the 
client probably should send the certificate. That might help in 
authenticating the client a little "sooner".

Cheers,
Aki