Subject: [eap] Proposed Resolution to Issue 200: Endpoint Verification

From: Bernard Aboba <[email-masked]>
Date: Sun, 23 Nov 2003 08:43:32 -0800 (PST)

The text of Issue 200 is enclosed below.  The proposed resolution is as
follows:

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 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 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 Section 7.15:

7.15 Endpoint Verification

It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP
peer and/or 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 pass-through mode, the EAP peer typically
does not verify the identity of the pass-through authenticator, it
only verifies that the pass-through authenticator is trusted by the EAP
server.  This lack of endpoint verification creates a potential
security vulnerability.

[RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator
acting as a AAA client can be detected if it attempts to impersonate
another authenticator (such by sending incorrect NAS-Identifier [RFC2865],
NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes
via the AAA protocol). However, it is possible for a pass-through
authenticator acting as a AAA client to provide correct information to
the AAA server while communicating misleading information to the EAP peer
via a lower layer protocol.

For example, it is possible for a compromised authenticator to utilize
another authenticator's Called-Station-Id in communicating with the EAP
peer via a lower layer protocol, or for a pass-through authenticator
acting as a AAA client to provide an incorrect peer Calling-Station-Id
[RFC2865] [RFC3580] to the AAA server via the AAA protocol.

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 peer and server can match parameters
provided by the authenticator (such as endpoint identifiers) via
out-of-band mechanisms against those exchanged within the EAP method.
Where discrepancies exist, these SHOULD be logged; additional actions MAY
also be taken, such as denying access.

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.

------------------------------------------------------------------------
Issue 200: Endpoint verification
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: Nov 17, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-November/001845.html
Document: RFC2284bis-06
Comment type: T
Priority: S
Section: 5, 7
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.

[Joe Salowey] 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?
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."

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 24 Nov 2003 11:28:21 -0800

I still find this section to be problematic, comments inlien below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Sunday, November 23, 2003 8:44 AM
> To: [email-masked]
> Subject: [eap] Proposed Resolution to Issue 200: Endpoint Verification
> 
> 
> Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the 
> following security claim:
> 

[Joe]Having this verification within an EAP-Method is problemaitc.  It
requires the EAP-Method to have a lot of specific details about the
environment in which it is used.  EAP-methods should be independent of
the environemnt.  

I would rather see 

"Channel Binding

The communiction of integrity protected data of underlying channel
proterties such as endpoint identifiers that can be compared outside the
EAP method to values communicated via out of band mechanisms (such as
via a AAA or lower layer protocol)."

> 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 Section 7.15:
> 

[Joe] Replace with "Channel Binding"

> peer and/or 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 pass-through mode, the EAP peer 
> typically does not verify the identity of the pass-through 
> authenticator, it only verifies that the pass-through 
> authenticator is trusted by the EAP server.  This lack of 
> endpoint verification creates a potential security vulnerability.
> 
> [RFC3579] Section 4.3.7 describes how an EAP pass-through 
> authenticator acting as a AAA client can be detected if it 
> attempts to impersonate another authenticator (such by 
> sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address 
> [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the 
> AAA protocol). However, it is possible for a pass-through 
> authenticator acting as a AAA client to provide correct 
> information to the AAA server while communicating misleading 
> information to the EAP peer via a lower layer protocol.
> 
> For example, it is possible for a compromised authenticator 
> to utilize another authenticator's Called-Station-Id in 
> communicating with the EAP peer via a lower layer protocol, 
> or for a pass-through authenticator acting as a AAA client to 
> provide an incorrect peer Calling-Station-Id [RFC2865] 
> [RFC3580] to the AAA server via the AAA protocol.
> 
> 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 peer and server can match 
> parameters provided by the authenticator (such as endpoint 
> identifiers) via out-of-band mechanisms against those 
> exchanged within the EAP method. Where discrepancies exist, 
> these SHOULD be logged; additional actions MAY also be taken, 
> such as denying access.
> 
> "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.
> 
> Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
> 
Document: RFC2284bis-06
Comment type: T
Priority: S
Section: 5, 7

"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: Mon, 24 Nov 2003 16:06:59 -0500

nice - I like it.  John

---

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

OK.  How does this look?

Channel Binding: No

Channel binding
The communication within an EAP method of integrity-protected channel properties
such as endpoint identifiers which can be compared to values communicated via out
of band mechanisms (such as via a AAA or lower layer protocol).

Add to Section 7.1:

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

Add Section 7.15:

7.15 Channel binding

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

For example, it is possible for a compromised authenticator to utilize
another authenticator's Called-Station-Id or NAS-Identifier in
communicating with the EAP peer via a lower layer protocol, or for a
pass-through authenticator acting as a AAA client to provide an incorrect
peer Calling-Station-Id [RFC2865] [RFC3580] to the AAA server via the AAA protocol.

In order to address this vulnerability, EAP methods may support
a protected exchange of channel properties such as 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 a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method.  Where discrepancies are found,
these SHOULD be logged; additional actions MAY also be taken, such as
denying access.

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 25 Nov 2003 10:06:27 -0800

This is better.  

Thanks,

Joe  

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, November 24, 2003 11:57 PM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: RE: [eap] Proposed Resolution to Issue 200: Endpoint 
> Verification
> 
> 
> OK.  How does this look?
> 
> The communication within an EAP method of integrity-protected 
> channel properties such as endpoint identifiers which can be 
> compared to values communicated via out of band mechanisms 
> (such as via a AAA or lower layer protocol).
> 
> Add to Section 7.1:
> 
> incorrect information to the EAP peer and/or server via 
> out-of-band mechanisms (such as via a AAA or lower layer 
> protocol).  This includes impersonating another 
> authenticator, or providing inconsistent information to the 
> peer and EAP server.
> 
> Add Section 7.15:
> 
> 7.15 Channel binding
> 
> authenticator is trusted by the EAP server.  This creates a 
> potential security vulnerability.
> 
> to utilize another authenticator's Called-Station-Id or 
> NAS-Identifier in communicating with the EAP peer via a lower 
> layer protocol, or for a pass-through authenticator acting as 
> a AAA client to provide an incorrect peer Calling-Station-Id 
> support a protected exchange of channel properties such as 
> 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 a protected exchange, it is possible to match the 
> channel properties provided by the authenticator via 
> out-of-band mechanisms against those exchanged within the EAP 
> method.  Where discrepancies are found, these SHOULD be 
> logged; additional actions MAY also be taken, such as denying access.
>