Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 6 Jan 2004 13:49:47 -0800

<snip>
> In Section 2.4, change:
> 
> "   [3] Peer policy satisfaction.  EAP methods may support protected
>        result indications, enabling the peer to indicate to the EAP
>        server that it successfully authenticated the EAP server.
>        However, a pass-through authenticator will not be 
> aware that the
>        peer has accepted the credentials offered by the EAP server,
>        unless this information is provided to the 
> authenticator via the
>        AAA protocol.  As a result, two authentications, one in each
>        direction, may still be needed.
> 
>        It is also possible that the EAP peer's access policy was not
>        satisfied during the EAP method exchange.  For example, the
>        authenticator may not have successfully authenticated to the
>        peer, or may not have demonstrated authorization to act in both
>        peer and server roles.  For example, in EAP-TLS [RFC2716], the
>        authenticator may have authenticated using a valid TLS server
>        certificate, but not using a valid TLS client 
> certificate.  As a
>        result, the peer may require an additional 
> authentication in the
>        reverse direction, even if the peer provided a protected result
>        indication to the EAP server indicating that the server had
>        successfully authenticated to it."
> 
> To:
> 
> "[3] Peer policy satisfaction.  EAP methods may support 
> protected result indications, enabling the peer to indicate 
> to the EAP server within the method that it successfully 
> authenticated the EAP server, as well as for the server to 
> indicate that it has authenticated the peer. However, a 
> pass-through authenticator will not be aware that the peer 
> has accepted the credentials offered by the EAP server unless 
> this information is provided to the authenticator via the AAA 
> protocol.  The authenticator SHOULD interpret the receipt of 
> a key attribute within an Accept packet as an indication that 
> the peer has successfully authenticated the server.
> 
[Joe] Is this authenticated or authenticated and authorized?

> However, it is possible that the EAP peer's access policy was 
> not satisfied during the initial EAP exchange, even though 
> mutual authentication occurred.  For example, the EAP 
> authenticator may not have demonstrated authorization to act 
> in both peer and authenticator roles.  As a result, the peer 
> may require an additional authentication in the reverse 
> direction, even if the peer provided an indication that the 
> EAP server had successfully authenticated to it."

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jan 2004 14:08:19 -0800 (PST)

> > The authenticator SHOULD interpret the receipt of

I think it is "authenticated and authorized".  Are there counter-examples?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jan 2004 13:31:45 -0800 (PST)

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

In Section 4.2, 7th paragraph, delete:

" A mutually authenticating method (such as EAP-TLS [RFC2716]) that
provides authorization error messages provides protected result
indications for the purpose of this specification. Within
EAP-TLS, the peer always authenticates the authenticator, and may
send a TLS-alert message in the event of an authentication
failure. An authenticator may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the authenticator decided not to proceed. If
a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts."

In Section 7.2.1, change:

"   Protected result indications
             The ability within a method for the authenticator to
             indicate to the peer whether it has successfully
             authenticated to it, and for the peer to acknowledge
             receipt of that indication as well as indicating to the
             authenticator whether it has successfully authenticated to
             the peer.  Since EAP Success and Failure packets are
             neither acknowledged nor integrity protected, this claim
             requires implementation of a method-specific result
             exchange that is authenticated, integrity and replay
             protected on a per-packet basis."

To:

"Protected result indications
The ability within a method for the authenticator to
indicate to the peer whether it has successfully
authenticated to it, and for the peer to acknowledge
receipt of that indication as well as indicating to the
authenticator whether it has successfully authenticated to
the peer.   This claim requires implication of a method-specific
result exchange that is authenticated, integrity and replay
protected on a per-packet basis.  Since this requires a
key, methods making this claim need only protect result
indications sent after a key has been derived. See Section 7.16 for
details."

In Section 2.4, change:

"   For example, EAP-TLS [RFC2716] is a client-server protocol with a
   different certificate profile for the client and server.  This
   implies that a host supporting peer-to-peer authentication with
   EAP-TLS would need to implement both the EAP peer and authenticator
   layers; support both peer and authenticator roles in the EAP-TLS
   implementation; and provision two distinct certificates, one
   appropriate for each role."

To:

"For example, EAP-TLS [RFC2716] is a client-server protocol in which
distinct certificate profiles are typically utilized for the client and
server.  This implies that a host supporting peer-to-peer authentication with
EAP-TLS would need to implement both the EAP peer and authenticator
layers; support both peer and authenticator roles in the EAP-TLS
implementation; and provision certificates appropriate for each role."

In Section 2.4, change:

"   [3] Peer policy satisfaction.  EAP methods may support protected
       result indications, enabling the peer to indicate to the EAP
       server that it successfully authenticated the EAP server.
       However, a pass-through authenticator will not be aware that the
       peer has accepted the credentials offered by the EAP server,
       unless this information is provided to the authenticator via the
       AAA protocol.  As a result, two authentications, one in each
       direction, may still be needed.

       certificate, but not using a valid TLS client certificate.  As a
       result, the peer may require an additional authentication in the

To:

"[3] Peer policy satisfaction.  EAP methods may support protected
result indications, enabling the peer to indicate to the EAP server within
the method that it successfully authenticated the EAP server, as well as
for the server to indicate that it has authenticated the peer.
However, a pass-through authenticator will not be aware that the
peer has accepted the credentials offered by the EAP server
unless this information is provided to the authenticator via the
AAA protocol.  The authenticator SHOULD interpret
the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated
the server.

However, it is possible that the EAP peer's access policy was not
satisfied during the initial EAP exchange, even though mutual authentication
occurred.  For example, the EAP authenticator may not have demonstrated
authorization to act in both peer and authenticator roles.  As a result,
the peer may require an additional authentication in the reverse
direction, even if the peer provided an indication that the EAP server had
successfully authenticated to it."

Add Section 7.16:

"7.16 Protected Result Indications

EAP Success and Failure packets are
neither acknowledged nor integrity protected.
This creates a potential vulnerability to
spoofing, as well as lengthy timeouts.

To address this vulnerability, EAP methods
may implement protected result indications.
Since protected result indications require
use of a key for per-packet authentication and
integrity protection, methods supporting
protected result indications MUST also
support key derivation and mutual authentication.

Result indications may be implicit
or explicit. For example, a method may use
error messages in order to explicitly indicate
a failure, while the completion of
mutual authentication and key derivation without
an error message implicitly indicates a successful
result.

For example, within EAP-TLS [RFC2716], the peer
always authenticates the server, and sends a TLS alert message
in the event of an authentication or authorization failure.
If the server does not receive a TLS alert message from the
peer and the peer continues the conversation
to completion (e.g. sends a FINISHED message),
then the server can assume that the peer
will accept access if granted it by the server.

Similarly, the peer can assume that the server will grant
access if it does not receive a TLS alert message from the
server, and the server carries the conversation to completion
(e.g. sends a FINISHED message).

A server may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the server decided not to proceed."

--------------------------------------------------------------------------
Issue 212: Protected Result Indications
Submitter name: Russ Housley
Submitter email address: [email-masked]
Date first submitted: 12/15/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-December/002003.html
Document: RFC 2284bis-07
Comment type: T
Priority: S
Section: 4.2
Rationale/Explanation of issue:

In section 4.2, 7th paragraph at the top of page 25, 1st
sentence, I cannot figure out what the sentence means:

"A mutually authenticating method (such as EAP-TLS
[RFC2716]) that provides authorization error messages provides
protected result indications for the purpose of this specification."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 20 Jan 2004 10:13:46 -0800

Bernard Aboba wrote:
>>> a key attribute within an Accept packet as an indication that the
>>> peer has successfully authenticated the server.
>>> 

I think the problem is that EAP method/framework may not have sufficient
information to determine authorization as there may be more
considerations than authentication.   This escpecially true of the
EAP-Server and I believe it is also true of the Peer.  I think the EAP
framework can be expected to determine that authentication related
policy has been satisfied,  but this does not gaurantee that peer or the
server will allow access.  

Joe

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 20 Jan 2004 13:44:18 -0500

> server will allow access.
I agree with Joe.  The EAP method does authentication and possibly 
authorization between the Server and the Peer.  Other authorization, such 
as "is Joe allowed on after 5PM" may have nothing to do with the EAP method 
but may keep Joe from being allowed to connect even though the EAP method 
succeeded.

John

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Jan 2004 16:39:59 -0800 (PST)

> but may keep Joe from being allowed to connect even though the EAP method

OK.  So the resolution is to leave the original text the way it is?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 20 Jan 2004 16:50:39 -0800

Bernard Aboba wrote:
>>> I think the problem is that EAP method/framework may not have
>>> sufficient information to determine authorization as there may be
>>> more considerations than authentication.   This escpecially true of
>>> the EAP-Server and I believe it is also true of the Peer.  I think
>>> the EAP framework can be expected to determine that authentication
>>> related policy has been satisfied,  but this does not gaurantee that
>>> peer or the server will allow access.
>>> 
>> authorization between the Server and the Peer.  Other authorization,
>> such as "is Joe allowed on after 5PM" may have nothing to do with the
>> EAP method but may keep Joe from being allowed to connect even though
>> the EAP method succeeded.
> 

[Joe] Yes, with "authenticated" instead of "authenticated and
authorized".

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Jan 2004 17:54:08 -0800 (PST)

> [Joe] Yes, with "authenticated" instead of "authenticated and

Done.