Hi Joe, Thanks for the reply, so basically if the underlying network access technology does not provide specification how to force the client to do a cert checking following successful access, there is essentially no benefit by using 6366 extensions, when the server does not support it.
Madjid -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 12:31 PM To: Nakhjiri Madjid-VXT746; [EMAIL PROTECTED]; [email protected] Subject: RE: [Emu] 2716bis13: Support of certificate_status extension Hi Madjid, Comments inline below: > -----Original Message----- > From: Nakhjiri Madjid-VXT746 [mailto:[EMAIL PROTECTED] > Sent: Friday, January 18, 2008 5:03 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: [Emu] 2716bis13: Support of certificate_status extension > > Hi, > > Question on the following text: > > > > "However, in the case where the EAP-TLS peer is attempting to obtain > network access, it will not have network connectivity and is therefore > not capable of checking for certificate revocation until after > authentication completes and network connectivity is available. For > this reason EAP-TLS peers and servers SHOULD implement Certificate > Status Request messages, as described in "Transport Layer Security > (TLS) Extensions" > [RFC4366] section 3.6. To enable revocation checking in situations > where servers do not support Certificate Status Request messages and > network connectivity is not available prior to authentication > completion, peer implementations MUST also support checking for > certificate revocation after authentication completes and network > connectivity is available, and they SHOULD utilize this capability by > default." > > > > In cases where the server does not support the certificate_status > extension, this is a little awkward, the server's cert is expired, but > the server does not support the extension. The client has already > gotten access to the network after EAP-TLS and so both TLS and the EAP > exchange is terminated by an EAP Success. How is the spec suggesting > the client to perform the revocation checking? [Joe] Once the client has network access it can attempt to access CRLs or certificate status services using existing mechanisms (CRL distribution points, OCSP, etc.) > and what is the > process to break the network access (ignoring the question on why a > client who would otherwise be a paying customer, really wanted this) > after already have gained the access? > [Joe] The process depends upon the client and underlying network access technology. > > > Thanks, > > > > Madjid > > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
