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

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 26 Sep 2013 01:58:05 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Sep 2013 11:23:07 -0400

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:
> 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:
> 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
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 27 Sep 2013 15:38:13 +0000

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?

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
>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
>
>>I'm

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 Sep 2013 12:04:21 -0400

> requirements document, but Vijay disagreed.

I don't know.

>> header in a malicious way? Maybe nothing sufficiently bad can happen
>> to justify anyone bothering to do so.
>>
>>  Thanks,
>>  Paul K
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Sep 2013 18:13:59 +0000

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

I don't know.