On Mon, Apr 16, 2018 at 11:38:28AM -0700, Tony Arcieri wrote: > On Mon, Apr 16, 2018 at 9:11 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> > 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
