Subject: [NSIS] last call comments on threats doc

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Mar 2004 01:24:19 -0000

Hi,

here are some last call comments on the threats document.
(i actually wrote them last week but then fell out of the
net. it must be 9th march somewhere, though.)
General

Despite the introductory text, I found it hard to work out
sometimes whether the document was talking about the overall
signalling problem or the different bits of NSIS (and whether
it was supposed to be doing one or the other or both). Apart
from anything else, someone less familiar than me with NSIS
terminology could get easily lost at various stages. A readability
check by someone with *no* NSIS background might be a good 
thing.

There is an important question of whether this document should
attempt to allocate responsibility for various threats between
the NSIS layers. My view is that - apart from high-level
statements about whether something is (for example) application 
related or transport related - it should not. Many details
of the layer split (including details which are very relevant 
from the security perspective) are left open in the framework,
so the layer split will only be well enough defined to analyse
as the protocol designs firm up. This document will serve as an
input to that design process, but it will still need interpretation
during that process.

Editorial comments have been sent separately.

> Abstract 
>     
>    This threats document provides a detailed analysis of the security 
>    threats relevant for the NSIS protocol. It calls attention to and 
Protocol or protocol suite? (and so on, also during the introduction,
mentions of NTLP/NSLP and so on)

> 1. Introduction 
[snip]
>    - NSIS Analysis Activities (e.g., RSVP Security Properties)   
>    - Security Threats for NSIS          
>    - NSIS Requirements               
>    - NSIS Framework                  
>    - NSIS Protocol Proposals 
Would be nice to add references here.

>    This interaction is also a 
>    subject of discussion within the NSIS Framework. 
The particular interaction you mention is not discussed in much detail,
in fact.

>     
>    We use the NSIS terms defined in [Brun03]. 
You also use some framework terms (e.g. in the preceding paragraph!)

> 2. Relevant Communications Models 

I think something should be added to this section to say that these
different models are not hard and fast statements about exactly how
communications in the Internet actually work, but convenient names
for different 'typical' scenarios. For example:
- is an on-path proxy a first peer or not? (according to the pictures
  it is if it initiates NSIS signalling, but it could actually be
  anywhere in the network)
- if I have a personal area network, is the device in it which provides
  the gateway to the infrastructure a first peer or not? (according
  to the pictures it is not if some other device in the PAN initiates
  the signalling, but the security issues are probably more first-peer
  like)

Also, this section talks a lot about 'trust relationships' without
saying what they are. (It may be that this is a standard formal
term, but I've just seen in another project a case where several
security experts realised they were all using it in a set of unsubtly
different ways.) It could mean
- some commonality of purpose (having the same goal)
- the ability to authenticate (because shared keys or validated
  certificates are available)
- an existing security association
- something else

Another point is that the level of detail in various subsections
is not consistent. Some include scenarios, some describe security
concepts, some provide threats information, and so on. This is 
slightly disorienting for the reader.

> 2.1 First-Peer Communications 

>    Usually there is 
>    a fairly strong (pre-established) trust relationship between the 
>    peers. Enterprise network administrators usually have some degree of 
>    freedom to select the appropriate security protection and to enforce 
>    it.

This sound perilously like talking about a 'trusted domain' (which is
apparently a red-flag word in some quarters ...)

> 2.4 Inter-Domain Communications 
>     
>    The number of neighboring domains 
>    is usually rather limited (compared with first-peer communications), 
>    which substantially reduces the key management considerations for 
>    securing inter-domain NSIS signaling. 

OTOH the increased volume of traffic probably means that automatic
rekeying is a must in such environments.

> 2.5 End-to-End Communications 
>     
>    The following example illustrates a possible application of end-to-
>    end protection for objects carried within the NSIS signaling 
>    protocol. Alice, the data sender, wants Bob, the data receiver, to 
>    pay for a QoS reservation (reverse charging). Bob wants to be 
                              ^^
"that Alice has made"?

>    Typical threats in such a scenario range from modification of QoS 
>    objects or price information (i.e., making Bob pay too much), to 
>    fraud (i.e., forcing Bob always to pay for the reservations), to 
>    identity spoofing (i.e., an impostor claiming to be Alice). 

Also, modifying the reservation so it can be used by someone else.

>    Regarding end-to-end security, one additional issue needs to be 
>    addressed: delegation. Whenever signaling is addressed end to end 
>    and an arbitrary node along the path acts as a proxy on behalf of 
>    the other endpoint, a delegation mechanism is required to provide 
>    secure interaction. This might lead to additional complexity.  

But why mention these (generic) threats here and not any of the 
other communications models (they apply widely, e.g. middle-middle,
end-middle).
 
> 3. Generic Threats 

> 3.1 Man-in-the-Middle Attacks 
>     
>    Note also that a 
>    denial of service attack on a signaling protocol exists when no 
>    separation between SA establishment and signaling protection takes 
>    place.

I don't know whether this is just saying that SA establishment needs
DoS protection (true), or a more subtle point about DoS protection 
being harder without the separation because the first stage is more
expensive (as you say later). In either case, the text doesn't seem
to be needed here.

>    The discovery procedure, in particular, is vulnerable to a 
>    number of such attacks. 

You haven't defined what a discovery procedure is. And even if the
protocols do have discovery procedures (which is not fixed, at least
at this threats stage of the lifecycle), the vulnerability is more
fundamental in the functionality.

> 3.4 Insecure Parameter Exchange and Negotiation

I think this threat is very important to consider. But is there
any way to handle it except in the context of a security protocol
(unless you rely on static policies)? You can always mount a 
downgrading attack on the authentication process itself, at 
which point you are finished.
    
> 4. NSIS-Specific Threat Scenarios 

> 4.2 Combining Signaling and SA Establishment 
>     
>    When a signaling message arrives at an NSIS-aware network element,
...
>    protection are described in [AN97] and in [ALN00]. 

I found this paragraph quite hard to follow (even though I think
I know what you are trying to say). Part of the problem is that
you are talking about the *threat* of flooding but the section
title is referring to imperfections in a particular class of 
solution. 

There is room for a more structured analysis of the flooding problem
(especially in the light of concerns about RAO handling expressed on
Monday). Flooding needs a layered defence and protection happens at
several levels.

> 4.4 Identity Spoofing 
>     
>    The ability for an adversary to inject data traffic that matches a 
>    certain flow identifier established by a legitimate user often 
>    requires the ability also to receive the data traffic. This is, 
>    however, true only if the flow identifier consists of values that 
>    contain addresses used for routing. If we imagine using attributes 
>    of a flow identifier that do not require such a property, then 
>    identity spoofing and injecting traffic are much easier. An 
>    adversary can use a nearly arbitrary endpoint identifier to achieve 
>    the desired result. Obviously, though, the endpoint identifiers are 
>    not irrelevant, because the messages have to travel the same path 
>    through the network.  

This implication of this is that flow identifiers should be hard to
spoof usefully (e.g. they should contain destination addresses).
This would be an important point to capture and propagate through into
the signalling protocol security analysis.

> 4.5 Unprotected Authorization Information 
>     
>    Returning an unprotected authorization token to 
>    the end host might allow an adversary (for example an eavesdropper) 
>    to steal resources. An adversary might also use the token to monitor 
>    communication patterns. Finally, an untrustworthy end host might 
>    also modify the token content.  

Doesn't this just mean that the token passing protocol is broken?
(i.e. shouldn't we be able to avoid this happening by using strong
protocols? or are these protocols particularly hard to secure?)

> 4.8 Denial of Service Attacks 
>     
>    - Path Finding 
>     
>    This threat scenario includes potential DoS attacks that exist when 
>    the reservation setup is split into two phases, i.e., path and 
>    reservation (as used, for example, in receiver-based reservation 
>    setup). In this case, assuming that the node transmitting the path 
>    message is not charged for the path message itself, it may be able 
>    to generate a large number of reservation requests (possibly in a 

Is this really specifically about reservation requests? It sounds
generically like a threat caused by any message which can be sent
without direct cost. (In particular, referring to reservation 
requests rather than messsages in general makes it sound like 
this is a threat to the resource pool, whereas I think it is a
threat to the control plane.)

> 4.11 Attacks against the Transport Mechanism 
>     
I think we can now refer to the split layer architecture as a 
decision within the group (after all, it's in the charter) and is
as defined in the framework.

A reference to RFC2385 might be helpful background.

--end

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