Last Call Review of draft-ietf-nfsv4-rfc3530bis-dot-x-16
review-ietf-nfsv4-rfc3530bis-dot-x-16-secdir-lc-nystrom-2013-04-18-00

Hi IÃaki,

I apologize for my delayed response. Please see my comments below. I am
still of the opinion that you should change the security "attitude" in
the draft from descriptive (non-normative) to prescriptive.



I also note below that leaving the security details essentially open 


also hurts the interoperability of the protocol.




Thanks,
	Yaron

On 2013-04-12 16:17, IÃaki Baz Castillo wrote:



Please let me one comment more about this at the end of this mail:



2013/4/11 IÃaki Baz Castillo <ibc at aliax.net>:



2013/4/10 Yaron Sheffer <yaronf.ietf at gmail.com>:




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".




IMHO there is no a "channel binding". It may be or not, that's up
to the implementor. For example an implementor could use the same
WS connection and carry SIP registrations and calls from different
SIP accounts over the same WS connection. Another implementor may
associate (at server side) each WS connection with a SIP identity
(for example the SIP identity could be provided in a URL parameter
in the WS HTTP GET request, or retrieved from a Cookie in the same
HTTP request).

Honestly I don't think we should force a specific behavior here.
When SIP is transported over TCP there is no rules in RFC 3261
stating that the endpoint is associated to the TCP connection, same
here IMHO.




Channel binding only applies when the layers are both secure. So TCP is
not interesting here, but TLS is. The second alternative you propose
(using WS information to identify the SIP entity) raises some questions:
what if I have logged in (to WS) as Yaron, but then I SIP-register or
SIP-invite as IÃaki? Dealing with such issues requires a policy, and you
need to at least mention it. Solving these issues securely probably
requires more than policy, it requires actual binding between the layers
(using some TLS-generated material when setting up the SIP connection).

The easiest way out is to say that there's no authentication at the WS
layer. But then you also lose confidentiality.








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.




IMHO we should leave this as flexible as possible. For example, as
author of OverSIP (the first SIP proxy with WebSocket support) I
leave the user to program it custom logic for
authenticating/authorizing WebSocket connections and the SIP
"layer" on top of them. From section "WebSocket
authentication/authorization" at


http://oversip.net/documentation/misc/sip_websocket/:




------------------------------------------------------------------
WebSocket authentication/authorization

When a WebSocket client attempts to establish a WebSocket
connection, OverSIP invokes user programmable callbacks. The user
can there inspect parameters from the connection (including the
HTTP GET request of the WebSocket handshake) in order to decide,
based on any custom policy, whether to allow or deny the
connection.

The user can also assign custom parameters to the authorized
WebSocket connection and retrieve such parameters when processing
SIP requests coming through that WebSocket connection. By playing
with these features several architectural solutions can be built
for implementing any kind of authentication/authorization system.
------------------------------------------------------------------




This might work well for your implementation's target audience. But the


RFC should allow implementers who are NOT security experts to build a 


secure implementation. I *think* most implementers of your draft will 


not be building open frameworks like your own implementation. They will 


be building actual UAs/servers that need to be secure.









About the above subject, I strongly consider that the draft MUST NOT
mandate how the implementor should authenticate/authorize WebSocket
connection/authentications or how he should correlate WebSocket
connections with SIP identities. If we mandate that then we are
limiting web developers. There are tons of ways in WWW world for
authenticating and authorizing connections/sessions, IMHO we should
not mandate nothing at the WebSocket layer because that is out of
the scope of the draft (which indeed just defines WebSocket as a new
transport for SIP, but does not attempt to deal with WebSocket
authentication/authorization).

Please take into account that RFC 6455 (The WebSocket Protocol) does
NOT state how authentication/authorization in WebSocket sessions
should be implemented. Instead it leaves full flexibility to web
developers for choosing their preferred mechanism. Why should this
draft mandate that at *WebSocket* level? does RFC 3261 state
something about how a SIP proxy should accept or not SIP TCP
connections from certain IP addresses?

The draft could mandate something like:

"HTTP Digest authentication is required at WebSocket level when
establishing the WS handshake, and later HTTP Digest authentication
MUST be used for every SIP request over such a WS connection, and
both credentials must be the same and...".

That would be a big error, and that would just work if we assume
that "SIP over WebSocket" is just valid for creating a pure phone in
a web (out of the context of the website itself) which would just
become a replacement for desktop phones or softphones. That's fully
wrong. There are a lot of possible scenarios for "SIP over
WebSocket":

- A social network, which *already* has its
login/authentication/session/authorization mechanism, could include
SIP over WebSocket for enabling RTC between its users. No need for
Digest auth at all since the user was *already* logged in the web
site and thus the server(s) can correlate the HTTP session with the
WebSocket connection (via Cookies, a custom token or whatever).

- Another web site could provide a "Web <--> PSTN" application in
which the user has to set his SIP information (SIP account, SIP
proxy, SIP password...).

- etc etc


So, I strongly think that the draft is correct in this subject.
Mandating how authentication must be done would limit the scope of
this SIP transport and would make it 100% unusable for most of the
existing web deployments.






I agree that it would be a mistake to mandate a specific auth mechanism 


for SIP or for WS. I think you should mandate that (any) such mechanism 


be used (and maybe give a few examples). And you should provide tools 


(like a header, a cookie format...) to build the correlation.






Please also note that leaving these details open means that effectively, 


you will not have interoperability. You might want to consider mandating 


some minimal mechanisms so that you can have an interoperable *and* 


secure baseline.









Best regards.



-- IÃaki Baz Castillo <ibc at aliax.net>