Subject: [eap] Re: Issue 366 Section 2.2.2

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 May 2006 07:12:30 -0700

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: [email-masked]
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.

_________________________________________________________________
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: Mon, 08 May 2006 07:40:44 -0700

>NAS-Identifier attribute or BSSID.

This probably should be "in order to enable the peer and backend server to 
tell
them apart", since the backend server will also have this issue.