Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope and ServerAuthorization

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 5 Jun 2006 21:43:33 -0700

Hi Bernard,

I think the text below is good, but I don't think it addresses the issue
I had in mind.  

Consider the case where each authenticator contains its own EAP Server.
If the peer wants to ensure that it is connecting to the "correct"
authenticator it obviously cannot just rely upon channel bindings since
the authenticator is in control of the EAP server, it must be able to
authorize the EAP server as being able to authorize the authenticator.
If we consider a remote EAP Server then this EAP server will be
authorized to atuhorize as subset of authenticators.  In order for a
peer to verify that the authenticator in collusion with the EAP server
is not lying about some parameter it must be able to authorize the EAP
Server as being able to authorize the authenticator. 

In some ways this is a basic thing, but I don't think this is currently
covered elswhere in the document.  It may not belong in this section,
but I think it belongs somewhere with the scoping discussion. 

Joe

Bernard Aboba wrote:
> The text of Issue 367 is enclosed below.  The proposed
> resolution is to
> change Section 2.2 to the text enclosed below, as well as to
> add a new
> Section 2.2.1, as follows:
> 
> 2.2.  Peer and Authenticator Architecture
> 
>    This specification does not impose constraints on the
> architecture of
>    the EAP authenticator or peer. Any of the authenticator
>    architectures described in [RFC4118] can be used. As a result,
> lower 
> layers need to
>    identify EAP peers and authenticators unambiguously, without
>    incorporating implicit assumptions about peer and authenticator   
> architectures. 
> 
>    For example, it is possible for multiple base stations and a
>    "controller" (e.g. WLAN switch) to comprise a single EAP
>    authenticator.  In such a situation, the "base station identity" is
>    irrelevant to the EAP method conversation, except perhaps as an
>    opaque blob to be used in Channel Bindings. Many base stations can
>    share the same authenticator identity.  It should be
> understood that
>    an EAP authenticator or peer:
> 
>    [a] may contain one or more physical or logical ports;
>    [b] may advertise itself as one or more "virtual"
>        authenticators or peers;
>    [c] may utilize multiple CPUs;
>    [d] may support clustering services for load balancing or failover.
> 
>    Both the EAP peer and authenticator may have more than one physical
>    or logical port.  A peer may simultaneously access the network via
>    multiple authenticators, or via multiple physical or
> logical ports on
>    a given authenticator.  Similarly, an authenticator may
> offer network
>    access to multiple peers, each via a separate physical or logical
>    port.  When a single physical authenticator advertises itself as
>    multiple "virtual authenticators",  it is possible for a single
>    physical port to belong to multiple "virtual authenticators".
> 
>    An authenticator may be configured to communicate with
> more than one
>    EAP server, each of which is configured to communicate
> with a subset
>    of the authenticators.  The situation is illustrated in Figure 3.
> 
>                                +-+-+-+-+
>                                | 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
> 
> 2.2.1.  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 within a realm, 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 Master Key identified by the TLS Session-Id, and
>    therefore the session resumption attempt will fail, requiring
>    completion of a full EAP-TLS exchange.
> 
> 
> ==========================================================
> Issue 367: Key Scope and EAP Server Authorization
> Submitter name: Joe Salowey
> Submitter email address: [email-masked]
> Date Submitted: May 3, 2006
> Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
> Document: KEYING-12 Comment type: 'T'echnical
> Priority: '1' Should fix
> Section: 2.2.1 and 3.2
> Rationale/Explanation of issue:
> 
> Section 1.4.1 correctly defines the scope of the EAP keying
> material as
> being defined by the EAP Peer and EAP server, however this
> relationship is not carried out in other key scope discussions as far
> as I 
> can tell.
> In order for channel binding, key mixing etc. to work the
> peer must make
> sure that the key is used not just within the authorized parameters of
> the lower layer, but of the authorized scope of the EAP
> server as well.
> 
> I'm not sure of all of all the places where this needs to be
> addressed, but I think it needs to be addressed in section 2.2.1
> perhaps 
> by adding
> 
> "[g] Verifying that the advertised scope is within the scope that the
> EAP server is allowed to authorize"
> 
> Section 3.2 should probably state somewhere that:
> 
> "The peer should verify that the key scope advertised by the
> authenticator is within the scope that is allowed to be authorized by
> the EAP Server." 
> 
> [Bernard Aboba]
> 
> I think I see the point, which is that a given authenticator may be
> connected to more than one EAP server, and that all authenticators in
> a realm 
> may not share the same EAP server. Also, EAP servers cannot
> necessarily be assumed to share key state among each other. If the
> selcted EAP method
> does not
> provide the Server-Id, then the peer cannot know the scope of
> the keys it
> derives with the EAP server.
> 
> This can create a number of issues, such as a peer attempting (but
> failing) a
> fast reconnect because the server that the authenticator is
> configured to communicate with is not the same one with which the peer
> established the
> previous session.
> 
> However, there are other situations in which the server
> identity is not
> material,
> such as handoff in an 11r Mobility Domain (MD), where the STA
> only care
> whether
> a candidate AP is in the same MD, not whether the new
> authenticator is
> configured
> to talk to the same backend authentication server as the
> current or initial
> AP.
> 
> In practice, the peer determines whether an authenticator is
> within the
> scope
> of authorization of the backend authentication server by
> attempting to
> complete
> the SAP exchange with it. If the exchange succeeds, the
> authenticator is
> authorized; if not, it isn't. It is possible for the peer to attempt a
> fast reconnect exchange with the wrong server; unless the
> server were to
> include its identity in the EAP-Request there is no way for
> the peer to
> determine what server it is talking to before the EAP method
> conversation gets underway. Even if the authenticator were to
> advertise 
> the server(s)
> that it is configured to talk to, and even if those servers
> were identified
> by their Server-Ids, it would not be possible for the peer to
> know a-priori
> which server it was going to talk to, since the primary
> server can change
> due
> to changes in network or server availability.
> 
> Given this, I'm not sure how the peer can verify that an
> authenticator is allowed to be authorized by an EAP server.
> 
> 
> _________________________________________________________________
> 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: Tue, 06 Jun 2006 10:42:13 -0700

>authorized to authorize a subset of authenticators.  In order for a
>covered elsewhere in the document.  It may not belong in this section,

When the EAP method exports the Server-Id, and the claim of server identity 
is authenticated (such as via certificates) the peer can decide whether the 
EAP server is authorized or not.   As you note, channel bindings only apply 
when the EAP server can be trusted.  By the principle of mode independence, 
the peer doesn't know whether the authenticator and EAP server are 
co-located or not, so that Server-Id seems like the only thing that the peer 
has to verify server authorization.  The authenticator and server could 
collude in the pass-through or standalone case, and there is really no way 
for the peer to detect this.

Do you have some text to suggest?

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Jun 2006 14:16:23 -0700

How about the following:

Add the following paragraphs to the end of Section 2.3 Server 
Identification:

"EAP methods that support mutual authentication enable the EAP peer to only 
connect to authenticators authenticated by a trusted EAP server.  However, 
mutual authentication may not result in verification of 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 know 
which one.

EAP methods that export the Server-Id MUST verify the server identity. This 
enables the EAP peer to decide whether a specific EAP server is authorized 
or not, and 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 keying 
material has been shared outside its authorized scope."

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: Re: [eap] Proposed Resolution to Issue 367: Key Scope 
>andServerAuthorization
>Date: Tue, 06 Jun 2006 10:42:13 -0700
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Jun 2006 21:41:38 +0300

>material has been shared outside its authorized scope."
I am basically fine with this text, but it may be exaggarate the value of
an identifier a little bit. If you assume that the correct server set has
given long-term secret material to some other servers, its not clear that
having the server provide an identifier helps in all cases. For instance,
the server may lie about its identifier.

Suggested edit: s/This enables the EAP peer to decide/This may help
the EAP peer to decide/

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 24 Jun 2006 13:36:30 -0700

>Suggested edit: s/This enables the EAP peer to decide/This may help

OK.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 24 Jun 2006 13:53:22 -0700

>Suggested edit: s/This enables the EAP peer to decide/This may help

Here is a revised version of the text proposed for Section 2.3:

"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 may help 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."