Subject: Re: [Insipid] Addressing security-related comments / requirements spec

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 Oct 2013 09:59:49 +0000

Christer,

I would expect use of the Session ID to be broader than just debugging.  
I mentioned at least one application previously, such as associating 
call signaling and media flows.  This may still fall into the category 
of troubleshooting, but there may be uses that are beyond that.  So, I 
do not want to assume that once we complete the work, it will only be 
used for troubleshooting.

Even in that limited use case, we still want to ensure that it did not 
change end-to-end.  My thought was that over any untrusted link, we 
would utilize TLS.  However, I did not think we need to spell that out 
in the requirements document.  That said, Vijay definitely felt there 
was more we needed to say.

Do others agree that we need to say more in the Security Considerations 
section or shall just publish the document as-is.  I'll note his 
comments are non-blocking.

Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 9/28/2013 2:13:59 PM
Subject: Re: [Insipid] Addressing security-related comments / 
requirements spec
>Hi,
>
>
>
>If it's used for trouble shooting, the only harm that someone can do by 
>removing/modifying the header field is to make the trouble shooting a 
>little more difficult. I don't see any security threat in that.
>
>
>
>Regards,
>
>
>
>Christer
>
>
>
>
>
>--------------------------------------------------------------------------------
>From:[email-masked] [[email-masked]] on behalf of 
>Paul Kyzivat [[email-masked]]
>Sent: Saturday, 28 September 2013 7:04 PM
>To:[email-masked]
>Subject: Re: [Insipid] Addressing security-related comments / 
>requirements spec
>
>On 9/27/13 11:38 AM, Paul E. Jones wrote:
> > Paul,
> >
> > The impact of an attack depends on the use of the Session ID.  If 
>it's
> > used only for troubleshooting a call, then it hinders the ability to
> > troubleshoot calls.  If someone were to use this to correlate call 
>legs
> > in an effort to do billing (which is explicitly forbidden in the
> > solution spec), then the operator would have a horrible billing mess 
>on
> > their hands.
> >
> > I expected the solution spec would have more in terms of security
> > considerations, since we can speak more concretely.  We should make
> > decisions about whether we want to mandate use of TLS, how trust 
>might
> > be established, etc.   We spell out procedures so that we minimize 
>the
> > probability that two devices will have the same UUID, for example.  
>This
> > meets part of the requirements, but does not fully address the 
>security
> > issues.
> >
> > In any case, we do have some known threats (e.g., spoofing, re-play, 
>bad
> > implementation, malicious SBCs).  We know the impact of any 
>successful
> > attack (basically rendering it useless, misleading applications that 
>use
> > it, etc).  And so that's why we have the language in the requirements
> > document now that requires a random, long value, verification by
> > applications using the session identifier, secure transport,
> > authentication, etc.  I thought what we had written was sufficient 
>for a
> > requirements document, but Vijay disagreed.
> >
> > So, what do we add?
>
>I don't know.
>
> > Paul
> >
> > ------ Original Message ------
> > From: "Paul Kyzivat" <[email-masked]>
> > To: [email-masked]
> > Sent: 9/26/2013 11:23:07 AM
> > Subject: Re: [Insipid] Addressing security-related comments /
> > requirements spec
> >> ISTM that what is lacking is a threat analysis. What bad things 
>could
> >> happen if an adversary was able to change/remove/add a Session-ID
> >> header in a malicious way? Maybe nothing sufficiently bad can happen
> >> to justify anyone bothering to do so.
> >>
> >>  Thanks,
> >>  Paul K
> >>
> >> On 9/25/13 9:58 PM, Paul E. Jones wrote:
> >>> Folks,
> >>> Vijay Gurbani provided feedback suggesting some improvements might 
>be
> >>> needed in the requirements document. See this message:
> >>> 
>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10419.html.
> >>> I'm
> >>> referring specifically to his comment on Section 7.
> >>> We had a couple of follow-up messages that you should probably also
> >>> read:
> >>> 
>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10437.html
> >>> 
>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10507.html
> >>> After reviewing his comments, I would like to ask the group what, 
>if
> >>> any, changes the group feels we should make to the requirements
> >>> document.
> >>> Thanks!
> >>> Paul
> >>>
> >>>
> >>> _______________________________________________
> >>> insipid mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/insipid
> >>>
> >>
> >> _______________________________________________
> >> insipid mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/insipid
> >
> > _______________________________________________
> > insipid mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/insipid
> >
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Oct 2013 10:46:24 +0000

Hi,

Well, then I guess the security aspects depends on what the header field is actually used for. I see no reason to e.g. mandate encryption in pure trouble shooting scenarios.

Regards,

Christer

From: Paul E. Jones [mailto:[email-masked]]
Sent: 2. lokakuuta 2013 13:00
To: Christer Holmberg; Paul Kyzivat; [email-masked]
Subject: Re: [Insipid] Addressing security-related comments / requirements spec

Christer,

I would expect use of the Session ID to be broader than just debugging.  I mentioned at least one application previously, such as associating call signaling and media flows.  This may still fall into the category of troubleshooting, but there may be uses that are beyond that.  So, I do not want to assume that once we complete the work, it will only be used for troubleshooting.

Even in that limited use case, we still want to ensure that it did not change end-to-end.  My thought was that over any untrusted link, we would utilize TLS.  However, I did not think we need to spell that out in the requirements document.  That said, Vijay definitely felt there was more we needed to say.

Do others agree that we need to say more in the Security Considerations section or shall just publish the document as-is.  I'll note his comments are non-blocking.

Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]<mailto:[email-masked]>>
To: "Paul Kyzivat" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 9/28/2013 2:13:59 PM
Subject: Re: [Insipid] Addressing security-related comments / requirements spec
Hi,

If it's used for trouble shooting, the only harm that someone can do by removing/modifying the header field is to make the trouble shooting a little more difficult. I don't see any security threat in that.

Regards,

Christer

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Paul Kyzivat [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, 28 September 2013 7:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Insipid] Addressing security-related comments / requirements spec
On 9/27/13 11:38 AM, Paul E. Jones wrote:
> Paul,
>
> The impact of an attack depends on the use of the Session ID.  If it's
> troubleshoot calls.  If someone were to use this to correlate call legs
> solution spec), then the operator would have a horrible billing mess on
> their hands.
>
> decisions about whether we want to mandate use of TLS, how trust might
> be established, etc.   We spell out procedures so that we minimize the
> probability that two devices will have the same UUID, for example.  This
> meets part of the requirements, but does not fully address the security
> issues.
>
> In any case, we do have some known threats (e.g., spoofing, re-play, bad
> implementation, malicious SBCs).  We know the impact of any successful
> attack (basically rendering it useless, misleading applications that use
> authentication, etc.  I thought what we had written was sufficient for a

I don't know.

> From: "Paul Kyzivat" <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
>> ISTM that what is lacking is a threat analysis. What bad things could
>>> Vijay Gurbani provided feedback suggesting some improvements might be
>>> After reviewing his comments, I would like to ask the group what, if
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
insipid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 02 Oct 2013 16:16:52 +0000

Christer,

I would assume that we do need to ensure what was specified in the 
security considerations, i.e., we need to use long, random identifiers, 
provide sufficient security to prevent rogue entities from re-using 
identifiers, etc.  I believe it's reasonable to assume this is as 
valuable as the Call-ID, for example.

But, what I need is to know how to answer Vijay's comments.  Do you or 
others think we should add or change the requirements draft as it's 
written now?

Paul

------ Original Message ------
From: "Christer Holmberg" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Paul Kyzivat" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 10/2/2013 6:46:24 AM
Subject: RE: [Insipid] Addressing security-related comments / 
requirements spec
>Hi,
>
>
>
>Well, then I guess the security aspects depends on what the header 
>field is actually used for. I see no reason to e.g. mandate encryption 
>in pure trouble shooting scenarios.
>
>
>
>Regards,
>
>
>
>Christer
>
>
>
>>If it's used for trouble shooting, the only harm that someone can do 
>>by removing/modifying the header field is to make the trouble shooting 
>>a little more difficult. I don't see any security threat in that.
>>
>>
>>
>>Regards,
>>
>>
>>
>>Christer
>>
>>
>>
>>
>>