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
