Subject: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17

From: Roland Bless <[email-masked]>
Date: Thu, 04 Aug 2005 20:36:58 +0200

Hi,

(see http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17
for more details)

as I already expressed in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05085.html

I'm in favor of Roberts approach, to document it as residual
threat. So I'm not agreeing on Hannes opinion "let's do it".
Sure we technically can, but
I don't think it is really worth spending the effort, because
it is more or less a special type of man in the middle attack,
which cannot be prevented anyway by NTLP. Maybe Hannes could
elaborate a little bit more...furthermore: maybe some guy
from the Security Area could give advise what to do about this
issue.

Regards,
 Roland

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 5 Aug 2005 10:31:49 +0200

hi roland, 

> Tschofenig, Hannes schrieb:
> > i think that the additional effort is mostly in a small 
> piece of protocol specification. 
> > there is almost no difference from a computational point of view. 
> 
> AFAIK this would require an additional cookie mechanism.
> What about additional implementation complexity etc.??

a few lines of codes and no additional mechanisms. just a few
clarifications regarding the cookie processing. 

> Robert seemed also to be reluctant to change the current spec
> (for these reasons, other others? What's your opionion on
> spec/implementation complexity?).

i think that he just wanted to get some feedback without indicating his
opinion. 

> I very much like to follow the KISS principle here:
> since we do not really can avoid a MitM attack in general,
> we should avoid this "additional" security mechanism
> -> reduces implementation complexity...and saves some
> paragraphs(?) in the protocol spec.
it is not that easy. if you look at the message flow then you will
notice that there are two places for a man-in-the-middle adversary.  

ciao
hannes

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 5 Aug 2005 09:54:25 +0100

hi all,

> clarifications regarding the cookie processing. 

to be precise, you need to define formally in the spec 
a) a set of objects that you care about being protected
b) a rule for serialising them into a byte stream
c) an additional nonce field in the Query (or something like it)
d) a hash function for putting (b) and (c) together
e) another object for carrying this in the Response

there is an alternative approach of similar complexity
(without more objects but with a more complex specification of
the existing ones); the details are all in
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/file1/GIMPS%20Co
okies.htm

i think this is more than just 'clarifications'. the current
specification makes the cookie generation/verification process
an implementation-local issue. these changes would make it an
interoperability issue.

> i think that he just wanted to get some feedback without 

clearly, henning and i work at the pleasure of the group.

one particular thing i'm concerned about is: how this feature
plays w.r.t. the general question of specification evolution.
in particular
- new optional objects get added which logically require the
same protection - how to define whether they get included in
the calculation
- how to cope with the *expected* situation that we get the
security details of the specification wrong first time,
xref steve bellovin's talk at the plenary :-)

> notice that there are two places for a man-in-the-middle adversary.  

i think it is clear that this is a new attack. however, IMHO
it is a less serious attack than others which we already have
to cope with by other mechanisms. in other words, to the space 
in which the addition has a benefit is rather limited:
- there is a bad guy in the network
- he wants to attack a specific flow for which he is on the
  reverse but not forward path
- the 'legitimate' end nodes believe there is no MitM problem
  on the forwards path and so aren't using any upper layer 
  protection

in the end, this is always a cost benefit analysis.

r.