Subject: [sipcore] Fwd: SecDir review of draft-ietf-sipcore-sip-websocket-08

From: Adam Roach <[email-masked]>
Date: Wed, 10 Apr 2013 16:29:37 -0500

A representative from the security directorate has weighed in on his 
opinion of the SIP over WebSockets document, and believes we may have 
additional work to do. I plan to spend some time wading through the 
specific comments and determining which ones indicate a need to change 
the document versus that that merely require an explanation for Yaron's 
benefit, but it will be a while before I have time to do so.

If anyone else is in a position to perform that analysis and propose 
explanations and/or proposed document edits, please feel free to hop in 
and do so.

/a

-------- Original Message --------
Subject: 	SecDir review of draft-ietf-sipcore-sip-websocket-08
Resent-Date: 	Wed, 10 Apr 2013 16:19:04 -0500 (CDT)
Resent-From: 	[email-masked]
Resent-To: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Date: 	Thu, 11 Apr 2013 00:18:46 +0300
From: 	Yaron Sheffer <[email-masked]>
To: 	IETF Security Directorate <[email-masked]>, The IESG 
<[email-masked]>, [email-masked]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines how SIP can be layered on the WebSocket protocol.
This is essentially a profile of SIP.

Summary

In my opinion, from a security perspective this document is not yet
ready for publication. I expect this document to be widely implemented,
and I would not want it implemented until it offers a solid security
model, even if it is optional.

Details

RFC 3261 has 20 pages of security considerations, and defines several
security mechanisms. The current document "only" defines a transport for
SIP, but such transport needs to preserve the security of any SIP
mechanisms being used. In particular, it should be clear how endpoint
identities are determined at each layer and how identities at different
layers relate to one another. In other words, what's known as "channel
binding".

The only security-related section (other than the Security
Considerations) is Authentication (Sec. 7), and this section is marked
non-normative. So the reader is left to wonder: how is the SIP client
authenticated? How does this authentication relate to the
WebSocket-level client authentication? And similarly for the server.

Sec. 9.1 mentions (again, non-normatively) that SIP-level certificate
checks are omitted, and replaced by transport-level checks only. I
believe this significantly reduces the security properties of SIP.
Moreover, it begs for a policy tying WebSocket certificates to
identities of the endpoints of the SIP protocol.

Nit/bug: Sec. 5.2.1 ends with a colon in the HTML version *only*, and is
missing a paragraph.

Thanks,
	Yaron

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Apr 2013 00:18:39 +0800

From first reading of the comments, my take is that this is going to 
require new normative text in the document. It isn't obvious to me what 
that text should be, but I suspect it is non-trivial. I think it will 
require mapping the http/https security models onto the sip security model.

I'll also note that since this is the first of several "X over 
Websockets" drafts, that it may set the pattern for what each of those 
will need to do.

I don't feel like I am strong enough on security issues to do this well. 
It would be great if we can find a volunteer strong on both SIP and 
security.

	Thanks,
	Paul

On 4/11/13 5:29 AM, Adam Roach wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>