RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09

[<[e-mail]>]

Hi all,
>> M2. Security functions for d-mode
>> 
>> When reading the security consideration and the specification on 
>> security properties I get a bit frightened that there are no 
>> authentication mechanism specified for d-mode. It seems that there 
>> should be need for authentication of d-mode queries etc to 
>ensure that 
>> the a NSIS node is talking to someone that really has the right to 
>> perform the query and association creation.
>
>This is an important question. Some high level analysis:
>*) d-mode basically has two functions: 
>- to set up routing state
>- to set up messaging associations
>
>Authentication/authorisation of the 'right' to set up the MAs 
>is actually handled within the MA protocols themselves (if you 
>use TLS or whatever). This can use traditional cryptographic 
>security techniques. So there should be no d-mode security issue here.
>
>Authentication/authorisation of the 'right' to set up routing 
>state is a more tricky. The point is that there is no 
>framework within which the correctness of routing state can be 
>secured in the traditional sense. Whether or not a node is on 
>the route of a flow is a dynamic function of the forwarding 
>tables in the network as a whole; two nodes could authenticate 
>with each other all that they want to, but this would tell us 
>nothing about whether the routing state itself was correct, 
>since that can only be done by interaction with the forwarding 
>layer. A further point is that at the start of the d-mode 
>exchange, you can no idea which peer you are going to be 
>communicating with, so at least some unauthenticated discovery 
>phase would be needed anyway.
>The GIST design is supposed to restrict the scope of d-mode to 
>this initial phase, and move over directly to c-mode as soon 
>as it is meaningful to do so.
>
>Section 8.3 is supposed to be about the sort of 'non-cryptographic' 
>authentication which can/must be done in these circumstances.

I agree with Robert's analysis here.  Magnus, do you feel that anything
should
be added to the Security Considerations (that is not already there)
on this issue?

>> Not having such a mechanism
>> seems to prevent building a system where the domains edge nodes 
>> handles the primary security and the internal nodes only accept GIST 
>> messages that are authenticated by nodes belonging to the domain.
>
>I don't understand the problem here. There is nothing to stop 
>a domain being deployed with the security model you indicate; for
>example:
>- a host initiates the GIST handshake with the appropriate 
>edge node, sets up routing state and a messaging association
>- the edge node authenticates the host as part of the MA setup 
>and decides what the host is allowed to do
>- the host initiates some signalling application transaction
>- if the edge node decides the signalling transaction is 
>valid, it continues to execute the transaction on the domain 
>interior nodes (GIST handshake for route discovery followed by 
>a signalling application exchange; typically the necessary MAs 
>would already be in place). 
>
>is this the sort of model you are thinking about?

Agreed - this is a sort of a deployment considerations topic, depending
upon what kind of network you are looking at.  I'm not sure if this
would
go into a base spec, but maybe a deployment guide, BCP or applicability
statement, IMO.

>> Section 8.6: I also am concerned that if there exist no secured MA 
>> between two GIST nodes, a on-path Man in the middle can prevent there

>> from ever existing a secured MA.
>
>This is not what 8.6 is aiming at. Modulo the residual threat 
>in 8.7, 8.6 is saying that
>- IF you have a suitable security policy and credentials at 
>each node (and 8.6 explains what 'suitable' means)
>- THEN the only things that an on-path MitM can do are
>(a) prevent all communication
>(b) allow a properly secured MA which it cannot intercept The 
>MitM cannot do
>(c) allow an insecure MA which it can intercept

Robert, I'm not sure if I can exactly parse (b), though I get your
point ...

>(a) is not something that any security solution can prevent: 
>an on-path MitM can always just block traffic. (b) is the 
>desired outcome anyway.
>What is ruled out is (c), which is a consequence of the MitM 
>detection mechanism in the Confirm and the security policy 
>which says what to do if the MitM is detected. (Basically, any 
>attempt to set up an insecure MA is automatically detected as 
>an MitM attack.)

Again, I agree with Robert's analsys here - do we need any additional
text?

John

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