ietf
[Top] [All Lists]

RE: IETF last call on draft-barany-eap-gee-04.txt

2007-01-02 18:57:06
Hi Bernard, Yoshi,
Following up on Lakshminath's suggestions, here are some changes we can
incorporate in the draft to move it forward. 

* Expected lower layer behavior - we will add a paragraph that
emphasizes that the lower layer must negotiate the use of GEE between
the peer and authenticator. It is necessary that the lower layer
indicate that the message type is GEE and not EAP. If such a message
type is not supported by the authenticator/peer, it will not be able
process those packets. So, there should be no confusion in processing
GEE packets as EAP packets by the lower layer. We will clarify this
behavior in the additional text. 

* Expected EAP behavior - GEE does not need any modifications to EAP.
The presence/absence of GEE is only handled by the lower layer. Perhaps
the figures are misleading - we can delete the figures as I don't think
they are adding much value anyway. We can make it clearer in the text
that this is not attempting to change any EAP behavior, if that is not
clear.  

* EAP lower layer and GEE - Bernard's review pointed out that the EAP
lower layer transport requirements are not discussed in the GEE draft.
GEE is not an EAP lower layer. GEE is a protocol that the EAP lower
layer can use to allow multiple parallel authentications. Also, this is
not quite the same as pre-authentication, since GEE is to allow multiple
authentications for different purposes (e.g., device and user; specific
types of accesses, say, IPv4 and IPv6, etc.). Pre-authentication, as
Lakshminath points out, can still be done with GEE and in fact, multiple
types of authentications can be done as pre-authentication. 

* Packet modification attacks - Bernard raised a question on packet
modification attacks leading to, say, Type 2 access being granted, when
only Type 1 authentication had occurred. Such MiTM attacks are not a
problem when appropriate key/identity binding requirements are met as
documented. OTOH, if the peer is malicious, it may try to use Type 1
credentials for Type 2 authentication or vice-versa. However, any time a
system expects multiple types of authentication, the authorization
information must be clearly sent from the backend server to the
authenticator, indicating the type of access the peer can be granted.
This is a need for multiple authentications with or without GEE. We can
add some text about this in the security considerations section to
clarify the required authorization information from the backend to the
authenticator. 

* Identity binding - Bernard points out the incorrect usage of peer IDs
in page 12. We will remove the text under "Single Access Control
Enforcement with Protected Result Indication" - when both methods are
key generating, the MSKs should be bound anyway. 

* On using CUI for identity binding - I think Bernard raises a good
point here. Perhaps, that doesn't make sense as an example and perhaps
should be removed. Jari, thoughts on this? 

We will fix the terminology and other nits suggested by Bernard as we
revise the document. 

Thanks,
Vidya


-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti(_at_)qualcomm(_dot_)com] 
Sent: Wednesday, December 27, 2006 11:44 PM
To: Bernard Aboba; Yoshihiro Ohba
Cc: Jari Arkko; Barany, Pete; ietf(_at_)ietf(_dot_)org
Subject: Re: IETF last call on draft-barany-eap-gee-04.txt

Hi Bernard, Yoshi,

Many thanks for your reviews and notes.  I am going to try 
and address the overarching issues.  Once we settle on those, 
we can take care of the details.

* On the use of the term "generic":
At the beginning of the GEE standardization effort, the idea 
was to specify the protocol and allow use of it by any EAP 
lower layer, irrespective of which standards body develops 
the lower layer.  Upon Jari's suggestion, we introduces the 
term 3GPP2 so as it stands now, GEE is only applicable to EAP 
lower layers defined by 3GPP2.  Please note that *multiple* 
lower layers specified by 3GPP2 may use it.  Furthermore, the 
intended status is "experimental."  The idea is to try it out 
and if all goes well, allow the protocol to be used by any 
lower layer.  Finally, the mechanism over the period of 1 
year or so has been known as GEE, so we would like to 
continue to use that term.

* On correctly parsing the GEE header:
Indeed EAP lower layers (would have to) specify how a peer 
and an authenticator can negotiate whether to use EAP or GEE 
(and versions within GEE etc); after that though, there would 
not be any incorrect parsing of a GEE header as an EAP header.

Perhaps it is best to specify that this is expected of the 
EAP lower layer in the GEE I-D.  Would that resolve this concern?

* On specifying GEE at the IETF:
Surely, GEE could have been specified as part of the EAP 
lower layer, but that would mean each lower layer would have 
to specify it independently and as with most things, those 
sort of exercises tend to end up with results slightly (or 
vastly, take your pick) different from each other.

Next, where as it is true that pre-authentication does allow 
multiple EAP conversations to occur in parallel, it is 
important to note that pre-authentication merely solves a 
subset of the problems.  In fact, there is nothing to say 
that pre-authentication cannot be used with GEE.  It can very 
well be used.

(Also please see the explanation for the use of the term 
"generic" on why GEE is better specified at the IETF).  Jari 
also provides a justification for this in his latest email.

* On getting an expert review of 3GPP2's EAP lower layers by the IETF:
As it turns out, Vidya suggested this very thing at the 
beginning of the GEE standardization effort to some of our 
3GPP2 colleagues.  The decision of course will be made by 
3GPP2 (the IESG can send an LS of course).  3GPP2 may develop 
one or more EAPoBlah standards and we can try and suggest to 
them that a review by the IETF in each case would be 
worthwhile.  In the same vein, it appears that with GEE they 
have identified a piece of common functionality that they 
think is best specified at the IETF.

Once we agree on the above issues, we can move forward and 
discuss things like key binding, how authenticators might 
keep track of results from the multiple authentications etc.  
Thanks also for your notes on inconsistencies (e.g., upside 
down layering diagram) and gaps in explanations.  We will fix 
those as part of the next revision of the draft.

Thanks again for your review and best wishes for the new 
year, Lakshminath

At 05:00 PM 12/24/2006, Bernard Aboba wrote:
Review of draft-barany-eap-gee-04.txt

Overall Comments

The title of this document "3GPP2 Generic EAP Encapsulation (GEE) 
Protocol" is somewhat of a contradiction in terms, implying both a 
mechanism that is specific to 3GPP2, as well as a "generic" 
encapsulation, suitable for use with any link layer.

This contradiction carries through much of the document, leaving the 
reader uncertain whether the authors are describing a 3GPP2-specific 
lower layer encapsulation of EAP, or a more general 
mechanism that is 
intended for use with *all* existing EAP lower layers.

If the document is intended to describe an EAP lower layer, then it 
should not contain language suggesting that EAP peer and 
authenticator 
implementations need to be modified for use with GEE, or 
diagrams that 
show GEE sitting above the EAP lower layer.

The problem with a generic EAP shim is that the architecture 
described 
in RFC 3748 does not provide a mechanism for negotiation of its use, 
and therefore there is no generic (e.g. non-link layer specific) way 
for backwards compatibility to be maintained.

As a result, introducing a shim as described in this 
document requires 
modification to existing EAP lower layers, or it risks introducing 
interoperability problems within existing implementations. 
No existing 
EAP lower layer has been defined to handle the GEE header, 
and if such 
a header were to blindly inserted, it would be interpretted 
it as the 
EAP Packet Code field by existing EAP peers, authenticators and 
servers:

      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |Version|TID|RFL|
      +-+-+-+-+-+-+-+-+

The version field = 0, and the TID field = 00/01.   The RFL bits are 
= 10 or 00.
Given this, the GEE header would be interpreted as one of 
the following 
EAP Packet Code values:

0 (TID = 0, RFL = 00)  (Reserved in RFC 3748)
2 (TID = 0, RFL = 10) (Response, in RFC 3748)
4 (TID=01, RFL = 00) (Failure, defined in RFC 3748).
6 (TID=01, RFL=10) Not defined in RFC 3748.

RFC 3748-conformant EAP implementations would be likely to silently 
discard Packet Codes of Types 0 and 6, and would also 
discard Code 2 if 
sent by an EAP authenticator and Code 4 if sent by an EAP peer.

While the document states that conforming implementations are to add 
and strip off the GEE header, it is not made clear how use 
of EAP GEE 
is negotiated so that EAP peer and authenticator implementations can 
tell if it is being used or not.  Presumably this negotiation is to 
occur in the link layer, but since no existing EAP link 
layers support 
such a negotiation, and the document does not describe how 
it works, I 
am not clear about whether backward compatibility is being 
maintained or not.

Given that link layer negotiation seems to be required and 
no existing 
link layer supports such a negotiation, GEE appears 
incompatible with 
existing EAP lower layers other than perhaps 3GPP2.

A generic shim that only (maybe) works with a single link layer is 
somewhat of a contradiction.

Given the problems of a generic EAP shim, the document makes 
much more 
sense if it is viewed as part of a definition of a 3GPP2 lower layer 
for EAP.  Presumably 3GPP2 has defined a mechanism by which 
the use of 
GEE can be negotiated, and once this is done,  3GPP2 peers and 
authenticators can encapsulate and decapsulate EAP packets within a 
3GPP2 lower layer including the GEE header. This kind of 
encapsulation/decapsulation is described in RFC 3748 as part of the 
operation of a lower layer, so inclusion of GEE within the 
3GPP2 lower 
layer definition makes much more architectural sense.

However, given the current orientation of the document, significant 
rework would be required to recast the GEE scheme as a 
3GPP2-specific 
lower layer definition.  Currently the document does not really get 
into sufficient detail to understand exactly how EAP is to be 
encapsulated when run over 3GPP2.  For example, there is no 
discussion 
of lower layer requirements for transport of EAP packets, as 
discussed 
in RFC 3748, Section 3.1.

Specific Comments

Abstract

   This document specifies the 3GPP2 Generic EAP Encapsulation (GEE)
   protocol for differentiating between multiple EAP 
conversations between
   a peer and an authenticator.

As noted earlier, this paragraph presents GEE as a generic update to 
the EAP specification when it seems more appropriate as part 
of a 3GPP2 
lower-layer definition.

   As CDMA2000 third generation cellular networks evolve 
[8], [9], EAP
   will also be used as a general authentication protocol that runs
   directly over the data link layer [10].

Is GEE support included in reference [10]?  I presume that 
it is, since 
otherwise, I don't see how the mechanism described in the document 
could be deployed.

   EAP can be used for different types of authentication, 
where multiple
   providers provide access to different services.  
However, EAP itself
   does not have the ability to differentiate between multiple EAP
   conversations between a peer and an authenticator.

In general, differentiation between conversations is the task of the 
lower layer, so this is not an EAP architectural issue.

   This document specifies the 3GPP2 Generic EAP Encapsulation (GEE)
   protocol for differentiating between multiple EAP conversations
   between a peer and an authenticator.  In the rest of 
this document,
   we refer to this protocol as GEE, Version 0 or GEEv0.

Given the title of the document, I was expecting something 
more along 
these lines:

This document defines a mechanism implemented as part of the 3GPP2 
lower layer support for EAP defined in [10] which enables 
differentation between multiple EAP conversations occuring 
over a 3GPP2 link layer.
As a result, the mechanism described in this document is specific to
3GPP2 and is not applicable to other EAP lower layers.

   Figure 1 shows an example of the case where the access network
   provider is different from the service network provider.  The ANP
   hosts the Authenticator (NAS or Network Access Server in 
the figure)
   and an Authentication Server (AAA-ANP in the figure).  
The SNP may
   have its own Authentication Server (AAA-SNP in the figure).

This figure implicitly assumes use of an EAP lower layer 
that enables 
multiple EAP conversations to be ongoing at the same time.  Not all 
existing EAP lower layers permit this.  For example, WPA does not 
support pre-authentication or make-before-break, and therefore EAP 
authentication is only permitted between a STA and an AP that it has 
successfully associated to. A STA can only be associated to 
a single AP 
within an ESS (associations to separate ESSes are possible via 
multi-net).  As a result, I would suggest that the lower 
layer assumptions be stated.

   When a peer is performing multiple EAP
   authentications, it is not possible to clearly 
differentiate between
   the two types of authentications using available means...
   Hence, there is no available means to allow multiple EAP
   authentications for a given peer to occur in
   parallel.

Some existing EAP lower layers do enable an EAP peer to conduct 
multiple EAP authentications in parallel.  For example, a STA 
supporting WPA2 pre-authentication can initiate multiple 
simultaneous 
EAP authentications (to different BSSIDs).

   While EAP methods are TLV-based and can easily be 
extended to carry
   additional information between the peer and the server, 
EAP itself
   does not provide a means to carry any additional 
information between
   the peer and the authenticator.

Not all EAP methods are TLV based, and as described in RFC 3748, the 
lower layer can also carry "additional information" such as a GEE 
header.

   It is important that the EAP peer
   and authenticator be able to differentiate between the access and
   service authentication exchanges for multiple reasons.  
For example,
   it allows proper routing of the messages to the appropriate EAP
   server and allows the two exchanges to happen in parallel.

EAP peers and authenticators already do this today, as noted 
earlier. 
However, this does not relate to routing of EAP packets to 
EAP servers;  
that is handled via the EAP Identity Request/Response mechanism as 
described in RFC 3748 and 3579.

   Hence, the primary motivation for this document is to provide the
   functionality for EAP peers and authenticators to differentiate
   between multiple EAP exchanges that a peer may be executing in
   parallel to gain access to different networks or services.

As described above, the title suggests that the motivation is to 
describe a 3GPP2-specific EAP lower layer encapsulation.


relate t  routing of EAP messages to EAP servers.  That routing is 
handled uthenticator
        +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
        |           |           |  |           |           |
        | EAP method| EAP method|  | EAP method| EAP method|
        | Type = X  | Type = Y  |  | Type = X  | Type = Y  |
        |       V   |           |  |       ^   |           |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |  EAP  ! layer         |  |  EAP  ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        |   GEE ! layer         |  |   GEE ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        |       !               |  |       !               |
        | Lower ! layer         |  | Lower ! layer         |
        |       !               |  |       !               |
        +-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
                !                          !
                !                          !
                +------------>-------------+


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

In this diagram, GEE should be included as part of the lower layer, 
rather than a distinct entity below the EAP layer, given that GEE 
cannot function without modifications to the lower layer.

        Peer            Pass-through Authenticator    Authentication
                                                          Server
      +-+-+-+-+-+-+                                   +-+-+-+-+-+-+
      |           |                                   |           |
      |EAP method |                                   |EAP method |
      |     V     |                                   |     ^     |
      +-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
      |     !     |   |EAP  |  EAP  |             |   |     !     |
      |     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
      |EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
      |     !     |   |     | !     |     !       |   |     !     |
      +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
      |     !     |   |       !     |     !       |   |     !     |
      |EAP  !layer|   |   EAP !layer|     !       |   |     !     |
      |     !     |   |       !     | EAP ! layer |   | EAP !layer|
      +-+-+-!-+-+-+   +-+-+-+-!-+-+-|     !       |   |     !     |
      |GEE  !layer|   |   GEE !layer|     !       |   |     !     |
      +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
      |     !     |   |       !     |     !       |   |     !     |
      |Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
      |     !     |   |       !     |     !       |   |     !     |
      +-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
            !                 !           !                 !
            !                 !           !                 !
            +-------->--------+           +--------->-------+

This diagram is also problematic because the kind of decapsulation 
described here can only be carried out by an EAP lower layer, not 
within the EAP layer itself.  If GEE is included as part of 
the lower 
layer, then the diagram makes more sense, since it would be 
clear that 
GEE requires lower layer modifications.

   When the authenticator operates in pass-through mode, 
the GEE layer
   terminates at the authenticator and the EAP packet is sent over a
   backend AAA layer (e.g., RADIUS [11]).  In this case, the
   authenticator must handle the GEE fields in exactly the 
same manner
   as in the multiplexing model.  The fields in the GEE 
header may be
   used by the authenticator to identify the correct EAP exchange to
   properly route the EAP packet.  A Transaction ID (TID) 
field defined
   in the protocol allows the EAP exchanges to be 
distinguished.  The
   TID field is used to look up the appropriate domain to which a
   particular EAP message must be routed.

As described in RFC 3748, the behavior described above can only be 
satisfied by an EAP lower layer, since a legacy EAP 
implementation will 
not know how to add or strip a GEE header.  So the term "GEE-enabled 
lower layer" would be more appropriate than "GEE layer".

   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.

Since existing EAP lower layers already support multiple 
simultaneous 
authentications with different authenticators (and different EAP 
servers), this scenario can be realized today, without the 
GEE header.

   Since GEE runs between the peer and the authenticator, 
it brings a
   slight variance when the authenticator for each EAP exchange is
   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.

Actually, the lower layer *always* needs to support the GEE 
header, right?

       ---------------------------------
       |                               |
       |    Data link layer header     |
       |                               |
       ---------------------------------
       |                               |
       |         GEE header            |
       |                               |
       ---------------------------------
       |                               |
       |         EAP packet            |
       |                               |
       ---------------------------------

This diagram is upside down (other diagrams put EAP layer on 
top of the 
GEE layer).

   Version

      The first 4 bits in the GEE header represent the 
protocol version
      number.  This field MUST be set to 0 for GEEv0.

   Transaction ID (TID)

      A 2-bit TID flag is used to distinguish between multiple EAP
      conversations.  In Version 0 of GEE (GEEv0), the TID 
field MUST be
      either 00 or 01.  When TID = 01, the encapsulated EAP 
packet is
      for Type 1 authentication.  When TID = 00, the 
encapsulated EAP
      packet is for Type 2 authentication.  In GEEv0, TID 
values other
      than 00 and 01 are reserved and MUST NOT be used.

Why are 4 bits used for the Version, but only 2 for the 
transaction ID?
Existing EAP lower layers can handle more than 4 simultaneous EAP 
authentications, so that a two bit transaction ID seems to provide
*less* flexibility than already exists.

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

Statements about the use of an MSK only really make sense 
within the a 
lower layer definition, since presumably the EAP method will 
output the 
MSK/EMSK as it would normally, with no awareness that GEE is being 
used.

   When the peer receives a GEEv0 packet, the TID field in the GEEv0
   header MUST be used to determine if the encapsulated EAP 
packet is
   for Type 1 or Type 2 authentication.  If TID value is 01 in the
   packet received from the authenticator, the peer must perform the
   necessary Type 1 authentication.  For instance, this may 
mean that
   the peer provides the appropriate identity and use the 
appropriate
   EAP method in the EAP session.  When the TID is set to 00 in the
   packet received from the authenticator, the peer must perform the
   necessary Type 2 authentication.

At first glance, this appears to be a statement about EAP packet 
handling.  I would rephrase it to say "when a 3GPP2 lower layer 
receives a GEEv0 packet... if the enapsulated 3GPP2 frame is 
for Type 1 
or Type 2 authentication... the 3GPP2 lower layer must perform the 
necessary Type 1 authentication..."

5.2.  Packet Handling at the Authenticator

   When the authenticator receives a GEEv0 packet, the TID 
value in the
   header MUST be used to determine if the encapsulated EAP 
packet is
   for Type 1 or Type 2 authentication.

Again, I don't believe that this document should be modifying EAP 
authenticator behavior described in RFC 3748.  This should 
be modified 
to say "when the 3GPP2 lower layer residing on the authenticator 
receives..."

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

This diagram suggests that network access can be granted 
even if one of 
the authentications fail.  If the GEE header is not 
protected (it would 
be hard to protect unless it represented a 
re-authentication, since no 
keys have been derived), this seems like it could result in 
a privilege 
elevation attack.  For example, unless the NAS kept track of which 
conversation related to which GEE header, an attacker could 
potentially 
modify the GEE header in transit, resulting in granting a different 
Type of access than was intended.  For example, the attacker could 
modify a GEE Type 1 to a GEE Type 2, etc.

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

How does GEE enforce this requirement?  If GEE is part of the lower 
layer, then it makes more sense to say "3GPP2 lower layers 
require that 
at least one...".

   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.

Since different AAA servers can issue different CUIs for the 
same user, 
I am not clear how a NAS could compare them.  And in any 
case, the CUI 
document describes the returned attributes as opaque blobs, no?

   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.

The use of terms such as "combined MSK" suggest that this 
document is 
updating RFC 3748.  I would suggest that a different term be 
used, such 
as "Intermediate Key Binding" (IMSK).

  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
      attack may be plausible in this case, and hence it is NOT
      RECOMMENDED.

I'm unclear what this paragraph is intending to say.  The 
authenticator 
is presumably unable to correlate peer-IDs, given that it is 
operating 
in "pass-through" and may not even have visibility into the 
EAP method 
exchanges since they are encrypted with keys it does not have access 
to.  Does the paragraph mean to imply that the NAS requests 
the Peer-Id 
attribute be sent to it by the AAA server?

   When two EAP authentications are performed, it is always 
feasible to
   use keys from a first exchange to protect a subsequent exchange.
   Note that the two authentications in this case will occur
   sequentially and the first method must be key 
generating.  The use of
   GEE does not preclude such an operation, even though the main
   motivation for GEE is to allow parallel execution of the EAP
   exchanges.

In fact, existing lower layer specifications *require* that the 
authentications be handled sequentially.  For example, in WPA/WPA2, 
receipt of keys kicks off the 4-way handshake.  This is 
another reason 
why GEE is inherently incompatible with existing EAP lower layers.

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.

As noted earlier, this is already possible.

   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.

Given that existing implementations can already handle multiple 
authentications, I don't understand why "policy hints" need 
to be sent 
across the wire.

   If the EAP method used for one authentication is known 
to be weaker
   than the EAP method used for another authentication, whereas the
   authenticator may intend to enforce one authentication before the
   other, an attacker may modify the GEE flags to cause the peer to
   start the weaker authentication without the protection 
of stronger
   authentication.  The adversary may then be able to break 
the weaker
   authentication method and gain access to services.  Even if the
   authenticator requires, say, both Type 1 and Type 2 
authentications
   from all peers, it is plausible for a rogue peer with available
   credentials for Type 1 authentication to gain access to Type 2
   services for which it does not have proper credentials.

Wouldn't it also be possible for an attacker to gain access to a 
different service type (1 vs. 2) by packet modification?

   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.

The problem is that EAP authentication typically occurs 
*before* layer 
3 addresses are assigned, so that this would require the 
authenticator 
to snoop on layer 3 traffic occuring after authentication, 
as well as 
to keep additional state.

   Suppose a peer has credentials for Type 1 authentication 
in a visited
   network and credentials for both Type 1 and Type 2 
authentication in
   the home network.  It is plausible that the peer may 
supply its home
   network credentials for Type 1 as well as Type 2 
authentication and
   thereby avoid any payments to the visited ANP.  To avoid this
   possibility, the AAA-ANP may send to the authenticators 
its Type 1
   authentication policy by sending a list of realms for 
which Type 1
   authentication request is allowed to be forwarded to 
home network.
   The authenticator may share that information with the 
peer in the EAP
   identity request following the semantics in RFC 4284 
[13] or other
   similar procedures.

Since RFC 4284 hints are unprotected, it seems like this would be 
vulnerable to active attack.

   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.

As described earlier, this would require authenticators to snoop on 
layer 3 exchanges and keep additional state on EAP peers.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>