eap Mailing List: Re: Issue 366 Section 2.2.2

[Bernard Aboba (bernard_aboba]

Sharing a logical cache between virtual authenticators creates the potential 
for elevation of privilege or unauthorized access.  By authenticating to one 
virtual authenticator, the peer can gain
access to any virtual authenticator that it shares a key cache with.  I 
don't think that Section 2.2.2 says this very clearly, though.

With respect to offering different services on different authenticators,this 
is discussed in Section 4, but I am not sure it is a "virtual authenticator" 
issue.

I think that there are two issues that have been intermingled in [i].  One 
is the need for virtual authenticators to advertise their identities 
consistently between AAA and the lower layer, or else channel bindings could 
fail.

Another issue is the need for virtual authenticators to identify them 
distinctly, so that peers can tell them apart.  For example, in 802.11r it 
would not be a good idea for all the virtual authenticators to use the same 
R0KH-ID, since then the peers might not be able to tell them apart.   
However, if they used different R0KH-IDs, but the same NAS-Identifier 
attribute, now channel bindings will fail.

Suggested resolution is as follows:

Change

"   When a single physical authenticator advertises itself as multiple
  "virtual authenticators", a number of security vulnerabilities may
  arise.  For example, the peer may assume that the "virtual
  authenticators" are distinct and do not share a key cache, whereas,
  depending on the architecture of the physical authenticator, a shared
  key cache may or may not be implemented.

  Where EAP keying material is shared between "virtual authenticators"
  an attacker acting as a peer could authenticate with the "Guest"
  "virtual authenticator" and derive EAP keying material.  If the
  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" virtual authenticator.

  In order to address these issues:"

To:

"  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:"

replace:

"[i]  It is RECOMMENDED that each "virtual authenticator" identify itself
    distinctly to the backend authentication server, such as by
    utilizing a distinct NAS-Identifier attribute.  This enables the
    backend authentication server to utilize a separate credential to
    authenticate each "virtual authenticator", and for the peer and
    backend authentication server to verify the authenticator identity
    via Channel Bindings (see Section 5.11)."

with

""[i]  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).

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


-------------------------------------------------------------------
Issue 366: Section 2.2.2
Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04274.html
Document: KEYING-12
Comment type: 'E'ditorial
Priority: '2' May fix
Section: 2.2.2
Rationale/Explanation of issue:

What is the specific vulnerability in this situation?

" For example, the peer may assume that the "virtual
  authenticators" are distinct and do not share a key cache, whereas,
  depending on the architecture of the physical authenticator, a shared
  key cache may or may not be implemented."

Maybe it should describe the peer problems that arise when you have
different authenticators that provide different levels of services,
similar to the authenticator problems in the next paragraph?

I'm not sure how recommendation [i] is related to the example of the
corporate/guest problem in the second paragraph.