Subject: Re: [eap] Revised Proposed Resolution to Issue 207: Miscellaneous Comments

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jan 2004 16:17:33 -0800

On Tue, Jan 06, 2004 at 01:57:14PM -0800, Joseph Salowey wrote:
> [Joe] What I am referring to is not access policy.  The situation is
> that the peer is in a state where it may accept either a EAP-Succes or
> an TLS-faliure.  SO in this case there does not appear to be a
> protected-result-indicator for server success.  There may be one for
> server failure, but it is probably that the keys won't match and you
> wouldn't be able to verify a failure message.  In addition since the
> protocol is considered complete it is possible that a failure message
> could be removed/added/modified without the peer knowing. 
> 

Understood.  It looks like that EAP-TLS session resumption might need
one more protected exchange between TLS finished from TLS client and
EAP-Success from TLS server so that the TLS client can securely know
whether it has successfully authenticated to the TLS server before
receiving the EAP-Success message which is unprotected.

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 5 Jan 2004 09:59:44 -0800

<snip>
> In Section 4.2, 7th paragraph, change:
> 
> " 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."
> 
> To:
> 
> "A mutually authenticating method may use error messages
> to provide protected result indications. This ensures that 
> the peer and server are aware of each other's final access 
> decision, and prevents lengthy timeouts.
> 
> 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).
>

[Joe] does this also hold true in the case of TLS session resume?  In
session resume the server sends the finished message before the client
which is opposite of the full handshake.  In the session resume case the
peer is in a state where it may accept a TLS-Alert or an EAP-Success.  

<snip> 
> 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."
> In Section 7.10, change the first paragraph from:
> 
> "It is possible for the peer and EAP server to mutually 
> authenticate and derive keys.  In order to provide keying 
> material for use in a subsequently negotiated ciphersuite, an 
> EAP method supporting key derivation MUST export a Master 
> Session Key (MSK) of at least 64 octets, and an Extended 
> Master Session Key (EMSK) of at least 64 octets.  EAP Methods 
> deriving keys MUST provide for mutual authentication between 
> the EAP peer and the EAP Server."
> 
> To:
> 
> "It is possible for the peer and EAP server to mutually 
> authenticate and derive keys.  In order to provide keying 
> material for use in a subsequently negotiated ciphersuite, an 
> EAP method supporting key derivation MUST export a Master 
> Session Key (MSK) of at least 64 octets, and an Extended 
> Master Session Key (EMSK) of at least 64 octets.
> 
> EAP Methods supporting key derivation MUST also support 
> mutual authentication between the EAP peer and the EAP 
> Server. EAP Methods supporting mutual authentication MUST 
> also support key derivation and protected result indications."
> 

[Joe] It seems that this disallows authenticated servers and anonymous
clients.  I'm not sure that this is a good idea.  The MUST for protected
result indications seems to be a big change.  Given the above it appears
that EAP-TLS does not meet protected result indications in all cases.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jan 2004 12:52:19 -0800

> peer is in a state where it may accept a TLS-Alert or an EAP-Success.  

I think that whenever TLS session resumption is performed there is an
implication that both the client and server agree on the same access
policy that was agreed during the initial authentication with a TLS
full handshake.  Based on this, it seems to me that there is no reason
for both entities to send a TLS-Alert message during TLS session
resumption procedure to indicate a problem in access policy.  If there
is a possibility of denying/changing the previous access policy, TLS
sesion resumption procedure should not be performed and TLS full
handshake should be performed instead.

Yoshihiro Ohba

---

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

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Tuesday, January 06, 2004 12:52 PM
> To: Joseph Salowey
> Cc: 'Bernard Aboba'; [email-masked]
> Subject: Re: [eap] Revised Proposed Resolution to Issue 207: 
> Miscellaneous Comments
> 
> 
> > which is opposite of the full handshake.  In the session 
> resume case 
> > the peer is in a state where it may accept a TLS-Alert or 
> an EAP-Success.
> 
> I think that whenever TLS session resumption is performed 
> there is an implication that both the client and server agree 
> on the same access policy that was agreed during the initial 
> authentication with a TLS full handshake.  Based on this, it 
> seems to me that there is no reason for both entities to send 
> a TLS-Alert message during TLS session resumption procedure 
> to indicate a problem in access policy.  If there is a 
> possibility of denying/changing the previous access policy, 
> TLS sesion resumption procedure should not be performed and 
> TLS full handshake should be performed instead.
> 

> > clients.  I'm not sure that this is a good idea.  The MUST for 
> > protected result indications seems to be a big change.  Given the 
> > above it appears that EAP-TLS does not meet protected result 
> > indications in all cases.
> > 
> > 
> > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > > 
> > 
> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
>