[NSIS] RE: comments on NSIS Security Threats ID

[Tschofenig Hannes <[e-mail]>]

hi cornelia, 

please see some comments inline:

>  -----Original Message-----
> From: 	Kappler Cornelia [mailto:[e-mail]] 
> Sent:	Friday, March 12, 2004 8:35 PM
> To:	Tschofenig Hannes; [e-mail]
> Subject:	comments on NSIS Security Threats ID
> 
> Hi Hannes, 
> 
> my comments mostly relate to the structure of Sec 4 (along similar lines
as Robert was suggesting), and to problems I have understanding identity
spoofing of flow identifieres. See below. 
> 
> Cornelia
> ----------------------
> 
> *4. NSIS Specific Threat Scenarios
> 
> This Section describes "threat scenarios in terms of attacks on and
security deficiencies in the NSIS signaling protocol". I find it hard
sometimes in subsequent subsections to pick out what the attack is, and
(particularly) what the security deficiencies allowing the attack are. May
be you could add sentences clearly stating this, rather than mentioning it
in passing. 

i went through other ietf drafts on security and noticed that these terms
(threats and attacks) are used interchangeable in many cases. i will,
however, try to find a definition somewhere and see how that would be
helpful for the draft. 

> 
> In addition to Theats and Security Deficiencies may be you should add (in
a structured fashion) what possible remedies are. In most subsections this
is mentioned but not everywhere. Also I think the fact that you also discuss
remedies should be mentioned in the intro to Sec 4.

i actually tried hard to remove all solution specific aspects (or
counter-measures). it was a request to remove them.

> 
> Subsection headings sometimes contain possible security deficiencies
("Combined Signaling and SA Establishment") and sometimes threats
("Eavesdropping and Traffic Analysis"). Could you streamline this (i.e.
either one or the other)

i will go through the titels again and try to align them. 
> 
> * 4.2 "Combined Signaling and SA Establishment"
> 
> It took me some time to understand the problem. To my current
understanding it is the assumption that one doesnt want to introduce extra
roundtrip times to establish SAs. I.e. somehow the SA needs to be
established as soon as an NSIS message arrives from an unknown NE, without
further interaction wiht this NE. But is this assumption valid? Do we expect
the number of possible peer-NEs is so large that the costs for an additional
roundtrip to establish the SA is too big?
> 
> I dont understand the sentence "For this to work, specific classes of
cryptographic mechanisms supporting this type of behaviour are needed". What
is "this to work"? Do you mean (previous sentence) "allow refresh messages
to create new state along a new path" to work _in a secure way_? Furthermore
what specifically is "this type of behaviour"? In the text above no
"behaviour" was described.


i have tried to fix this section. you can find a change-proposal in a
separate mail.

> 
> * 4.3 "Eavesdropping and Traffic Analysis"
> 

> I cant find what the security deficiencies are that allow this kind of
threat. It only says integrity protection does NOT help against it. But why
would anybody think it does??? Adding a kind of secured checksum (that is
what integrity protection does, doesnt it?) of course doesnt help.

the ability to eavesdrop signaling traffic (for various reasons) is a
threat. whether people would like to address it is another story. 
might might remember steve bellovin speaking about confidentiality
protection. he argued that it is required. 

it is true that the paragraph:

"
   Note that this threat scenario is not mitigated by applying 
   integrity protection to the messages, which is often considered 
   sufficient for signaling protocols. 
" 

might be somewhat trivial. i will remove it. 



> 
> The 3rd paragraph introduces exploitation of the spoofing of flow
identifiers. The remaining paragraphs of 4.3 all seem to discuss this
problem in more detail. It took me some time to realize this, may be you
could add an explaining sentence.


i guess that the subsequent issues refer to the section 4.4 (identity
spoofing):

> 
> 2nd last paragraph of 4.3: "The ability...to inject data
atraffic..requires the ability to also receive the data traffic. This is,
however, true only if the flow identifier consists of a value that contains
addresses used for routing." Doesnt seem to make sense. I can picture
various scenarios where I am able to receive data traffic not really
destined to me, independent of the structure of the flow identifier...!?
> 
> The same paragraph continues: "If ... using...a flow identifier that do
not require such a property (CK: i.e. addresses used for routing I assume??
Or ability to receive data traffic? But this I think is independent of the
structure of the flow identifier) then ...injecting traffic are much
easier." Doesnt make sense to me either (I may just have problems catching
on...)
> 
> The final paragraph contains the DiffServ example but I dont see how it
relates to the rest. Where is the spoofed flow identifier in the example?
May be you could be more explicit...> 
> 

robert also gave comments to this issue. you can find a first attempt of a
text proposal in a separate mail. 

> * 4.6 Missing Non-Repudiation
> last paragraph "because it public-key" -> "because public-key"
> 
fixed. 

> * 4.8 Denial of Service Attacks
> In the "path-finding" scenario, what is a possible remedy?

two possible strategries: 
- life with it. 
- avoid it by authenticating and authorizing nodes, sender-initiated
reservations, do not allocate state, ....

that's subject for a discussion in nslp drafts. 

ciao
hannes

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis