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

From: Paal Engelstad <[email-masked]>
Date: Tue, 12 Feb 2002 1:17:15 +0100

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 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: "Alper Yegin" <[email-masked]>
Date: Mon, 11 Feb 2002 19:42:06 -0800

Paal,

> "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")."
> "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.

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:
> 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.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 11 Feb 2002 21:25:33 -0800 (PST)

Based on the recent feedback.

1 - Authorization (Open)

(Alper) Requirements draft has a position on this.
Regarding more detailed
authorization, my personal take is "not now, can be
done later".

2 - Should PANA duplicate functionalities already
present in other protocols? (Open)

(Alper) I think this is not for the requirements draft
(yet).. This is a 
high-level discussion that has been going on regarding
the charter and 
the scope of this work. We also have some charter
items to address this:
"PANA interactions with PPP and 802.1X"

Alper

3 - Notion of is actually being authenticated: User ID
vs Link 
Layer ID (closed as Tue, 12 Feb 2002 0:50:10 +0100)

Requirements draft is clear. 

4 - DI as an access independent parameter. (closed as
Tue, 12 Feb 2002 0:50:10 +0100)

You may have:
  - access independent authentication
  - access dependent authentication
 
 In the former case, you authenticate based on an
 access independent identifier, such as a NAI. In the
 latter case you also
 validate/authenticate/ensure-the-integrity-of  an
 access dependent Device Identifier. (This is just a
 word referring to an IP-address, link-layer address,
 flow-state-descriptor or some other access dependent
 divice information.)
 
 Thus, the conclusion of the thread was that the
 Device Identifier is OPTIONAL in the PANA protocol.
 PANA accommmodates both access independent and
 access dependent authentication.

5 - Device Identifier and Multicast Addresses. (Open)

In the requirements it is said that.

"Device Identifier (DI) 
    
The identifier used by the network as a handle to 

...<snip>...<snip>...

At most one PANA client should be associated with a DI
on a PANA authentication agent. "
    
Given that the DI can an IP address, this means that
in the multicast case you cannot use DI as an
identifier (since several clients would be associated
with a DI), or we need to change the above definition
a little.

So the main question is: Would that be a case where
you want to grant access to all members of a multicast
group without caring to know each client individually?

Text to be added
=================

1 - Non multi-access aspect of PPP - James Carlson -
Text to be added

2 - PPP Framing vs Encapsulation Terminology - James
Carlson - Text to be added

---

From: subir Das <[email-masked]>
Date: Tue, 12 Feb 2002 11:45:22 -0500

> "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. P…

  => Agree

> 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 challeng…

  ==> I would prefer not to include this much details in the requirement draft.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Feb 2002 09:51:23 -0800

Reinaldo,

Let me register my opinion on the following..

> group without caring to know each client individually?

I don't think we need to deal with multicast IP address as DI.
DI can be used as the source of outgoing traffic and destination
of incoming traffic. As such, a multicast IP address as DI doesn't
make sense. Granting access to multicast members seem outside the scope
to me. Are there similar protocols that handle this case?

alper

---

From: subir Das <[email-masked]>
Date: Tue, 12 Feb 2002 14:51:08 -0500

Reinaldo,

> List of Issues that are open/need clarification

  => What exactly you mean by "pure authentication" protocol?
   Can you elaborate?

> "PANA interactions with PPP and 802.1X"

    I agree with Alper and Hesham. We should avoid spending time in
    discussing a topic like this. We know many protocols have some
common
    functionalities and goal. Moreover, we have specific charter item
    to deal with as mentioned above.

>  access dependent authentication.

  => Sorry, I am confused. In one place you mention DI is access
       independent and finally you conclude PANA accomodates both and
       DI is optional.

> group without caring to know each client individually?

   => I would prefer to deal the multicast case separately.

Subir

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 13 Feb 2002 18:00:03 -0800 (PST)

>   => What exactly you mean by "pure authentication"

Well, today we authenticate a DI and return a binary,
0 or 1. Technically you can say that this is already
an authorization, an authorization to send packets
through that DI. Later in the network you can have
other constraints.

Another example, if you authenticate a PaC, you might
want to overide the routing table (very common with
tunneling protocols), this could also be seen as 
authorization

I think it boils down to how much authentication and
authorization and close together today. From my
perspective we made DI a parameter tha can be anything
because we think being an access dependent parameter
will not help with the authorization process. There
were some good examples on the Reqs list were the
access level does not help. 

I think I will stop here cause this might be a good
ratrole...

>        independent and finally you conclude PANA

You are giht. I changed the wording.

>    => I would prefer to deal the multicast case

okay, do you have any suggestion?

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 13 Feb 2002 18:19:04 -0800 (PST)

Here it goes the new compiled version. 

regards,

Reinaldo

1 - Authorization (Open)

Should it be in-scope? To what extent? 
In a real network can we have a pure authentication protocol?

(Alper) Requirements draft has a position on this. Regarding more detailed
authorization, my personal take is "not now, can be done later".

2 - Should PANA duplicate functionalities already present in other protocols? 
(closed as Tue, 12 Feb 2002 14:51:08 -0500)

(Alper) I think this is not for the requirements draft (yet).. This is a 
high-level discussion that has been going on regarding the charter and 
the scope of this work. We also have some charter items to address this:
"PANA interactions with PPP and 802.1X"

(subir) I agree with Alper and Hesham. We should avoid spending time in
discussing a topic like this. We know many protocols have some
common functionalities and goal. Moreover, we have specific charter item
to deal with as mentioned above.

3 - Notion of is actually being authenticated: User ID vs Link 
Layer ID (closed as Tue, 12 Feb 2002 0:50:10 +0100)

4 - DI as an access independent parameter. (closed as Tue, 12 Feb 2002 0:50:10 +0100)

You may have:

"Device Identifier (DI) 

...<snip>...<snip>...

(subir) Want to deal with Mutlicast separately

6 - Addtional Security Requirements - Paal (open)

Current Text: 

"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")."

 
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 think the intention of the former is not to develop new solutions. However, 
I think the following requirement would fit the purpose of our WG 
better:
 
"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")."

As a sidenote:

1) PAA and PaC MUST use different keys for re-authentication in both 
direction.

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.

7 - Expand on the Interactionsinteraction/relationship of PANA with 
802.1X and PPP authentication - Erik et al (open)

Text to be added
=================

1 - Non multi-access aspect of PPP - James Carlson - Text to be added

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 - Text to be added

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.

	- 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?