Subject: Re: [eap] Re: Clarifications on "Domino Effect"

From: Jari Arkko <[email-masked]>
Date: Mon, 01 Aug 2005 18:40:49 +0300

Bernard Aboba wrote:

>>Well, yes, but I think the main reason for this requirement
>>is physical access. If you grab an access point from a coffee
>>shop wall, this should not lead to an uncontained compromise
>>of the whole system.
>>    
>>
>
>This problem statement is somewhat more concrete (and easier to analyze).
>
>For example, if you grab the access point off the wall, do you:
>
>a. Obtain a RADIUS shared secret used by another AP?  If good RADIUS
>secret hygene is being used, then  the answer is no.
>  
>
Right.

>b. Obtain keys useful in compromising another AP?  If the EAP method
>provides "session independence" I think that obtaining one MSK provides
>no useful information to compromise another MSK.  Also if the EMSK is
>cryptographically independent from the MSK, you can't compromise the EMSK
>if the MSK is compromised.
>  
>
Right.

>c. Obtain keys useful in compromisng an EAP peer or the backend server?
>
>Assuming that the EAP method is sufficiently robust (e.g. satisfies the
>RFC 4017 requirements) I think the answer is "no" to this one too.  For
>example, the attacker can't do an offline or online dictionary attack,
>can't do a brute force attack on the key (assuming the key strength is
>sert high enough), etc.
>  
>
Right.

>>an RFC with WG consensus behind it, it might be an idea
>>to define the issue in the keying framework itself. In this particular
>>case what we need to do is to go from a general statement "must
>>not compromise other nodes" to a set of more specific statements
>>that talk about what exact quantities in what exact other nodes
>>must not be compromised. While we are at it, we might also state
>>that we do not have a requirement on the compromise of the radius
>>server being recoverable...
>>    
>>
>
>Yes, it would be good to have a plan for getting this (and other
>requirements issues) settled.  The exact nature of the "domino effect"
>requirement is important to a number of lower layer attempting to utilize
>EAP.
>
>And the EAP WG is probably as good a place to discuss this as anywhere...
>  
>
I'm not necessarily saying that we need to have a long
list of requirements imported from Russ'es document.
Or a requirements section for that matter.

But it would be useful to have a discussion of the compromise
issue and other aspects of the system level security model in
the doc. Of course, we should not cover the extensions or
anything really beyond existing usage.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Aug 2005 09:05:18 -0700 (PDT)

> anything really beyond existing usage.

I agree that this makes sense.  Perhaps what we need to do is develop the
"threat model" section and then analyze existing lower layers against
those threats, providing concrete examples of how violation of
draft-housley principles can lead to issues (if in fact that is the case).
This might prove more helpful than just reciting a requirements list.
Usually the first question we get from a lower layer designer is "why does
this requirement matter to my lower layer?"
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Tue, 02 Aug 2005 03:40:45 -0700

> > And in other sense, I find the text a bit narrow. Why does it only
focus
> > on the "authenticator" if we are talking about domino affect? A
> > compromised RADIUS relay yields a domino effect as well.
> 
> Right -- and a much worse one because this compromises not only
> keys, but also the RADIUS shared secrets, allowing the attacker to
forge
> RADIUS packets at will to all the NASes associated with that RADIUS
proxy.

My current thinking is that, instead of singling out "authenticator" and
focusing on it, draft-housley-aaa-key-mgmt could be talking about key
hierarchy, and how compromise of a key (or its possessor) at one level
should not lead to compromise of another key (possessor) at the same
level or above.

Btw, earlier you had proposed:

	First, an authenticator MUST NOT share any keying material with 
	another authenticator.

How can we enforce that in the light of what you described as
"clustering" in the attached e-mail? The above strict language is
leaving no "legal" room for the practical approach you described in that
e-mail. Or, maybe we simply apply this rule to the cluster that appears
like a single authenticator? (And within the cluster we are breaking
this rule.) I hope we can clarify this as well.

Alper

Subject: Re: [eap] RE: Separation of EAP authenticator and AAA client
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Cc: Alper Yegin <[email-masked]>, [email-masked]
Date: Tue, 28 Jun 2005 21:47:44 -0700

> I think that's correct:   RFC 3748 invokes the 802.1x definition in
> which the Authenticator is the entity that "flips the switch"
> controlling port access.  So the CAPWAP (or Wimax NWG) scenario would
> be viewed as including a single authenticator - whose functionality
> happens to be divided between more than one physical box.

RFC 3748 does use this definition, but I'm not clear that in every
CAPWAP scenario that the entity that "flips the switch" is the same
entity
that would hold local credentials where no AAA is present.

Maybe we get around this by calling the combination of the lightweight
APs
and WLAN switch "the authenticator" without getting into its internal
structure.  This is easier in some ways -- if we don't care how an AP
circuit board is laid out (e.g. does it have two processors? If so,
which
one is the "authenticator?") why do we care about the decomposition of a
CAPWAP system?

For example, if I put a big black box around a CAPWAP system of
lightweight APs and WLAN switches, could you tell the difference between
that and separate APs that utilize clustering to appear as one
"authenticator"?  Assuming that both systems utilize a single NAS-ID
attribute with RADIUS, and advertise that ID on the link layer side and
keep the key cache consistent with that view, I don't see how a peer
could
tell the difference.  Note that both systems could utilize multiple
NAS-IP-Address and NAS-IPv6-Address attributes (even a single AP could
have multiple IP addresses;  one IPv4 & one IPv6 for a dual stack host,
or
more of both IPv4 and IPv6 addresses if the AP is a member of multiple
VLANs).

> Tangentially: if we did begin to decompose the authenticator  the
> 802.16e secure association protocol would most naturally seem to take
> place in the "EAP lower layer" since it is based on the port specific
> AK rather than the PMK.

I think it is definitely in the "lower layer" even if we don't decompose
it :)

> But if any entity can simply claim to belong to the same
> Authenticator (ie. "NAS-ID") I'm not sure how much has been gained.

The advertisement of the NAS-ID by the authenticator is largely a key
cache efficiency issue.  A bogus NAS-ID advertisement can induce a peer
to
utilize a key in a conversation that it otherwise would not expose to
potential attack.  However, that can happen without a NAS-ID
(e.g. in 802.11i, a peer can advertise a PMKID that is not in the
APs cache, and if the AP selected that PMKID, the peer would
attempt to complete a 4-way handshake with it (and fail).

If the NAS claims a bogus NAS-ID to the peer, then this can be
discovered via Channel Bindings.  If the NAS claims
a bogus NAS-ID to AAA, then the AAA proxy can figure that out.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap