Subject: [eap] Issue 200: Endpoint verification

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Nov 2003 13:17:56 -0800 (PST)

Issue 200: Endpoint verification
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: Nov 17, 2003
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:

The Security Claims section doesn't include a claim for
a solution to the "Lying NAS" problem, and this attack
is not included in the threat model either.

Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following
security claim:

Endpoint verification:  No

Add to Section 7.1:

[10] An attacker acting as an authenticator may provide
inconsistent information to the EAP peer
and server.  This includes impersonating another
authenticator,  or communicating incorrect information
via out-of-band mechanisms such as via
a AAA or lower layer protocol.

Add the following definition to section 7.2.1:

Endpoint verification
The verification within an EAP method of endpoint
identifiers communicated out of band, such as via
a AAA or lower layer protocol.

Add Section 7.15:

7.15  Endpoint Verification

It is possible for a compromised or poorly implemented EAP
authenticator to communicate inconsistent information to
the EAP peer and server.   This may enable an authenticator
to impersonate another authenticator or communicate
incorrect information via out-of-band mechanisms such as via a
AAA or lower layer protocol.

Where EAP is used in passthrough mode, the EAP peer typically
does not verify the identity of the authenticator, it
only verifies that the authenticator is trusted by the EAP
server.  This lack of endpoint verification creates a potential
security vulnerability.

While [RFC3579] Section 4.3.7 describes how an EAP authenticator
providing incorrect information to a AAA server
(such as a forged NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address
attributes) can be detected, it is possible for the AP to provide the
correct information to the AAA server while communicating
incorrect information to the EAP peer via a lower layer
protocol.

For example, it is possible for an authenticator to utilize another
authenticator's Calling-Station-Id in communicating with
the EAP peer, or for the authenticator to provide incorrect information on
the peer's Calling-Station-Id to the AAA server.

In order to address this vulnerability, EAP methods may support
a protected  exchange of endpoint identifiers, including
(but not limited to):
Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580],
NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and
NAS-IPv6-Address [RFC3162].

Using such an exchange,  the EAP server could match the
Called-Station-Id and Calling-Station-Id provided by the EAP
peer against that provided by the authenticator via the AAA protocol.
Similarly, if the peer is provided with the authenticator's
NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address via the lower layer
protocol, it could provide this information to the EAP server via the
EAP method, allowing the EAP server to match it against the equivalent
information provided by the authenticator via the AAA protocol.  Where
discrepancies exist, these SHOULD be logged.

Add to non-normative references:

[RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.

[RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
RFC 3162, August 2001.

[RFC3580]      Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580,
September 2003.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 21 Nov 2003 15:08:33 -0800

I'm a little worried about the usage of EAP server and AAA server
terminology.  I don't think that these two entities are the same thing.
An EAP-Server is typically embedded within the AAA server, but I don't
think that this has to be the case.  In particular the EAP-Server knows
how to execute EAP mechanisms, but it knows little or nothing about the
underlying application using EAP.  The underlying application is the
domain of the AAA server.

Also if discrepancies exist in the data provided to the AAA may it be
appropriate to take action beyond logging?

Suggested revision below:

> incorrect information via out-of-band mechanisms such as via 
> does not verify the identity of the authenticator, it only 
> verifies that the authenticator is trusted by the EAP server. 
>  This lack of endpoint verification creates a potential 
> security vulnerability.
> 
> While [RFC3579] Section 4.3.7 describes how an EAP 
> authenticator providing incorrect information to a AAA server 
> attributes) can be detected, it is possible for the AP to 
> provide the correct information to the AAA server while 
> communicating incorrect information to the EAP peer via a 
> lower layer protocol.
> 
> For example, it is possible for an authenticator to utilize 
> another authenticator's Calling-Station-Id in communicating 
> with the EAP peer, or for the authenticator to provide 
> incorrect information on the peer's Calling-Station-Id to the 
> AAA server.
> 
> In order to address this vulnerability, EAP methods may 
> support a protected  exchange of endpoint identifiers, 
> including (but not limited to): Called-Station-Id 
> [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], 
> peer against that provided by the authenticator via the AAA 
> protocol. Similarly, if the peer is provided with the 
> authenticator's NAS-Identifier, NAS-IP-Address or 
> NAS-IPv6-Address via the lower layer protocol, it could 
> provide this information to the EAP server via the EAP 
> method, allowing the EAP server to match it against the 
> equivalent information provided by the authenticator via the 
> AAA protocol.  Where discrepancies exist, these SHOULD be logged.
> 
[Joe] replace 

"allowing the EAP server to match it against the 
equivalent information provided by the authenticator via the 
AAA protocol."

With 

"allowing the EAP server to provide this information to the AAA 
server to match it against the equivalent information provided 
by the authenticator via the AAA protocol."

---

From: John Vollbrecht <[email-masked]>
Date: Sat, 22 Nov 2003 12:48:25 -0500

> > communicating incorrect information to the EAP peer via a

This is certainly true.  I am not sure what the consequences are.  Nothing 
in the spec says what except the EAP packet and perhaps the Identity gets 
passed to the EAP method.

> > incorrect information on the peer's Calling-Station-Id to the
In this case the AP is lying accross the interface to either EAP directly 
or to AAA and to EAP indirectly.  In the latter case it has a fraudulent 
RADIUS packet sent from a trusted AP to the RADIUS server.

> > NAS-IPv6-Address [RFC3162].
This may be needed to create a binding with this info to a key in methods 
that create keys.  If this information is not included in EAP exchange but 
passed by the AP to the EAP method (directly or indirectly via AAA 
protocol) and then included in the key binding, then perhaps this attribute 
passing capability should be included in the spec.

Including it in methods seems reasonable suggestion.

> by the authenticator via the AAA protocol."
I think this is a good statement, except that it doesn't seem to matter 
whether the information is provided directly by the AP or indirectly by the 
AAA protocol.  So - the AP could lie to EAP, or the RADIUS Server could lie 
to EAP.  I think both cases should be included.

Also, I am not sure that the EAP Server per se would do the checking, but 
the EAP method could.   Perhaps the EAP Server and method are the same in 
this instance? The terminology is a bit unclear to me.   Since the Client 
and AP can use the key to verify that the Client and EAP Server/method 
created the key, one check is made when the AP and Client initiate 
communication with the key.  The check could be made somewhere else as 
well, but I am not clear exacly where it is useful - perhaps someone could 
explain.

-- John