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

From: <[email-masked]>
Date: Thu, 5 Jun 2003 13:52:03 +0300

Hi,

Just a request for conclusion. The third leg (creating the SA) then is IKE in PANA scope? The first case where we need this SA is PANA SA! (IPSec is out of the scope of PANA).

PANA has at least these building blocks:
 - Discovery (bootstrapping..)
 - Carry EAP (authentication)
 - Manage lifetimes (session management)
 - retransmissions, msg formatting, etc. (protocol core)
 - Use IKE(v2) (SA negotation)??

Now, PaC and PAA could do SA negotiation before the EAP provides the session key! When the SA parameters are negotiated the EAP session key is derived and used with the right SA parameters?

Needles to say that there are other protocols that create SAs too, like TLS handshake.

As Bernard pointed out we need to take a closer look to the key derivation problem in PANA. One question is, if the PANA session key should be independent of the key(s) it has been derived from? [otherwise it may be possible by knowing the EAP Session key and sniffing the link to create PANA SA]. Further more, if PANA SA is used to bootstrap other SAs, how to make sure that the derived SA is independent of PANA SA (conceptually similar case). 

The property that PANA SA could give is *authentication* (based on the EAP negotiation). So by creating the session key partly from the PANA SA would give this property to derived session keys.

Br,
- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 05 June, 2003 05:11
> To: Bernard Aboba
> Cc: Russ Housley; pana
> Subject: Re: last call review of PANA Requirements document. 
> 
> 
> > "   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.
> 
> 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 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.
> 
> 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
> 
> > 
> > "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.
> 
> 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.
> 
> > 
> > "
> >  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,
> 
> 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)
> 
> > 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.
> 
> OK.
> 
> > 
> > "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.
> 
> 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
> > there is a lot that is being glossed over here.
> 
> The details are left to the solution drafts.
> 
> > 
> > "   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.  
> 
> 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
> > 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.
> 
> 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]
> 
> > 
> > "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.
> 
> 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.
> 
> 
> > 
> > "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.
> 
> 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: Alper Yegin <[email-masked]>
Date: Thu, 05 Jun 2003 12:08:52 -0700

Hi Dan,

> Just a request for conclusion. The third leg (creating the SA) then is IKE in
> PANA scope? 

Creating an "IPsec SA for access control" might be done by IKE, as proposed
in draft-mohanp-pana-ipsec-00.txt. This is not same as PANA SA, which is
created at the end of EAP authentication over PANA.

> The first case where we need this SA is PANA SA! (IPSec is out of
> the scope of PANA).
> 

> - Use IKE(v2) (SA negotation)??
No, this last piece is not part of the PANA protocol. It is separately done
by another mechanism, like draft-mohanp-pana-ipsec-00.txt, only when needed.
The resultant SA is IPsec SA for access control.

> 
> Now, PaC and PAA could do SA negotiation before the EAP provides the session
> key! When the SA parameters are negotiated the EAP session key is derived and
> used with the right SA parameters?

please see above...

> As Bernard pointed out we need to take a closer look to the key derivation
> problem in PANA. One question is, if the PANA session key should be
> independent of the key(s) it has been derived from? [otherwise it may be
> possible by knowing the EAP Session key and sniffing the link to create PANA
> SA]. Further more, if PANA SA is used to bootstrap other SAs, how to make sure
> that the derived SA is independent of PANA SA (conceptually similar case).

Yes.

> 
> The property that PANA SA could give is *authentication* (based on the EAP
> negotiation). So by creating the session key partly from the PANA SA would
> give this property to derived session keys.

Yes.

Alper