Re: [TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tobias Gondrom]

Hi Kathleen, Ekr and Tony, 

 

Thank you so much for your fast feedback. 

I did google a bit before asking, but didn’t dig deep enough into the document 
to find the right one. 

Your answers were most helpful. 

And I will dig more into the RFC link from Kathleen and the github link from 
Tony. 

 

Thanks a lot!

 

Tobias

 

 

From: Kathleen Moriarty  
Sent: Monday, April 16, 2018 9:20 PM
To: Eric Rescorla 
Cc: Tobias Gondrom ;  
Subject: Re: [TLS] question about verification of client side certificate for 
TLS session for mutual authentication

 

Hi Tobias,

 

If you use search terms that include pkix, authorization, access control, and 
attribute certificate profile, you’ll find a few documents.  This one should be 
helpful based on your description:

 

https://tools.ietf.org/html/rfc5755

 

Best regards,

Kathleen 

Sent from my mobile device


On Apr 16, 2018, at 4:55 AM, Eric Rescorla mailto:e...@rtfm.com> > wrote:

I am not aware of anywhere this is documented, primarily because it's so 
application-specifiic.

 

-Ekr

 

 

On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom mailto:tobias.gond...@gondrom.org> > wrote:

Hi dear TLS experts, 

 

Apologies for my stupid question for advise: 

I am currently working on some design requirements for mutual authentication 
and have a question regarding verification of client certificate. 

 

In many web scenarios the simple use is server authentication by certificate 
and verification of client id by username & password or by a simple 
verification of client certificate. 

 

Are there any RFCs that speak (beyond the general verification of the 
certificate in mutual TLS authentication) to the need to also verify the CN 
inside the client certificate against an additional whitelist _before_ 
establishing a TLS connection. 

 

For example in this scenario: 

A client with a valid certificate may be allowed to connect to application 1, 
but would not be allowed to connect to application 2. (for sake of separation 
application 1 and 2 are on separate servers (application 1 on server 1 and 
application 2 on server 2).) 

 

>From my current understanding, I would establish the TLS connection in both 
>cases, do mutual authentication and then let application 2 reject access based 
>on that the user is not allowed to access it. There is a question whether this 
>would expose to a risk that server resources could be exhausted by allowing to 
>establish the TLS connection before failing, but this does not seem too bad to 
>me. But maybe I am missing something…

 

Are there any informational (or standard) RFCs for TLS that speak about this 
risk and best practices to address it?  

(e.g. using additional whitelist checks of parameters inside the client 
certificate for access control checks already during phase of establishing the 
TLS connection)

 

Thank you and sorry for bothering, Tobias

 


___
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/tls

 

___
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] question about verification of client side certificate for TLS session for mutual authentication

[Tobias Gondrom]

Hi dear TLS experts, 

 

Apologies for my stupid question for advise: 

I am currently working on some design requirements for mutual authentication
and have a question regarding verification of client certificate. 

 

In many web scenarios the simple use is server authentication by certificate
and verification of client id by username & password or by a simple
verification of client certificate. 

 

Are there any RFCs that speak (beyond the general verification of the
certificate in mutual TLS authentication) to the need to also verify the CN
inside the client certificate against an additional whitelist _before_
establishing a TLS connection. 

 

For example in this scenario: 

A client with a valid certificate may be allowed to connect to application
1, but would not be allowed to connect to application 2. (for sake of
separation application 1 and 2 are on separate servers (application 1 on
server 1 and application 2 on server 2).) 

 

>From my current understanding, I would establish the TLS connection in both
cases, do mutual authentication and then let application 2 reject access
based on that the user is not allowed to access it. There is a question
whether this would expose to a risk that server resources could be exhausted
by allowing to establish the TLS connection before failing, but this does
not seem too bad to me. But maybe I am missing something.

 

Are there any informational (or standard) RFCs for TLS that speak about this
risk and best practices to address it?  

(e.g. using additional whitelist checks of parameters inside the client
certificate for access control checks already during phase of establishing
the TLS connection)

 

Thank you and sorry for bothering, Tobias

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id

[Tobias Gondrom]

Hello dear TLS WG and chairs, 
>From my side a strong support for the adoption of this WG draft. 
There are many scenarios, especially in IoT where this draft is essential to
maintain the right security association. If we can achieve this, we can
dramatically reduce the number of new handshakes and roundtrips in low-power
scenarios and thus dramatically reduce power consumption. In battery powered
IoT scenarios this can help and dramatically increase the lifetime of a
device. (potentially up to a factor of 2-3 longer lifetimes). 
Therefore this feature is very important for the success of DTLS in IoT. 
Thank you and hope we can progress this extension as soon as possible, 
Tobias
 
 
> Should have included a date: 13 December 2017.
> On Nov 28, 2017, at 15:17, Sean Turner < >
s...@sn3rd.com>; wrote:
> 
> All,
> 
> In Singapore @ IETF100, there was strong WG consensus to adopt
draft-rescorla-tls-dtls-connection-id, but we need to confirm this on the
list.  Please let us know by X December 2017 whether you oppose adopting
this draft and why.
> 
> Your chairs: J&S
 

References:


*

[TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id
Sean Turner 

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls