ietf
[Top] [All Lists]

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

2006-12-28 07:41:52
Hi Lakshminath,

On Wed, Dec 27, 2006 at 11:43:34PM -0800, Lakshminath Dondeti wrote:
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.

The functionality to run multiple EAP conversations between peer and
authenticator is part of EAP lower layer design that is specific to
each lower layer.  Hence, I am concerned if the intent is to allow GEE
to be used not only for 3GPP2 but also for other SDOs.  In fact, the 1
octet GEE field is not even needed if different frame types (e.g.,
Ether Types) or equivalent are used for identifying multiple EAP
conversations between peer and authenticator, where usually one frame
type or equivalent is allocated for EAP.


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

But there is nothing wrong that each EAP lower layer is designed in
different ways including support for multiple EAP conversations
between peer and authenticator.

Yoshihiro Ohba



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

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