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

2018-04-16 Thread Nico Williams 
On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote:
> On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni 
> wrote:
> > A major obstacle to making access control decisions during the TLS
> > handshake is that at that time the server often does not yet have enough
> > information to determine which specific resource the client will ask to
> > access.
> 
> There's also the problem that (at least in an SOA/"microservice
> architecture") people will inevitably want some resources to be accessible
> without a client certificate, e.g. status endpoints or anything consumed by
> clients which do not support TLS certificates. In these cases it really
> helps to force things up a level out of the TLS handshake into something at
> the application level like an ACL language that lets you whitelist
> unauthenticated access to these resources.

Indeed, one might even say that user authentication should be driven by
application needs.  This is done in HTTP, for example, via 401
responses, which can trigger HTTP authentication.  Granted, HTTP
authentication methods are fairly limited.

If a client is authenticated at the TLS layer, authorization should
still happen at the application layer as much as possible, as otherwise
access control is very coarse-grained.

Nico
-- 

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

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

2018-04-16 Thread Tony Arcieri 
On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni 
wrote:

> A major obstacle to making access control decisions during the TLS
> handshake is that at that time the server often does not yet have enough
> information to determine which specific resource the client will ask to
> access.


There's also the problem that (at least in an SOA/"microservice
architecture") people will inevitably want some resources to be accessible
without a client certificate, e.g. status endpoints or anything consumed by
clients which do not support TLS certificates. In these cases it really
helps to force things up a level out of the TLS handshake into something at
the application level like an ACL language that lets you whitelist
unauthenticated access to these resources.

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

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

2018-04-16 Thread Viktor Dukhovni 


> On Apr 16, 2018, at 5:56 AM, Tobias Gondrom  
> wrote:
> 
> 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)

A major obstacle to making access control decisions during the TLS handshake is 
that at that time the server often does not yet have enough information to 
determine which specific resource the client will ask to access.

If the access control is very coarse, and the client is simply not allowed any 
of the features of the application, then one might terminate the handshake 
"early", but by the time server has processed the client certificate it has 
done pretty much all the heavy lifting (signing its own key exchange messages, 
...) so allowing the handshake to complete and dealing with access control at 
the application layer is far more typical, and makes possible more meaningful 
(to the client application) "Permission denied" error responses, which would be 
far less likely to be understood if communicated via a handshake failure.

-- 
Viktor.

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

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

2018-04-16 Thread 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 <kathleen.moriarty.i...@gmail.com> 
Sent: Monday, April 16, 2018 9:20 PM
To: Eric Rescorla <e...@rtfm.com>
Cc: Tobias Gondrom <tobias.gond...@gondrom.org>; <tls@ietf.org> <tls@ietf.org>
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 <e...@rtfm.com 
<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 <tobias.gond...@gondrom.org 
<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

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

2018-04-16 Thread Tony Arcieri 
On Mon, Apr 16, 2018 at 2:56 AM, Tobias Gondrom 
wrote:

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

I'm not sure what you mean by "before establishing a TLS connection", as
certificates are generally exchanged during the TLS handshake, so doing
anything "before establishing a TLS connection" would require the server
somehow know the client's certificate a priori. There are several systems
that will abort the handshake unless they receive an acceptable client
certificate, however.

I don't know of any RFCs for this per se, or anything that uses the Subject
CN (I think almost everything has completely moved away from using the CN).
However, as an example, SPIFFE is a largely Kubernetes-focused identity
system which encodes a "SPIFFE ID" in the client cert's subjectAltName and
uses that to determine whether clients are authorized to continue a TLS
connection:

https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md

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

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

2018-04-16 Thread Kathleen Moriarty 
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  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  
>> 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
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2018-04-16 Thread Eric Rescorla 
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 
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
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls