Subject: Re: Re: List of Open Issues - Concerns about draft-ietf-pana-requirements-00

From: Paal Engelstad <[email-masked]>
Date: Tue, 12 Feb 2002 7:53:59 +0100

Alper,

Yes, right here I am afraid you might be missing something that might be very important. So I urge you to read once more, or simply accept that we MAY need additional requirements that make selected point-to-point mechanisms secure even in the PANA environment.

What I used as ONE example (there may be more!) was a very straitforward reflection attack. (Look up any tutorial on authentication with challenge/response, or search the web.)

Paal

Comments below,

> 
> Fra: "Alper Yegin" <[email-masked]>
> Dato: 2002/02/12 Tue AM 04:42:06 CET
> Til: "Paal Engelstad" <[email-masked]>, 
>    "Reinaldo Penno" <[email-masked]>,  <[email-masked]>
> Tema: Re: List of Open Issues - Concerns about draft-ietf-pana-requirements-00
> 
> Paal,
> 
> 
> > Hi folks,
> >
> > There is a thing I think should be clarified in the requirement document
> related to the following:
> >
> > 1)
> > "PANA MUST NOT define new security protocols or mechanisms. Instead it
> must be defined as a "carrier" for such protocols. PANA MUST identify which
> specific security protocol(s) or mechanism(s) it can carry (the "payload")."
> >
> > Another place in the draft we find:
> > 2)
> > "Both the PaC and the PAA MUST be able to initiate both the initial
> authentication and the re-authentication process."
> >
> > I see a possible contradiction between 1 and 2. Re-authentication is often
> based on Challenge/response.
> > Now, I think 1) and 2) would rule out EAP MD-5 challenge/response (e.g.
> carried by say EAP-over-
> > ICMP) and a lot of other re-authentication methods as well. The reason is
> that 1) and 2) makes reflection > attacks really easy to launch, IMO.
> >
> > Say, an unauthenticated malicious node pretends to be an authenticated
> PaC. It receives a MD-5
> > challenge from a PAA. It buffers the challenge, and sends a new request
> message back to PAA containing
> > exactly the same challenge. PAA returns the answer, which is the answer to
> the first request. The malicious
> > node managed to re-authenticate!
> 
> I didn't understand this...  The request sent by PaC to the PAA would
> "fail", because the this is a
> malicious node and doesn't have the right key to prove its identitity... So,
> how does this "failure"
> response help the malicious PaC? Am I missing something here.
> 
The malicious node does NOT need the session key, because it reflects the challenge back to PAA, which gives the answer to the first challenge message back to the malicious node. So the malicious node uses PAA as an oracle for the challenges that PAA issues!

This attack is clearly not possible if Challenge/Response is only sent from one side; or if there are different session keys on each side; or if nodes are required to remember all challenges sent; or if challenges sent are required to be different from challenges received. However, all of these fixes means additional requirements to the original protocol.

I am afraid that we MAY add additional requirements to some authentication methods to allow them to run securely in a PANA environment.

Paal

> alper
> 
> >
> > I think the intention of 1) is not to develop new solutions. However, I
> think the following requirement would fit the purpose of our WG better:
> >
> > 1)
> > "PANA MUST NOT define new security protocols or mechanisms. Instead it
> must be defined as a "carrier" for such protocols, and it MAY pose
> additional requirements to the protocols that it carries. PANA MUST identify
> which specific security protocol(s) or mechanism(s) it can carry (the
> "payload")."
> >
> > Thanks,
> > Paal
> >
> >
> > As a sidenote:
> >
> > Additional requirements on challenge/response methods to solve the
> Reflection Attack problem could be one of the following:
> >
> > 1) PAA and PaC MUST use different keys for re-authentication in both
> direction.
> >
> > But I prefer the following:
> >
> > 2) A node cannot send the same challenge that it receives. This can be
> enforced by requiring Authenticator MUST append the authenticatee's NAI (or
> temporary identity) to the beginning of a challenge-string, and to require
> that authenticatees MUST parse the challenge and validate that the identity
> in the challenge is correct before returning the MD-5 digest.
> >
> > Right?
> >
> > >
> > > Fra: Reinaldo Penno <[email-masked]>
> > > Dato: 2002/02/10 Sun AM 04:30:30 CET
> > > Til: [email-masked]
> > > Tema: List of Open Issues - Concerns about
> draft-ietf-pana-requirements-00
> > >
> > > Hello,
> > >
> > > I'm not finished with the thread, but this is what I
> > > captured. Feel free to provide correction/additions
> > >
> > >
> > > List of Issues that are open/need clarification
> > > ===============================================
> > >
> > > 1 - Authorization
> > >
> > > Should it be in-scope? To what extent?
> > > In a real network can we have a pure authentication
> > > protocol?
> > >
> > > 2 - Should PANA duplicate functionalities already
> > > present in other protocols?
> > >
> > > 3 - Notion of is actually being authenticated: User ID
> > > vs Link Layer ID
> > >
> > > 4 - DI as an access independent parameter.
> > >
> > > Text to be added
> > > =================
> > >
> > >
> > > 1 - Non multi-access aspect of PPP - James Carlson
> > >
> > > PPP provides an inherently point-to-point interface.
> > > This is by
> > > design.  If you have a multiaccess subnetwork (e.g.,
> > > Ethernet), then
> > > you're certainly not using a point-to-point model.  In
> > > particular,
> > > you have arbitrary peer-to-peer relationships on that
> > > network (which, to
> > > emulate with PPP, would require either a full mesh of
> > > point-to-point
> > > links, or the use of a designated router) and you
> > > likely have the
> > > options of broadcasting and multicasting (depending on
> > > the exact
> > > technology used).
> > >
> > > 2 - PPP Framing vs Encapsulation Terminology - James
> > > Carlson
> > >
> > >
> > > 3 - DDoS - James Carlson.
> > >
> > > I don't think that's sufficient.  Because PANA is a
> > > carrier for
> > > authentication protocols, and authentication
> > > necessarily involves
> > > computational complexity far in excess of that
> > > required for TCP, it's
> > > particularly vulnerable to attack.  I also think that
> > > at least part of
> > > the issue falls on the design of the authentication
> > > protocols carried
> > > by PANA and is thus out of scope.
> > >
> > > The in-scope issues seem to me to be:
> > >
> > > - How are PAAs protected against attack?  The logical
> > > place
> > >           that PANA can affect this (without becoming
> > > too intimate
> > >           with the authentication protocols
> > > themselves) is in the
> > >           discovery stage.  Thus, discovery likely
> > > needs to be
> > >           throttled by the PAA itself.  Some
> > > recommendations are might
> > >           be necessary there, but I suspect that the
> > > general problem
> > >           is intractable.  (If you start slowing down
> > > discovery, how
> > >           do you distinguish among requests from
> > > unknown but valid
> > >           clients and requests from unknown and
> > > invalid attackers?)
> > >
> > > - How are PaCs protected against attack?  This
> > > appears to be a
> > >           lot harder.  Because the relationship isn't
> > > quite symmetric,
> > >           a PAA isn't affected by the presence of a
> > > rogue PAA on the
> > >           same network, but the PaCs certainly are.
> > > PaCs can be
> > >           attacked by compromised or bug-ridden PAAs.
> > >
> > > - Does any of this actually matter when a multiaccess
> > > network
> > >           itself can be trivially (or inadvertently) attacked?
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Send FREE Valentine eCards with Yahoo! Greetings!
> > > http://greetings.yahoo.com
> > >
> > >
> >
> >
> 
>

---

From: subir Das <[email-masked]>
Date: Tue, 12 Feb 2002 10:44:00 -0500

Paal,
Late entry... See below.

> The malicious node does NOT need the session key, because it reflects the challenge back to PAA, which gives the answer to the first challenge message back to the malicious node. So the malicious n…

 ==>  My understanding is that PAA keeps a table for binding DIs to the Pacs. So why does PAA return the answer to a malicious node while it is not authenticated initially?  Cann't you take care this via implementation?

 Subir