Subject: RE: [eap] Issue 213: Cleanup issues

From: "Joseph Salowey" <[email-masked]>
Date: Sun, 25 Jan 2004 22:24:27 -0800

Sorry I hit send too soon:

<snip>
> > 
> > On rereading this, it occurs to me that it is only SUCCESS
> > result indications that can be implicit;  FAILURE indications 
> > need to be explicit. So this is not so clear.
> > 
> >    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.
> > 
> >   and the
> >    server carries the conversation to completion (e.g. sends
> > a FINISHED Similarly, the peer can assume that the server will 
> grant access if
> >    it does not receive a TLS alert message from the server, 
> >    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.
> > 
> > As a result of the discussion we had on the operation of TLS
> > session resume, I went back and looked at RFC 2246 as well as 
> > E. Rescorla's SSL and TLS book.  I think these paragraphs are 
> > correct as written and apply to session resume.  Or am I 
> > missing something? 
> 
> [Joe] I haven't quite parsed your entire message yet, but 
> here is the issue I was looking at:
> 
> From 2246 the abbreviated handshake looks like this:
> 
> 
>       Client                                                Server
> 
>       ClientHello                   -------->
>                                                        ServerHello
>                                                 [ChangeCipherSpec]
>                                     <--------             Finished
>       [ChangeCipherSpec]
>       Finished                      -------->
> 	Application Data              <------->     Application Data
> 
> 
> 
> In this case the client does not receive an indication that 
> the server accepted the authentication.  Since the server 
> finished message comes first it is possible that the Client's 
> finished message is rejected by the server.  At this point a 
> failure or success is possible. Although the protocol 
> authentication is not considered complete until all the 
> finished messages have been correctly verified, I suppose 
> that it is very unlikely that the client would successfully 
> verify the server's finished message and respond with a bad 
> finished message if it were a valid client.  I don't think 
> there is a very big problem here.  However I do think we 
> should change 
> 
> "...server can assume that the peer will accept access if 
> granted it by the server." 
> to 
> "...server can assume that the peer has authenticated the server."
> 
> And
> 
" Similarly, the peer can assume that the server will grant access if it
does not receive a TLS alert message from the server,..."

To
 
" Similarly, the peer can assume that the server has successfully
authenticated the peer if it does not receive a TLS alert message from
the server,..."

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

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