Subject: Re: [eap] Proposed Resolution to Issue 365: Ambiguous Use ofIdentifier

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 9 Jun 2006 10:35:34 -0700

Hi Bernard,

I think this looks better with respect to identifier terminology.
Additional comments and questions in line below: 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Sunday, June 04, 2006 5:48 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [eap] Proposed Resolution to Issue 365: 
> Ambiguous Use ofIdentifier
> 
> Looking over the proposed resolution, I think we can make it 
> moreclear that 
> we are not talking about replacing endpoint addresses with 
> names.  How about 
> this?
> 
> "2.2.2. Authenticator and Peer Identification
> 
> The EAP method conversation is between the EAP peer and server. The
> authenticator identity, if considered at all by the EAP method, is
> treated as an opaque blob for the purposes of Channel Bindings (see
> Section 5.12). However, the authenticator identity is important in
> two other exchanges - the AAA protocol exchange and the Secure
> Association Protocol conversation.
> 
> The AAA conversation is between the EAP authenticator and the backend
> authentication server. From the point of view of the backend
> authentication server, EAP keying material and parameters are
> transported to the EAP authenticator identified by the NAS-Identifier
> attribute. Since an EAP authenticator MUST NOT share EAP keying
> material or parameters with another party, if the EAP peer or backend
> authentication server detects use of EAP keying material and
> parameters outside the scope defined by the NAS-Identifier, the
> keying material MUST be considered compromised.
> 

[Joe] The section should clarify that the keying material refers to keys
derived from the EAP MSK that are transmitted to the authenticator.

Is it possible for an authenticator to be distributed across several
devices?  If so then the NAS identifiers may not be the best choice in
these cases.  Also what should be used in the Security association
protocol if there is no AAA client (collocated authenticator)?  

> The Secure Association Protocol conversation is between the peer and
> the authenticator. For lower layers which support key caching it
> is particularly important for the EAP peer, authenticator and backend
> server to have a consistent view of the usage scope of the transported
> EAP keying material.  In order to enable this, it is RECOMMENDED
> that the Secure Association Protocol explicitly communicate the
> usage scope of the EAP keying material passed down to the lower
> layer, rather than implicitly assuming that this is defined by
> the authenticator and peer endpoint addresses.
> 
> Since an authenticator may have multiple ports, the scope of the
> authenticator key cache may not be described by a single endpoint
> address.  Similarly, where a peer may have multiple ports and
> sharing of EAP keying material and parameters between peer ports
> of the same link type is allowed, the extent of the peer key cache
> cannot be communicated by using a single endpoint address.
> Instead, it is RECOMMENDED that the EAP peer, authenticator and server
> consistently identify themselves utilizing explicit identifiers that
> SHOULD be  distinct from endpoint addresses or port identifiers
> (e.g. IP or MAC addresses).
> 
> AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide
> a mechanism for the identification of AAA clients; since the EAP
> authenticator and AAA client are always co-resident, this mechanism
> is applicable to the identification of EAP authenticators.
> 
> RADIUS [RFC2865] requires that an Access-Request packet contain one
> or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
> attributes. Since a NAS may have more than one IP address, the
> NAS-Identifier attribute is RECOMMENDED for explicit identification
> of the authenticator, both within the AAA protocol exchange and
> the Secure Association Protocol conversation.
> 
> It is possible for problems to arise in situations where the
> backend server identifies itself differently to the EAP peer
> and authenticator (e.g. where the Server-Id and backend authentication
> server identity differ).  

[Joe] It would seem that currently they almost always differ since the
back end server is identified by the IP address to the authenticator and
by the EAP method to the peer.  What problems are you referring to?

> Problems which may arise where the peer and
> authenticator implicitly identify themselves using endpoint addresses
> include the following:
> 
> [a] It may not be obvious to the peer which authenticator ports are
> associated with which authenticators.  The EAP peer will be unable
> to determine whether EAP keying material has been shared outside
> its authorized scope, and needs to be considered compromised. The
> EAP peer may also be unable to utilize the authenticator key cache
> in an efficient way.
> 
> [b] It may not be obvious to the authenticator which peer ports are
> associated with which peers. As a result, the authenticator may
> not be able to enable a peer to communicate with it utilizing
> multiple peer ports.
> 
> [c] It may not be obvious to the peer which "virtual authenticator" it
> is communicating with. For example, multiple "virtual
> authenticators" may share a MAC address, but utilize different
> NAS-Identifiers.
> 
> [d] It may not be obvious to the authenticator which "virtual peer" it
> is communicating with. Multiple "virtual peers" may share a MAC
> address, but utilize different Peer-Ids.
> 
> [e] It may not be possible for the EAP peer and server to verify the
> authenticator identity via channel bindings.
> 
> For example, problems [a], [c] and [e] occur in [IEEE-802.11i], which
> utilizes peer and authenticator MAC addresses within the 4-way
> handshake. Problems [b] and [d] do not occur since [IEEE-802.11i]
> only allows a peer to utilize a single port.
> 
> The following steps enable lower layer identities to be securely
> verified by all parties:
> 
[Joe] What does lower layer identities mean in this case?  Does this
mean peer, authenticator and port identities?

> [a] Specifying the lower layer parameters used to identify the
> authenticator and peer;
> 
> [b] Communicating the lower layer identities between the peer and
> authenticator within phase 0;
> 
> [c] Communicating the lower layer authenticator identity between the
> authenticator and backend server within the NAS-Identifier
> attribute;
> 

[Joe] Is this necessary or desirable?  If the AAA server does not
already what the NAS-ID associated with the NAS, is it OK for the NAS to
assert this?  If the NAS can assert whatever it wants why are we
bothering to do channel bindings?

> [d] Including the lower layer identities within Channel Bindings (if
> supported) in phase 1a, ensuring that they are communicated between
> the EAP peer and server;
> 
> [e] Supporting the integrity-protected exchange of identities within
> phase 2a;
> 
> [f] Utilizing the advertised lower layer identities to enable the peer
> and authenticator to verify that keys are maintained within the
> advertised scope;"
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Jun 2006 20:32:13 -0700

>derived from the EAP MSK that are transmitted to the authenticator.

Why are the considerations different for EMSK derived keys?  The AAA server 
still has to know who the keys are being sent to, or they can't be delivered 
(e.g. a proxy could be in the path).  The NAS-Identifier attribute tells the 
AAA server who that destination is.

>protocol if there is no AAA client (collocated authenticator)?

The authenticator can only be distributed if the peer and server see it as a 
single entity, so that there is no indication that the keying material has 
been shared outside of the legal scope, which is defined by the 
NAS-Identifier.  If the keys are passed among entities that are identified 
as distinct authenticators, then the peer and server will detect that the 
keys have been compromised.

For example, it's ok for an authenticator's ports to be identified by 
distinct MAC addresses or IP addresses. Since an authenticator can have 
multiple ports. use of a different port authenticator doesn't imply a 
different authenticator.  But if multiple authenticators with different 
NAS-Identifiers possess the same key, then that indicates that those keys 
have been compromised.

>by the EAP method to the peer.  What problems are you referring to?

The issue arises in situations where an entity needs to retrieve a key from 
the AAA server.  Since all AAA servers can't be assumed to share a key 
cache, the specific server on which the key resides needs to be identified.

A peer cannot ask an authenticator to retrieve a key unless it can provide 
both the Key Name and the server from which it needs to be retrieved.  In 
effect, the Peer-Id and Server-Id need to be part of the Key Name.

However, an authenticator cannot retrieve a key from the server if it has no 
way of mapping the Server-Id to a server that it recognizes.

In Diameter, server can be identified by name, since Diameter supports 
DNS-based service location as well as certificate authentication 
(altSubjectName).   So if the Server-Id is an FQDN, then the Diameter client 
can reach that server.

In RADIUS servers are identified only by IP address.  So presumably a RADIUS 
server would need to resolve the Server-Id FQDN to an IP address to figure 
out which server to make the key request to.  If the Server-Id and AAA 
server FQDN are different then the message may not be deliverable.

This issue is not purely academic -- it will come up in the EAPEXT BOF at 
IETF 66.

>mean peer, authenticator and port identities?

I assume that we're talking about peer and authenticator identities.  
Comments below.

> > [a] Specifying the lower layer parameters used to identify the

It is possible to uniquely identify an authenticator in multiple ways.  For 
example, a MAC address could be used, as long as it was associated with the 
entire authenticator and not just a port of it.

> > authenticator within phase 0;

If this is not done, then the peer may not know the authenticator scope.

> > authenticator and backend server within the NAS-Identifier

So whatever authenticator identity is chosen to be sent to the peer also 
needs to be sent to the backend server.

>bothering to do channel bindings?

RADIUS REQUIRES the NAS to identify itself, using NAS-Identifier, 
NAS-IPv6-Address or NAS-IPv4-Address.   However, if the NAS has more than 
one IP address, NAS-Identifier makes the most sense, regardless of any EAP 
considerations.   If there is a proxy present, then the proxy needs to 
validate the NAS-Identifier; by the time it gets to the AAA server, it is 
not possible to validate it.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Jun 2006 21:35:05 -0700

To improve the clarity of the sections on Authenticator, Peer and Server 
Identification, I've done some rewriting.  How about this?

"2.2.1.  Authenticator and Peer Identification

                               +-+-+-+-+
                               | EAP   |
                               | Peer  |
                               +-+-+-+-+
                                 | | |  Peer Ports
                                /  |  \
                               /   |   \
                              /    |    \
                             /     |     \
                            /      |      \
                           /       |       \
                          /        |        \
                         /         |         \     Authenticator
                      | | |      | | |      | | |   Ports
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                    |       |  |       |  |       |
                    | Auth1 |  | Auth2 |  | Auth3 |
                    |       |  |       |  |       |
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                         \        | \         |
                          \       |  \        |
                           \      |   \       |
             EAP over AAA   \     |    \      |
               (optional)    \    |     \     |
                              \   |      \    |
                               \  |       \   |
                                \ |        \  |
                             +-+-+-+-+-+  +-+-+-+-+-+  Backend
                             |  EAP    |  |  EAP    |  Authentication
                             | Server1 |  | Server2 |  Servers
                             +-+-+-+-+-+  +-+-+-+-+-+

   Figure 3: Relationship between EAP peer, authenticator and server

   The Secure Association Protocol conversation is between the peer and
   the authenticator.  For lower layers which support key caching it is
   particularly important for the EAP peer, authenticator and backend
   server to have a consistent view of the usage scope of the
   transported EAP keying material.  In order to enable this, it is
   RECOMMENDED that the Secure Association Protocol explicitly
   communicate the usage scope of the EAP keying material passed down to
   the lower layer, rather than implicitly assuming that this is defined
   by the authenticator and peer endpoint addresses.

   Since an authenticator may have multiple ports, the scope of the
   authenticator key cache may not be described by a single endpoint
   address.  Similarly, where a peer may have multiple ports and sharing
   of EAP keying material and parameters between peer ports of the same
   link type is allowed, the extent of the peer key cache cannot be
   communicated by using a single endpoint address.  Instead, it is
   RECOMMENDED that the EAP peer and authenticator consistently identify
   themselves utilizing explicit identifiers, rather than endpoint
   addresses or port identifiers.

   RADIUS [RFC2865] requires that an Access-Request packet contain one
   or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
   attributes. Since a NAS may have more than one IP address, the NAS-
   Identifier attribute is RECOMMENDED for explicit identification of
   the authenticator, both within the AAA protocol exchange and the
   Secure Association Protocol conversation.

   Problems which may arise where the peer and authenticator implicitly
   identify themselves using endpoint addresses include the following:

[c]  It may not be obvious to the peer which "virtual authenticator" it
     is communicating with.  For example, multiple "virtual
     authenticators" may share a MAC address, but utilize different NAS-
     Identifiers.

[f]  Specifying the lower layer parameters used to identify the
     authenticator and peer.  As noted earlier, endpoint or port
     identifiers are not recommended for identification of the
     authenticator or peer when it is possible for them to have multiple
     ports.

[g]  Communicating the lower layer identities between the peer and
     authenticator within phase 0.  This allows the peer and
     authenticator to determine the key scope if a key cache is
     utilized.

[h]  Communicating the lower layer authenticator identity between the
     authenticator and backend server within the NAS-Identifier
     attribute.

[i]  Including the lower layer identities within Channel Bindings (if
     supported) in phase 1a, ensuring that they are communicated between
     the EAP peer and server.

[j]  Supporting the integrity-protected exchange of identities within
     phase 2a.

[k]  Utilizing the advertised lower layer identities to enable the peer
     and authenticator to verify that keys are maintained within the
     advertised scope.

2.2.2.  Virtual Authenticators

   When a single physical authenticator advertises itself as multiple
   "virtual authenticators", if the virtual authenticators do not
   maintain logically separate key caches, then by authenticating  to
   one virtual authenticator, the peer can gain access to the other
   virtual authenticators sharing a key cache.

   For example, where a physical authenticator implements "Guest" and
   "Corporate Intranet" virtual authenticators,  an attacker acting as a
   peer could authenticate with the "Guest" "virtual authenticator" and
   derive EAP keying material.  If the "Guest" and "Corporate Intranet"
   virtual authenticators share a key cache, then the peer can utilize
   the EAP keying material derived for the "Guest" network to obtain
   access to the "Corporate Intranet" network.

   In order to address this vulnerability:

[a]  Authenticators are REQUIRED to cache associated authorizations
     along with EAP keying material and parameters and to apply
     authorizations consistently.  This ensures that an attacker cannot
     obtain elevated privileges even where the key cache is shared
     between "virtual authenticators".

[b]  It is RECOMMENDED that physical authenticators maintain separate
     key caches for each "virtual authenticator".

[c]  It is RECOMMENDED that each "virtual authenticator" identify itself
     consistently to the peer and to the backend authentication server,
     so as to enable the peer to verify the authenticator identity via
     Channel Bindings (see Section 5.11).

[d]  It is RECOMMENDED that each "virtual authenticator" identify itself
     distinctly, in order to enable the peer and backend server to tell
     them apart.  For example, this can be accomplished by utilizing a
     distinct NAS-Identifier attribute or BSSID.

2.3.  Server Identification

   The EAP method conversation is between the EAP peer and server, as
   identified by the Peer-Id and Server-Id.  As shown in Figure 3, an
   authenticator may be configured to communicate with multiple EAP
   servers; the EAP server that an authenticator communicates with may
   vary according to configuration and network and server availability.
   While the EAP peer can assume that all EAP servers within a realm
   have access to the credentials necessary to validate an
   authentication attempt, it cannot assume that all EAP servers share
   persistent state.

   Authenticators may be configured with different primary or secondary
   EAP servers, in order to balance the load.  Also, the authenticator
   can dynamically determine the EAP server to which requests will be
   sent; in event of a communication failure, the authenticator may fail
   over to another EAP server.  For example, in Figure 3, Authenticator2
   may be initially configured with EAP server1 as its primary backend
   authentication server, and EAP server2 as the backup, but if EAP
   server1 becomes unavailable, EAP server2 may become the primary
   server.

   In general, the EAP peer cannot direct an authentication attempt to a
   particular EAP server within a realm; this decision is made solely by
   the authenticator.  Nor can it determine which EAP server it will be
   communicating with, prior to the start of the EAP method
   conversation.  The Server-Id is not included in the EAP-
   Request/Identity, and since the authenticator determines the EAP
   server dynamically, it typically is not possible for the
   authenticator to advertise the Server-Id during the discovery phase.
   EAP methods may or may not export the Server-Id, and as a result, the
   EAP peer may not even learn which server it was conversing with after
   the EAP conversation completes successfully.

   As a result, an EAP peer, on connecting to a new authenticator or
   reconnecting to the same authenticator, may find itself communicating
   with a different EAP server.  Fast reconnect, defined in [RFC3748]
   Section 7.2, may fail if the EAP server that the peer communicates
   with is not the same one with which it initially established a
   security association.  For example, an EAP peer attempting an EAP-TLS
   session resume may find that the new EAP-TLS server will not have
   access to the TLS Master Key identified by the TLS Session-Id, and
   therefore the session resumption attempt will fail, requiring
   completion of a full EAP-TLS exchange.

   EAP methods that support mutual authentication may not allow the EAP
   peer to verify the EAP server identity.  For example, the EAP peer
   may only verify that the EAP server possesses a long-term secret; in
   this case the EAP peer will only know that an authenticator has been
   authorized by an EAP server, but will not confirm the identity of the
   EAP server.

   EAP methods that export the Server-Id MUST verify the server
   identity.  As noted in Appendix A, existing EAP methods exporting the
   Server-Id determine this from the altSubjectName in the server
   certificate, and as a result, the peer determines the identity of the
   server (expressed as a Fully Qualified Domain Name (FQDN)) by
   validating the server certificate.

   Validating the EAP server identity enables the EAP peer to decide
   whether a specific EAP server is authorized, and to determine whether
   the EAP server is sharing keying material outside the intended scope.
   In some cases, such as where the certificate extensions defined in
   [RFC4334] are included in the server certificate, it may even be
   possible for the peer to verify some Channel Binding parameters from
   the server certificate.  Where the EAP peer does not verify the EAP
   server identity, it is not possible for the peer to determine whether
   the EAP server has shared keying material outside its authorized
   scope.

   It is possible for problems to arise in situations where the EAP
   server identifies itself differently to the EAP peer and
   authenticator.  For example, the Server-Id exported by EAP methods
   may not be identical to the Fully Qualified Domain Name (FQDN) of the
   backend authentication server.  Where certificate-based
   authentication is used within RADIUS or Diameter, the altSubjectName
   used in the backend server certificate may not be identical to the
   Server-Id or backend server FQDN.

   Where the backend server FQDN differs from the altSubjectName in the
   certificate, the AAA client may not be able to successfully determine
   whether it is talking to the correct backend authentication server.
   Where the Server-Id and backend server FQDN differ, the combination
   of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
   (Session-Id) may not be sufficient for the authenticator to determine
   where the key resides.  For example, the authenticator may identify
   backend servers by their IP address (as occurs in RADIUS), or using a
   Fully Qualified Domain Name (as in Diameter).  If the Server-Id does
   not correspond to the IP address or FQDN of a known backend
   authentication server, then the authenticator will not know which
   backend authentication server possesses the key."