eap Mailing List: RE: Re: Clarifications on "Domino Effect"

[Alper Yegin (alper.yegin]

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

--- Begin Message ---

Title: Re: [eap] RE: Separation of EAP authenticator and AAA client

> 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
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap

--- End Message ---