eap Mailing List: RE: Revised Proposed Resolution to Issue 207: Miscellaneous Comments

[Joseph Salowey (jsalowey]

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


> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>