Subject: [Emu] 2716bis13: Support of certificate_status extension

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Fri, 18 Jan 2008 20:02:44 -0500

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

Thanks,

Madjid 

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 22 Jan 2008 12:30:31 -0800

Hi Madjid,

Comments inline below: 

> -----Original Message-----
> From: Nakhjiri Madjid-VXT746 [mailto:[email-masked]] 
> Sent: Friday, January 18, 2008 5:03 PM
> To: [email-masked]; [email-masked]
> Subject: [Emu] 2716bis13: Support of certificate_status extension
> 
> Hi, 
>  
> "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.

---

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Wed, 23 Jan 2008 15:39:18 -0500

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-masked]] 
Sent: Tuesday, January 22, 2008 12:31 PM
To: Nakhjiri Madjid-VXT746; [email-masked]; [email-masked]
Subject: RE: [Emu] 2716bis13: Support of certificate_status extension

Hi Madjid,

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

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

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