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

["Vijay K. Gurbani" <[e-mail]>]

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