Subject: RE: [eap] Re: issue 367: Key Scope and EAP Server Authorization

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 8 May 2006 22:46:00 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, May 06, 2006 7:42 PM
> To: [email-masked]
> Subject: [eap] Re: issue 367: Key Scope and EAP Server Authorization
> 
> 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 single 
> administrative
> domain 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.
> 
[Joe] I'm not sure that a formal server-ID is required or sufficient.  The peer has a set of credentials that it uses to establish trust in a server.  It needs to know what the limits of that trust is.  If the peer wants to resume some state with an particular server then server-ID is very useful, but I think that is a slightly different problem. 

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

[Joe] Or one EAP server/Authenticator can attempt to spoof another. 

> 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.
> 
[Joe] I'm not familiar with this scenario, is this based on a context transfer from one AP to another?  So in this case you are putting your trust in one AP to only exchange data with another valid 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. 

[Joe] Implicit in this statement is that the peer pefromed some authorization of the authentication server. 

> 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.
> 
[Joe] Sounds true

> Given this, I'm not sure how the peer can verify that an 
> authenticator is
> allowed to be authorized by an EAP server.
> 
[Joe] This seems to me to be a rather serious system problem, since all we know is the EAP server and our trust in the authenticator is based on authorization from the EAP server.  If we can't verify this then I'm not sure why we are worried about channel bindings.  If you don't now the scope of the EAP server that is establishing trust then you don't know whether the parameters are valid or not.  

> The proposed resolution is as follows:
> 
> Change Section 2.2 to the following:
> 
> "2.2 Peer, Authenticator and Server Architecture
> 
> This specification does not impose constraints on the 
> architecture of the
> EAP authenticator, peer or server. 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, peers or servers;
> [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
> backend authentication 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"
> 
> Add a new section 2.2.1 entitled "Server Identification":
> 
> "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 server that 
> a peer communicates
> with may vary according to network and server availability.  
> 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.
> 
> As a result, prior to initiation of the EAP conversation, the 
> peer may not 
> be able to predict which
> EAP server it will be communicating with.  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. The peer may 
> not be able to 
> determine
> the Server-Id prior to the start of the EAP method 
> conversation, since the
> Server-Id is not included in the EAP-Request/Identity, and may not be
> advertised by the authenticator during the discovery phase."
> 
> --------------------------------------------------------------
> -------------------
> 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."
> 
> 
> _________________________________________________________________
> 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, 09 May 2006 08:41:01 -0700

>[Joe] I'm not sure that a formal server-ID is required or sufficient.  The 
>peer has a set of credentials that it uses to establish trust in a server.  
>It needs to know what the limits of that trust is.  If the peer wants to 
>resume some state with an particular server then server-ID is very useful, 
>but I think that is a slightly different problem.

[Bernard] The NAI allows the peer to request authentication within a given 
realm.  The assumption is that any EAP server in that realm will have access 
to the credentials necessary to authenticate the peer.  However, the peer 
cannot necessarily assume that the EAP servers share a cache of 
method-specific keying material.   This is where things get tricky.

>[Joe] Or one EAP server/Authenticator can attempt to spoof another.

If the EAP method doesn't support authentication of the server claim of 
identity, then even if the method supports mutual authentication, the peer 
is only verifying that the EAP server has access to the credentials, it is 
not authenticating the server itself.  For example, in EAP-TLS, TTLS, PEAP, 
etc. the server identity can be validated by the peer;  in EAP-SIM and 
EAP-AKA it cannot be.  One question this brings up is whether a method that 
doesn't support server certificates can validate the server identity.

>[Joe] I'm not familiar with this scenario, is this based on a context 
>transfer from one AP to another?  So in this case you are putting your 
>trust in one AP to only exchange data with another valid AP?

11r allows the authenticators derive cryptographically independent keys 
(PMK-R1s) from the MSK.  So it is not context transfer, which would mean 
that all authenticators use the same key to derive TSKs.  In 11r the trust 
model is between a new authenticator and the "initiall" authenticator. 
Compromise of the "initial" authenticator leads to compromise of all peer 
sessions that originated at that authenticator.  However, it does not 
necessarily compromise sessions which did not originate at the compromised 
authenticator, due to the crytographic separation built into the key 
hierarchy.

>[Joe] Implicit in this statement is that the peer pefromed some 
>authorization of the authentication server.

The peer can only do that if it authenticates the server, right?  For 
example, in EAP-TLS or PEAP the peer can perform authorization of the EAP 
server.

> > authenticator is allowed to be authorized by an EAP server.
> >
>[Joe] This seems to me to be a rather serious system problem, since all we 
>know is the EAP server and our trust in the authenticator is based on 
>authorization from the EAP server.  If we can't verify this then I'm not 
>sure why we are worried about channel bindings.  If you don't now the scope 
>of the EAP server that is establishing trust then you don't know whether 
>the parameters are valid or not.

I think that the peer has to trust that the backend authenticator server 
will not send a key to an unauthorized authenticator.  This implies that 
either the backend authentication server either checks that the Request 
attributes make sense (NAS-Identifier, Called-Station-Id, etc.) or that the 
local proxy does it if one is present.

You are correct that if the EAP server does not check the authorization of 
the authenticator, then Channel Bindings provide little value;  the 
authenticator can provide the same mis-information to the peer and backend 
server, and it will be believed.