Subject: Re: last call review of PANA Requirements document.

From: Alper Yegin <[email-masked]>
Date: Wed, 04 Jun 2003 17:45:09 -0700

And these are Bernard Aboba's comments. Thanks Bernard!
(sorry for late fwds. I was away from the office until today)

Alper

On 5/30/03 9:47 PM, "Bernard Aboba" <[email-masked]> wrote:

> OK. Here are my comments. Since some of them are based on the AAA keying
> requirements presented by Russ Housley at IETF 56, I'm CC:'ing Russ.
> 
> "   The protocol design will be limited to defining a client-server
>  messaging protocol (i.e., a carrier) that will allow authentication
>  payload to be carried between the host/client and an agent/server in
>  the access network for authentication and authorization purposes
>  regardless of the AAA infrastructure that may (or may not) reside on
>  the network. As a network-layer protocol, it will be independent of
>  the underlying access technologies. It will also be applicable to
>  any network topology."
> 
> Is it really a requirement that the protocol by assymetric
> (client/server)? For example, EAP is a peer-to-peer protocol.  I ask this
> because certain wireless scenarios such as adhoc are inherently symmetric,
> and it may be awkward to solve these problems with a client/server
> protocol.
> 
> "  The Working Group will not invent new security protocols and
>  mechanisms but instead it will use the existing mechanisms. In
>  particular, the Working Group will not define new authentication
>  protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key
>  agreement protocols, or key derivation methods."
> 
> EAP and AAA only provide two legs of the security
> relationship between the EAP peer, Authenticator and AAA server. The
> third leg is the "secure association" protocol that negotiates the
> security association (including ciphersuites and other communications
> characteristics) between the EAP peer and authenticator.  In this
> regard, EAP is similar to IKE Phase 1 (authentication and keying
> material) while the "secure association" protocol is like IKE Phase 2
> (security parameter negotiation). An example of a "secure association"
> protocol is the IEEE 802.11i 4-way handshake.
> 
> In general, the properties of the "secure association" protocol
> (such as mutual authentication and guaranteed freshness of transient
> session keys) are critical to the overall security of the system. So
> unless PANA is planning on reusing or repurposing the 4-way handshake,
> where EAP is being used to generate keys on a physically insecure link,
> it's difficult to see how the overall system will be able to meet
> the AAA key requirements presented at IETF 56.
> 
> "PANA MUST only grant network access
> service to the device identified by the DI, rather than granting
> separate access to multiple simultaneous users of the device."
> 
> I'm not clear why PANA requires that only a single security association
> can exist between a PANA client and potential endpoints.  In protocols
> such as PPPOE it is possible for multiple services to exist on the same
> wire and for a client to connect to multiple such services, with separate
> security associations for each. Whether the security associations apply
> to the machine as a whole or individual users is really an operating
> system issue, not something that the PANA protocol should care about.
> 
> "
>  Providing authentication, integrity and replay protection for data
>  traffic after a successful PANA exchange is outside the scope of
>  this protocol. In networks where physical layer security is not
>  present, link-layer or network-layer (e.g., IPsec) ciphering can be
>  used to provide such security. These mechanisms require presence of
>  cryptographic keying material at PaC and EP, which can be generated
>  by various EAP methods."
> 
> The last sentence seems to imply that EAP by itself is sufficient to
> provide keying material for a ciphersuite.  In general, this is not the
> case. EAP provides only authentication and basic keying material, but
> does not negotiate the properties of the security association, or
> guarantee liveness in cases where keying material is cached,
> This is the task of the "secure association" protocol.  Given the critical
> role of this "third leg" of the EAP/AAA triangle, it seems to me that if
> PANA is using EAP for key generation that either a "secure association"
> protocol is supplied or the protocol will not meet the security
> requirements.
> 
> For example, without a "secure association" protocol to guarantee
> freshness of transient keys, it is possible that transient keys will be
> reused,
> compromising security.
> 
> "Although PANA does not deal with key
>  derivation or distribution, it indirectly enables this by the virtue
>  of carrying EAP. "
> 
> EAP is not sufficient for key  derivation or exchange on physically
> insecure media -- a "secure association" protocol is required in addition.
> 
> "The keying material produced by EAP methods cannot
> be directly used with IPsec. In that case these initial keys can be
> used with an IPsec key management protocol like IKE to generate the
> required security associations."
> 
> The use of EAP to generate IKE pre-shared keys does take care of the need
> for a "secure association" protocol since IKE Phase 2 takes on that role.
> However there is still the need to specify exactly what EAP keying
> material is used, and how it is processed.  Overall, I think that
> there is a lot that is being glossed over here.
> 
> "   After a device is authenticated using PANA, it MUST be authorized
>  for network access. That is, the core requirement of PANA is to
>  verify the authorization of a PaC so that PaCs device may send and
>  receive any IP packets."
> 
> Using PANA for authorization seems to me to be problematic because EAP
> assumes that access is allowed or denied based on the EAP authentication
> process alone.  We've already addressed conflicts between the AAA
> result (Accept/Reject) and EAP result (Success/Failure) in RFC 2869bis,
> and now in 2284bis we are having to reconcile the EAP method result with
> the EAP result. Given this, adding a PANA authorization result as well
> will just add to the confusion.
> 
> "PANA SHOULD have a
>  mechanism to provide disconnect indication. When such indications
>  are not protected by means of physical or link-layer mechanisms,
>  PANA MUST ensure this protection to prevent attackers from
>  leveraging this extension for DoS attacks."
> 
> Just as it is important to have a secure mechanism
> for establishing a security association, it is also important to have a
> secure mechanism for tearing one down. That is what a secure disconnect
> indication is, and this is something that needs to be provided within
> the same protocol as handles security association setup. So I'd claim
> that PANA MUST deal with this regardless of physical or link-layer
> mechanisms.
> 
> "5. Security Considerations
> 
>  This document identifies requirements for the PANA protocol design.
>  Due to the nature of this protocol most of the requirements are
>  security related. The actual protocol design is not specified in
>  this document."
> 
> I think there needs to be expanded discussion of issues relating to
> keying, if in fact this is relevant to PANA. As noted earlier, once
> EAP is used to generate keys on a physically insecure network,
> a "third leg" is required, in addition to the EAP and AAA legs. After
> reading this document I'm not clear about the requirements for that
> leg or how PANA could be considered secure without such a leg.
>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 04 Jun 2003 19:10:42 -0700

> and it may be awkward to solve these problems with a client/server

I don't think that was intentional. We don't mean to require that this is a
strictly client-server design. Hence, I'd remove the term "client-server"
from the text.

> the AAA key requirements presented at IETF 56.

Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue.
There is already an I-D for this purpose: draft-mohanp-pana-ipsec-00.txt

> system issue, not something that the PANA protocol should care about.

Actually this requirement does not say one client is entitled to at most one
security association. This text is meant to reflect what you point out in
your last sentence.

Regarding the PPPoE example,  unless these users use different DIs (device
identifiers), the enforcement points cannot distinguish one's traffic from
the others'. So, as long as DIs are unique, there should not be a problem
for PANA to deal with.

> guarantee liveness in cases where keying material is cached,

We say that later:

  The keying material produced by EAP methods cannot be directly used with
   IPsec.

But I see your point. I'd rewrite the relevant text  (please see the bottom
of this message)

> insecure media -- a "secure association" protocol is required in addition.

OK.

> material is used, and how it is processed.

Agreed. The PANA draft will specify how PANA SA is generated at the end of a
successful PANA exchange. But PANA SA is not same as IPsec SA. A separate
draft, like the one I referenced earlier, will define how PANA SA is turned
into IPsec SA.

> Overall, I think that

The details are left to the solution drafts.

> process alone.  

Actually all this requirement says is that at the end of a PANA
authentication, client is either authorized to access the network or not. It
does not really say anythign regarding whether PANA carries authorization,
or EAP carries authentication, etc.

PANA can satisfy the above requirement by simply carrying EAP, and not
carrying any other result codes. It may also have its own result field, but
we need to deal with this issue separately. At least, this is not a
requirements issue, I think.

> We've already addressed conflicts between the AAA

I don't think this matter boils down to "PANA must not have an authorization
result field", or the opposite. So, I'm not sure if this  is for the
requirements draft to deal with.

[if the PANA result field proves not useful or problematic, we can remove it
from the design]

> that PANA MUST deal with this regardless of physical or link-layer

OK, I'd rewrite this text as:

   PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST
   be capable of securing disconnect messages in order to  prevent malicious
   nodes from leveraging this extension for DoS attacks.

> leg or how PANA could be considered secure without such a leg.

Updated text for section 4.1.1:

   Providing authentication, integrity and replay protection for data
   traffic after a successful PANA exchange is outside the scope of
   this protocol. In networks where physical layer security is not
   present, link-layer or network-layer (e.g., IPsec) ciphering can be
   used to provide such security. These mechanisms require presence of
   cryptographic keying material at PaC and EP. Although PANA does not deal
   with key derivation or distribution, it indirectly enables this by the
   virtue of carrying EAP. Various EAP methods are capable of generating
   basic keying material.

   The keying material produced by EAP methods cannot be directly used with
   IPsec as it lacks the properties of an IPsec  SA (security association).
   These basic (initial) keys can be used with an IPsec key management
   protocol like IKE to generate the required security  associations. A
   separate protocol, called secure association protocol, is required to
   generate IPsec SAs based on the basic EAP keys. This protocol  MUST be
   capable of enabling IPsec-based access control on the EPs. IPsec  SAs
   MUST enable authentication, integrity and replay protection of
   data packets as they are sent between the EP and PaC.

Also, some updates for section 4.1.2:

   Providing access control functionality in the network is outside the
   scope of PANA. Client access authentication SHOULD be followed by
   access control to make sure only authenticated and authorized
   clients can send and receive IP packets via access network. Access
   control can involve setting access control lists on the EPs.
   Identification of clients that are authorized to access the network
   is done by the PANA protocol exchange. If IPsec-based access control is
   deployed in an access network, PaC and EPs should have the required IPsec
   SA in place. Generating the IPsec SAs based on EAP keys is outside the
   scope of PANA protocol. This transformation MUST be handled by a
   separate secure association protocol (see section 4.1.1).

Alper

---

From: Subir Das <[email-masked]>
Date: Thu, 5 Jun 2003 02:07:30 -0700 (PDT)

> There is already an I-D for this purpose: draft-mohanp-pana-ipsec-00.txt

Is it fair to say that the *only* intended use of PANA for keying is
described by this document?

> the others'. So, as long as DIs are unique, there should not be a problem

In this particular example, the "session identifier" can differentiate
sessions between identical endpoints. Does this qualify as a "DI"?

> But I see your point. I'd rewrite the relevant text  (please see the bottom

The issue is that setup of an IPsec SA requires more than just keying
material and authentication -- which is all EAP provides.

> draft, like the one I referenced earlier, will define how PANA SA is turned

Yes. The PANA SA only provides authentication and key material. You need
another protocol to negotiate an IKE Phase 2 SA so as to be able to use IPsec.
That protocol could of course be IKE itself.

> The details are left to the solution drafts.

That's fair -- but I think that you need to expand on the nature of the
PANA SA and how it compares to an IKE Phase 1 and Phase 2 SA.

OK.

> [if the PANA result field proves not useful or problematic, we can remove it

Sure. I agree this is not a requirement.

>    nodes from leveraging this extension for DoS attacks.

Yes, that's better.

>    IPsec as it lacks the properties of an IPsec  SA (security association).
which include secure ciphersuite negotiation, mutual proof of possession
of keying material, freshness of transient session keys, key naming, etc.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 05 Jun 2003 12:00:01 -0700

> described by this document?

No. This draft describes using PANA for keying for access control (IPsec).
This is what is needed for PANA WG. There are other potential consumers of
keying, such as bootstraping RFC3118 for DHCP security, but that is not for
PANA WG. It solves a problem for DHCP WG.

> sessions between identical endpoints. Does this qualify as a "DI"?

I don't see why not.

> of keying material, freshness of transient session keys, key naming, etc.

I will add these to the text.

Alper