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

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Nov 2005 10:26:01 -0800

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.  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.  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: Cullen Jennings <[email-masked]>
Date: Sun, 27 Nov 2005 05:54:13 -0800

One change inline due to comment I got ...

On 11/26/05 10:26 AM, "Cullen Jennings" <[email-masked]> wrote:

> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-ses
> sions.html 
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-ses
> sions.txt
> 
> required to bind the certificate to one of the communication endpoints.
Insert something like ...

"Unlike normal TLS operations in this protocol, when doing peer to peer TLS,
the"

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 27 Nov 2005 11:21:24 -0800

On Nov 26, 2005, at 10:26, Cullen Jennings wrote:

> mechanism

[22]

> .  The rest of this section describes the details of this approach.
>
> distinct, unique certificate MUST be used for this purpose.  For an

s/an/a/

> client

Because the generation....., endpoints...

> been tampered with after the digital signature was added to the SIP  

do we want to mention response integrity?

thanks,
-rohan

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 28 Nov 2005 10:44:25 +0100

On Nov 26, 2005, at 7:26 PM, Cullen Jennings wrote:

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