Subject: [eap] Issue: AAA server assumptions

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 19 Nov 2006 22:44:25 -0800

Issue: AAA server assumptions
Submitter name: Russ Housley
Submitter email address: [email-masked]
Date Submitted: November 17, 2006
Reference:
Document: KEYING-15
Comment type: Technical
Priority: S
Section: 1.5
Rationale/Explanation of issue:
The security goals section does not capture an important assumption about 
the AAA server that is required for the major security goal (fresh session 
keys known only to the peer and authenticator) to be achieved.

The AAA server is a trusted entity.  When keying material is present at all, 
it establishes keying material with the peer and distributes keying material 
to the authenticator using the AAA protocol.  It is trusted to only 
distribute keying material to the authenticator that was established with 
the peer, and it is
trusted to provide that keying material to no other parties.   In many 
systems, keying material established by the EAP peer and EAP server are 
combined with publicly available data to derive other keys.  The AAA server 
is trusted to refrain from deriving these same keys even though it has 
access to the secret values that are needed to do so. The authenticator is 
also a trusted party.  It is trusted not to provide keying material it 
obtains from the AAA server to any other parties.

Proposed resolution:

Add the following text to Section 1.5, after the first paragraph:

"The backend authentication server is a trusted entity.  Where the 
authenticator operates in pass-through mode and an EAP method supporting key 
generation is used, the EAP server establishes keying material with the peer 
and the backend authentication server distributes keying material to the 
authenticator using the AAA protocol.  The backend authentication server is 
trusted to only distribute keying material to the authenticator that was 
established with the peer, and it is trusted to provide that keying material 
to no other parties.  In many systems, keying material established by the 
EAP peer and EAP server are combined with publicly available data to derive 
other keys.  The backend authentication server is trusted to refrain from 
deriving these same keys or acting as a man-in-the-middle even though it has 
access to the secret values that are needed to do so.  The authenticator is 
also a trusted party.  It is trusted not to provide keying material it 
obtains from the backend authentication server to any other parties."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: Charles Clancy <[email-masked]>
Date: Mon, 20 Nov 2006 21:09:56 -0500

The following worries me:

"The backend authentication server is trusted to only distribute keying 
material to the authenticator that was established with the peer, and it 
is trusted to provide that keying material to no other parties."

Sounds at odds with HOKEY.

"The authenticator is also a trusted party.  It is trusted not to 
provide keying material it obtains from the backend authentication 
server to any other parties."

Sounds at odds with 11r.

... unless "keying material" refers specifically to top-level keys, and 
not keys derived from those keys.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Nov 2006 08:08:50 -0800

>... unless "keying material" refers specifically to top-level keys, and not 
>keys derived from those keys.

Yes, that is the intent.  Will change this to "EAP keying material".

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Nov 2006 09:07:04 -0800

How about this? (insert after the third paragraph in Section 1.5):

"The backend authentication server is trusted to only transport
EAP keying material to the authenticator that was established with
the peer, and it is trusted to transport that EAP keying material
to no other parties.  In many systems, EAP keying material
established by the EAP peer and EAP server are combined with publicly 
available
data to derive other keys.  The backend authentication server is trusted to
refrain from deriving these same keys or acting as a man-in-the-middle even
though it has access to the EAP keying material that is needed to do so.
The authenticator is also a trusted party.  It is trusted not to provide
EAP keying material it obtains from the backend authentication server to
any other parties."