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

["Hancock, Robert" <[e-mail]>]

hi,

inline ...

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: 16 June 2006 13:14
> To: Hancock, Robert
> Cc: [e-mail]
> Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 
> Security Issues
> 
> 
> Hancock, Robert wrote:
> > Hi,
> > 
> > the security issues, M2:
> > 
> >> -----Original Message-----
> >> From: Magnus Westerlund [mailto:[e-mail]] 
> >> Sent: 01 June 2006 15:23
> >> To: [e-mail]
> >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09
> >>
> >> 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.
> 
> Hmmm. I see that being easily done for the MA that are 
> established over 
> connection oriented protocols. What about applications using 
> D-mode for 
> application data?

This is then partly a terminology/concept issue:
*) we define D-mode as where there is no per-message state, which
effectively rules out many channel security protocols anyway.
*) OTOH the C-mode is not restricted to 'fully fledged' connection-
oriented protocols like TCP; it's supposed to be used for anything 
where some [don't know what to call it]-state is set up between two
nodes with fixed IP addresses.
*) so, for example, DTLS/UDP or DTLS/DCCP or IPsec AH/UDP or whatever 
would count as additional C-mode configuration possibilities. they
aren't allowed in the current version of the spec, because we have
not chosen to define an unreliable transport option for C-mode. But
if we decided that such a mechanism was useful, then this is how it
would be incorporated (rather than by securing D mode itself).
*) as an aside: in the layering model, applications do not choose 
which of C/D mode they use. they express their transfer requirements
(reliable or not, secured or not, etc.) and then GIST chooses what 
to do. A consequence of us not (yet) defining an unreliable transport
option is that if an application requests secure transfer, it will
get TLS/TCP.

> 
> > 
> > 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.
> 
> Yes, maybe I am being overly paranoid here. And it seems that if you 
> like to authenticate the D-mode requests you could use IPsec 
> AH mode to 
> accomplish that.

indeed (but see also above).

> However lets assume that this is sufficient 
> for now. I 
> intended to request a security review of this protocol as 
> soon as we are 
> ready to progress GIST to IETF last call.

That will be good to get.

> 
> > 
> >> 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?
> 
> Yes. But with the extra twist that I perceive a threat of spoofing or 
> manage to tunnel attacks into the domain. Thus having a desire to 
> restrict the interior nodes to only accept GIST D-mode 
> messages that are 
> authenticated as coming from a the domain. But I will assume 
> that this 
> can actually be accomplished with IPsec.
> 
> > 
> >> 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
> > 
> > (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.)
> > 
> 
> I think you are mostly correct. However I think there is a 
> case D that 
> is not sufficiently warned about. The case is the two GIST 
> peers A and 
> B, where A tries to create a MA between them. The attacker C 
> is on-path 
> and can intercept and rewrite the GIST messages. A offers 
> both TCP/TLS 
> and TCP in its query. C change that to only being TCP. Which 
> it can sit 
> in the middle and rewrite anything in. B. gets the modified query and 
> sends a response. The response sent back by C is modified so 
> that A gets 
>   the picture that B selected TCP. The TCP connection is 
> established and 
> now C can modify the checks as they are not secured.
> 
> My issue with this whole thing is that the only way of knowing that a 
> MITM exist is to require the usage of TLS with certs at both end, and 
> use that to verify the query sent unsecured. I think it should be 
> clearer that not having a policy of using TLS equals leaving 
> it open for 
> MITM. Or is the above case based on some misunderstanding?

Your analysis is correct. You can find a similar discussion at
http://www1.ietf.org/mail-archive/web/nsis/current/msg05743.html.
Section 8.6 was written partly in response to that thread, and the
last sentence there is supposed to address the point you raise:

  "Therefore, provided that the Querying node applies a
   security policy on the messaging association protocols it will create
   that ensures at least this minimal level of protection is met, it can
   be assured that the capability discovery process will result in the
   setup of a messaging association with the correct security properties
   as appropriate for the two peers involved."

It may be that this sentence does not advertise its content very
effectively (maybe it should be said the other way round, e.g. 
'if the querying node does not XXX ...'). Views?

cheers,

robert h.

> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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