Subject: [Emu] Q & C on 2716bis-08

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 08 Mar 2007 15:57:43 -0800

Hi Bernard, others, 

I have a few comments/ questions on 08 of the 2716bis. I apologize if this
has been discussed before.

Section 2.1.3

"

   If the EAP server authenticates unsuccessfully, the peer MAY send an

   EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert

   message identifying the reason for the failed authentication.  The

   peer MAY send a TLS alert message rather than immediately terminating

   the conversation so as to allow the EAP server to log the cause of

   the error for examination by the system administrator.

To ensure that the EAP Server receives the TLS alert message, the

   peer MUST wait for the EAP-Server to reply before terminating the

   conversation.  The EAP Server MUST reply with an EAP-Failure packet

   since server authentication failure is a terminal condition.

"

What sort of benefit does this provide. If a server fails to authenticate
due to a security reason, then its EAP failure would not matter, since it
cannot be trusted anyway.

If the authentication fails because of channel errors, we are not giving the
server another chance to authenticate, since it must send failure, so no
benefit here either.

Is this to allow the server to shut down the EAP state machine successfully?

Section 2.1.4 

"

An EAP-TLS peer supporting privacy MUST provide a certificate list

   containing at least one entry in response to the subsequent

   certificate_request sent by the server.  If the EAP-TLS server

   supporting privacy does not receive a client certificate in response

   to the subsequent certificate_request, then it MUST abort the

   session."

How would the peer and the server know this is a "subsequent certificate
request" and not the initial certificate request?

is there anything in the protocol to indicate this, not sure how? Or you
simply rely on the state for TLS tunnel.

Nit on key hierarchy text: TMS only mentioned in the figure 1, but nowhere
in the text.

Finally, this might be a dumb TLS question: 

Seems that if the TLS session is being resumed, it seems that only a
sessionID is being presented by the client, no server certs, no key exchange
records.

Is possession of anything (except of sessionID) being proven? Anything is
signed? Or the client and server just start using the established TLS master
key (TMS)?

Thanks,

Madjid

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 09 Mar 2007 06:34:38 -0800

>cannot be trusted anyway.

This is an optional mechanism for enabling the server to log the reason for 
the error.  This might allow an administrator to diagnose and correct the 
problem.

>request" and not the initial certificate request?

Because the peer did not provide a certificate in response to the first 
request -- that is how privacy is provided.

>signed?

Authentication is provided in the Finished message.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 09 Mar 2007 10:32:16 -0800

Hi Bernard,

Thanks for the quick reply. I am ok on the first and third questions,
thanks.

However, what I meant by my second question was how do we know from a
protocol stand point that this is not the first but a subsequent request?
Are we relying on the server state (a tunnel is established now)?

Madjid