Subject: [Gen-art] Gen-ART Last Call review of draft-barany-eap-gee-04

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 17 Jan 2007 06:19:43 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-barany-eap-gee-04
Reviewer: Spencer Dawkins
Review Date: 2007-01-17
IETF LC End Date: 2007-01-19

Summary: This draft is on the right track, but has open issues, identified 
in the review below.

Comments:

Please remember I'm not a security geek, or an EAP geek, so please push back 
on anything that seems bogus ("welcome to the IETF")...

My biggest concerns are

(1) the document is really inconsistent about how Type 1 and Type 2 work 
together (is Type 1 always access authentication?) and this seems to allow a 
level of flexibility that (I read in the security considerations section) 
increases vulnerabilities when you use that flexibility,
(2) I don't get the N/As in the access control matrix at all,
(3) I'm not sure how much 2119 language you need in this document, but it 
seems like you'd need more than you've got, at least in Section 5.3,
(4) Section 7 has some speculation about future versions of GEE, but they 
aren't tagged quite clearly enough as "this COULD happen",
(5) the security considerations section seems to make recommendations that I 
wasn't comfortable with.

Further details follow. Please note that "Spencer: Nit:" isn't technically 
part of the Gen-ART review, these are just things I noticed while writing 
the review, for your convenience.

Abstract

   The Extensible Authentication Protocol (EAP) is a general
   authentication protocol that supports multiple authentication methods
   and typically runs directly over data link layers without requiring
   IP.  EAP can be used for different types of authentication, where

Spencer: Nit: the abstract text here doesn't seem as clear as the Section 
1.1 text. Perhaps "EAP could be used to authenticate with multiple 
Authentication Servers, when multiple providers provide access to different 
types of services, but EAP itself does not have the ability to differentiate 
between multiple EAP conversations between a peer and an authenticator"? And 
I'm not sure whether GEE is required for multiple EAP conversations, or if 
it's only required for multiple EAP conversations done in parallel.

   multiple providers provide access to different services.  However,

Spencer: the specification seems to oscillate between "access to multiple 
services" and "access and service", and I'm not sure why. Is access a 
service? Is access to a service a service? I am confused. Could you pick 
one? :-)

   EAP itself does not have the ability to differentiate between
   multiple EAP conversations between a peer and an authenticator.  This
   document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol
   for differentiating between multiple EAP conversations between a peer
   and an authenticator.

1.1.  Motivation

   A good example of the case where access and service authentications

Spencer: Nit: s/of the case//

   are performed separately is the case of Mobile Virtual Network
   Operators (MVNO).  In this case, the network provider providing
   Layer1 and Layer2 access is typically different from that providing
   Layer 3 service (i.e., IP level service).  Hence, separate access and
   service authentications are usually required to gain access to the
   respective networks and services.

   In cases where access and service authentications are performed
   separately, it may be desirable to do these in parallel, to avoid

Spencer: re-reading... this seems to conflict with the "do Type 1 and use 
the result to secure Type 2" recommendation in the Security Considerations 
section 7.2.2, or at least there could be text explaining why the two 
recommendations really are consistent...

   added latency resulting from a sequential execution of the two
   authentications.  When a peer is performing multiple EAP
   authentications, it is not possible to clearly differentiate between
   the two types of authentications using available means.  Also, the
   authenticator will need to distinguish the multiple EAP exchanges in
   order to route the packets to the correct EAP server.  Typically, the
   Identifier value in an EAP Response packet will be the same as that
   in the matching Request - however, the authenticator, while operating
   in pass-through mode, does not keep track of the value of the
   Identifier field.  Even if the authenticator could match up the
   values of the Identifier field, the two EAP servers performing the
   access and service authentication may generate the same Identifier
   (since the Identifier is a randomly chosen 8-bit field in the EAP
   Request/Response packets).  Hence, there is no available means to

Spencer: Nit: s/packets)/packets), and a collision would prevent correct 
routing/?

   allow multiple EAP authentications for a given peer to occur in
   parallel.

2.  Terminology

   Type 1 Authentication

      This refers to one authentications that is performed by the peer.
      For instance, it may be the Layer 1 and Layer 2 authentication
      that allows the peer to gain link layer access to the attached
      network.

   Type 2 Authentication

      This refers to a second authentication that is performed by the
      peer.  For instance, it may be the Layer 3 authentication that
      allows the peer to gain access to Layer 3 services.

Spencer: "Type 1" and "Type 2" sound like two different kinds of services, 
but if I am reading correctly, Type 1 is always for access, and Type 2 is 
always for a layer 3 service. So it's not "for instance", it's "in every 
case", or am I confused?

3.  Architecture and Overview

   The proposed protocol operation remains mostly the same in the EAP
   multiplexing model as well as the EAP pass-through model.  At a high
   level, this protocol allows the peer and authenticator to perform
   multiple EAP authentications independently and potentially with
   different authentication servers in different provider networks.  The
   multiple EAP conversations may happen sequentially or in parallel.
   However, in accordance with RFC 3748, an EAP peer and authenticator

Spencer: Nit: since RFC 3748 is about 68 pages long, a section number for 
this reference would be really nice! Section 5, perhaps?

   MUST utilize only one authentication method (Type 4 or greater)

Spencer: Nit: I know the same terminology appears in 3748, but I'm not happy 
with "Type 4 or greater", especially since this document also has Type 1 and 
Type 2, which have nothing to do with the EAP request Type 1 and Type 2. 
Since 3748 says "1-3 aren't real", maybe you could drop the "Type 4 or 
greater" parenthetical remark?

   within an EAP conversation, unless the providers are the same and the
   peer is using the same credentials and EAP method for both types of
   authentication.

   Figure 2: GEE Protocol stack and Peer to Authenticator interaction in

Spencer: Nit: is this a busted Figure label? It seems incomplete, and the 
next text doesn't quite seem to complete a thought.

   Figure 2 shows the protocol stack for GEE in the EAP multiplexing
   model.

3.1.  Multiple Authenticator Model

   Depending on the architecture, the authenticator that is responsible
   for each authentication may be different.  This could be true
   irrespective of whether the EAP server is the same or different for
   each authentication.  However, in most practical cases, the need for
   multiple authentications arises only when the EAP servers performing
   the different types of authentications are different.  Figure 4 shows
   the architecture with each provider having a different authenticator
   that is engaged in different EAP exchanges that the peer performs.
   In 3GPP2 networks, single authenticator and multiple authenticator
   architectures are both possible.

Spencer: it's not quite clear to me from the document whether GEEv0 also 
supports multiple SNPs AND an ANP - I was thinking the answer is "yes", but 
I'm guessing, and the discussion of TIDs below made me wonder if I'm 
guessing correctly for GEEv0. If multiple SNPs are supported, a 
strategically placed "two or more" would be helpful. If multiple SNPs are 
not supported in GEEv0, this document advertises more flexibility than it 
delivers...

   Since GEE runs between the peer and the authenticator, it brings a
   slight variance when the authenticator for each EAP exchange is

Spencer: Nit: not quite sure what "variance" means here - "requirement for 
different handling"? I'm guessing. Mumble.

   different.  Since the multiple EAP authentications are over the same
   link, the EAP exchange between the peer and one of the authenticators
   may have to pass through another authenticator or enforcement point.
   Hence, the lower layers at each hop in this case must be able to
   indicate the presence of the GEE header.

4.1.  GEE Header Format

   Result flags/code (RFL)

      The last 2 bits in the GEE header are used to indicate the result
      of the EAP authentication in progress.  The leftmost bit in this
      field is the 'K' bit and indicates whether the MSK resulting from

Spencer: Nit: MSK is not expanded on first use.

      the EAP conversation being encapsulated by the particular GEE
      session must be bound with an MSK resulting from the second EAP
      conversation carried in a second GEE session.  If set, this
      implies that the peer MUST bind the MSKs to derive TSKs.  The
      process of MSK binding is described in Section 5.3.  In GEEv0, the
      last bit is the R bit and is reserved and MUST be set to zero at
      the sender and MUST be ignored by the receiver.

5.  Packet Processing Details

5.1.  Packet Handling at the Peer

   While Type 1 and Type 2 authentications are not explicitly defined in
   this document, these must be defined at the peer and authenticator
   for a given usage of this protocol.

Spencer: Good. I'm supposed to be confused here... :-)

   When the peer sends a GEEv0 packet in response to a GEEv0 packet
   received from the authenticator, the TID value MUST be copied from
   the corresponding packet received from the authenticator.  As in the

Spencer: Nit: s/As in the/As with the/

   packet from the authenticator, a value of 01 indicates that the EAP
   packet is for Type 1 authentication and a value of 00 indicates that
   the encapsulated EAP packet is for Type 2 authentication.  The RFL
   value MUST be set to 00.

5.3.  Multiple authentications and access control enforcement

   When both Type 1 and Type 2 authentications are carried out, access
   control MUST conform to the following cases.

                Type1                  Type2        Combined result

 Case 1       Success               Success         Success
 Case 2       Success               Failure         Type1 related access
only
 Cases 3&4    Failure               S/F             Failure
 Cases 5&6     N/A                  S/F             S/F

                           Access Control Matrix

Spencer: deeply confused here. There is no explanation of what "N/A" means 
in this table, and in the absence of that explanation it feels like you're 
talking about six cases when you should either be talking about four cases 
or eight. I didn't see draft-terrell-math-quant-ternary-logic-of-binary-sys 
listed as a reference, so I'm assuming that the explanation would help a lot 
:-)

   GEE requires that at least one of the authentications to be key
   generating and both authentications to be mutually authenticating.

Spencer: I am confused by the lack of 2119 language in this sentence. MUST? 
SHOULD? WOULD-BE-NICE?

   If one of the authentications is not key generating, then there MUST
   be a way for the authenticator to identify the two authentication
   conversations (Type 1 and Type 2) corresponding to a peer.
   Specifically, there MUST be a mechanism for the authenticator to
   correlate the Type 1 and Type 2 credentials; typically this is
   facilitated by backend network protocol support.  An example of such
   backend support is to be able to send an identifier that is unique to
   the peer across the authentications in an authenticated manner.  For
   instance, when both authenticators reside in the same node, the AAA
   transactions may return Chargeable-User-Identity (CUI) attributes
   [12] and the node can compare them for equality.  If there is a
   mismatch, or the node has not received such an identity from both
   transactions, the peer MUST be disconnected.

   If both Type 1 and Type 2 authentications are key generating and
   occur in parallel, one of the following techniques are used:

   MSK Binding

      In this case,even when there are multiple authenticators, we
      assume that there is only one access control enforcement point.
      Here, the combined MSK MUST be used to derive session keys
      (Transient session keys, TSKs).  Both authenticators deliver the
      MSK to the enforcement point and it computes the combined MSK as
      follows: Combined-MSK = f(MSK-Type 1, "GEE Combined Key" || MSK-
      Type 2), where f represents prf+ as defined in [3].  The length of
      the Combined-MSK MUST be 512 bits.  With GEEv0, the PRF is HMAC-
      SHA-256.

   Single Access Control Enforcement with Protected Result Indication

      In the event that there can be a protected result indication
      between authenticators and/or enforcement points with a way to
      correlate the peer IDs used in the EAP conversations, it is
      feasible to have the TSK generated from only one MSK.  A MiTM

Spencer: s/feasible/possible/

      attack may be plausible in this case, and hence it is NOT
      RECOMMENDED.

6.  GEE Extensibility

   GEE could be extended to support dynamic TID assignment, where an
   authenticator may pick an unused TID value.  The peer could
   participate in as many as 4 EAP conversations in parallel.

   In order for the peer to be able to understand the meaning of each
   TID, a new mechanism would be needed to send information about
   authentication type and other policy hints.  Such a mechanism could
   either operate on the layer that carries GEE, or in an extended
   version of GEE itself.  Note that RFC 4284 defines a mechanism for
   the authenticator to advertise a set of roaming realms.  With this
   information alone, the peer needs to readily understand the nature of
   authentication based on the realm information.  However, in some
   cases, a peer may have multiple credentials (e.g., for device and
   user authentication) for a give realm and for that or other reasons,
   providing a list of realms alone may not be sufficient.  In those
   cases, the realm information itself is insufficient.  Similarly, due
   to EAP MTU and other considerations, RFC 4284 can carry only a very
   limited amount of information, and it is not intended for carrying
   other policy information.  As a result, its applicability for this
   purpose is limited, and other mechanisms are likely to be needed.
   This document does not propose any such mechanisms at this time.

Spencer: wasn't entirely clear on what this is saying - something like "EAP 
with GEE is more likely to trip over limited EAP MTU than EAP without GEE, 
so don't plan on using EAP to carry large amounts of data"? The current text 
seems to be more about EAP limitations than about GEE limitations.

   Specifically due to the introduction of additional capability to use
   the identity hints and indicating the type of authentication via
   extensible options (TLVs), the restriction imposed in GEEv0 for the
   semantics of the TID field can be removed for future versions.

Spencer: can you provide a pointer to where this introduction will happen?

   Furthermore, in the result code and flags field the last bit may be
   set to indicate the presence of TLVs in the GEE header.

Spencer: not sure how to reconcile this with "In GEEv0, the last bit is the 
R bit and is reserved and MUST be set to zero at the sender and MUST be 
ignored by the receiver." This is speculating about how a later version of 
GEE might work, perhaps? Something like "Furthermore, future versions of GEE 
may use the last bit of the result code and flags field to indicate the 
presence of TLVs in the GEE header"?

7.1.  Recap of use cases and interactions between network entities

   GEE encapsulates EAP so an authenticator can signal to the peer about
   the type of authentication the EAP request is meant for.  GEE also
   facilitates parallel execution of such authentications.  For
   instance, Type 1 and Type 2 authentication may take place in tandem

Spencer: Nit: s/in tandem/sequentially/

   (in any order) or in parallel.

7.2.  Threats and mitigation strategies

   The GEE header is not cryptographically protected.  Thus it is
   plausible for an eavesdropper to use Layer 2, GEE and EAP headers and
   collate information on how certain devices are authenticating
   themselves to their network providers: the order and combination of
   the different types of authentication are easily available in those
   headers.

   Note that if Type 1 (say, access) authentication occurs first and

Spencer: again, some of the text seems to assume that Type 1 IS access 
authentication, while other text does not seem to require this.

   subsequent authentication processes take place via a Layer 2
   encrypted channel, information about the rest of the authentications
   will not be available to passive observers on the path from the peer
   to the authenticator.

Spencer: this text could be recommending that Type 1 authentication happens 
before Type 2 authentication, but it's not recommending this, and the 
specification seems to go out of its way to NOT require this. I'm not sure 
why this text isn't SHOULD ("except in tightly-controlled environments"), if 
the alternative opens you to eavesdropping attacks. 7.2.2 seems to be a 
stronger statement than this one.

7.2.1.  Threats that might cause denial of service

   An adversary may change any of the contents of the GEE payload, the
   version field and/or the TID field, to cause either the peer or the
   authenticator to drop GEE encapsulated EAP packets.  Suppose an
   attacker consistently changes the value of the TID field, the AAA
   server may conclude that the peer's credentials may have been
   compromised and may revoke access so as to trigger an offline process
   for updating that peer's credentials.  As a result the peer may lose
   connectivity temporarily.  Note however that DoS attacks identical or
   similar to this are also possible on EAP conversations without GEE
   encapsulation.

Spencer: This might be clearer if you said "EAP conversations without GEE 
encapsulation are vulnerable to denial-of-service attacks, and GEEv0 does 
not change this vulnerability" someplace.

7.2.2.  Threats that might cause theft of service

   To mitigate this threat, i.e., when the EAP method used for one
   authentication (e.g., Type 2) is more vulnerable to attacks than the
   EAP method used for another authentication (e.g., Type 1), the
   authenticator needs to strictly enforce a policy of Type 1
   authentication first, and require that the Type 2 authentication
   occur within the secure channel established as a result of Type 1
   authentication.  Another possible solution is for the authenticator
   to maintain an association between the Layer 2 security association
   and Layer 3 address(es), to prevent rogue peers from stealing other
   peers' IP services.

Spencer: I'm not a security geek, but if the rogue peer goes first, wouldn't 
this proposed band-aid prevent the legitimate peer from "stealing BACK" its 
own IP services?

7.3.  Implications of multiple EAP authentications

   There are several possible mitigation strategies including the use of
   identifier binding between authentications (e.g., Layer 2 and Layer 3
   identifier correlation), or in case of sequential authentications,
   the use of key material from the first authentication to encrypt
   future authentications.  Other solutions require all authentications
   to be key generating and binding all the keys to generate the master
   key used to bootstrap the traffic key generation process or using
   multiple encapsulations using the generated keys.

Spencer: Nit: s/using/with/

   When the multiple authentications are key generating and occur in
   parallel, GEEv0 requires that the MSKs resulting from each
   authentication be all used for access control in order to

Spencer: Nit: s/the MSKs resulting from each authentication be all used/all 
of the MSKs resulting from each authentication be used/

   successfully prevent any MiTM attacks.  When only one of the
   authentications is key generating or when the authentications occur
   sequentially, other administrative policies must be used to ensure
   that the threat is mitigated. 

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