Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08

["Paul E. Jones" <[e-mail]>]

Vijay,

Thanks for the additional feedback.  I will consult with a few of the 
folks in the WG to see how we can best address your points.

Paul

------ Original Message ------
From: "Vijay K. Gurbani" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>
Cc: [e-mail]; "'James 
Polk'" <[e-mail]>; "'IESG IESG'" <[e-mail]>; 
[e-mail]
Sent: 9/23/2013 11:29:31 AM
Subject: Re: [apps-discuss] APPSDIR review of 
draft-ietf-insipid-session-id-reqts-08
>On 09/20/2013 04:07 PM, Paul E. Jones wrote:
>>Vijay,
>>
>>(My email client did not format that well. Let me try to correct 
>>that...)
>>
>>I apologize for taking so long to get back to you. This has been an
>>extremely busy week for me.
>
>Paul: No problem. Please see inline.
>
>>I understand. I wasn't trying to be combative. Rather, I'm just
>>stating that I'm not sure what more is needed. Please don't assume I
>>was being argumentative, as that certainly was not the intent.
>
>No worries; I just wanted to make sure that if you made any changes,
>they would be driven by what you would also consider actual problems,
>and not driven by just trying to placate me :-)
>
>>I cannot recall who introduced that language into that text, but the
>>desire would be prevent two things: [...]
>>The proposed remedies in that paragraph are to mandate REQ6 and
>>encourage encryption.
>
>Right, it is the "encourage encryption" part that I think should garner
>some attention. One way to do so is suggested below.
>
>>REQ5 does not, in itself, assume or require some kind of security. In 
>>a
>>trusted service provider network, for example, the value might be
>>inserted at the edge by an SBC and no encryption used through the
>>service provider domain.
>
>SIP has developed this notion of a trust domain as a set of SIP nodes,
>including B2BUAs, that are trusted to exchange some private information
>among (and between) themselves. This function goes by the wonderful
>name of Spec(T) and is fully defined in rfc3324. Other pieces of work
>[1,2] that forsee a need to define a trust domain simply use the
>Spec(T) function to do so.
>
>>The required security differs based on the environment. As I mentioned
>>above, a service provider domain may have minimal internal security
>>requirements, placing all security at the edge. Likewise, the issues
>>related to the Session-ID are not unlike those of the Call-ID. In 
>>fact,
>>an attack on the Call-ID or "To" header in SIP is far more problematic
>>than an attack on the Session-ID. So, while I think most real-world
>>implementations of SIP (ignoring Session-ID) should use TLS, at the 
>>very
>>least, we cannot insert a requirement for use of any particular 
>>security
>>mechanism.
>
>The Spec(T) mechanism at least allows you to state that you have
>thought of the security ramifications of the header being sent out in
>cleartext, and therefore, domains that wish to exchange the header in
>non cleartext format should comply to Spec(T). You can define Spec(T)
>as is done in [1], without having to delve into the mandating TLS or
>choosing cipher specs for TLS.
>
>It seems appropriate that if we know that usurping the session
>identifier will lead to problems then we at least try to provide a way
>to mitigate these problems without mandating specific security 
>policies.
>I think Spec(T) allows you to do so.
>
>Regarding the statement that an attack on the Call-ID or "To" header
>being more disruptive than an attack on Session-ID, sure I agree. But
>at least we have rfc4474 to mitigate that (I understand it is not used
>widely, but it *is* there).
>
>>I do not disagree, but I cannot insert a requirement into this text 
>>that
>>says TLS must be used. There may be folks who would oppose that. I
>>think the particular means through which the requirements are met 
>>should
>>be spelled out only in the solution text. If you really disagree, we
>>can go back to the WG and raise the point. I certainly have no
>>objection to that.
>
>I am not privy to the discussions that happened in the working group
>along making TLS mandatory. But from your description it seems that
>the working group does not want to mandate it. Maybe couching the
>security aspects in terms of Spec(T) will suffice?
>
>[1] See Section 5.4 of 
>http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-09
>[2] 
>http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-02
>
>Thanks,
>
>- vijay
>-- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>Email: vkg@{bell-labs.com,acm.org} / [e-mail]
>Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq