draft-thomson-httpbis-cant

[Stephen Farrell <[e-mail]>]

First off, I like the idea - the more ways in which we
can try push passwords a bit further off stage the better.
So I hope this is taken up somewhere and progressed and
gets deployed.

That said:

- section 2: I don't like the auth scheme name - this
should work without X.509. I'd suggest "TLSClientAuth"
would be a better thing to use.

- 3.1: I assume this is solely for backwards compat?
If not they who do we expect to use this? If so,
please say so and encourage use of (hashes of) keys
or certs instead.

- 3.1: You should probably profile X.500 names for
use here - requiring the full complexity of X.500
(e.g. it allows for X.400 ORAddress as an option)
would seem like a bad idea. Not sure where you could
find that already done by someone else but it ought
be somewhere (maybe some ldap thing?).

- 3.2: Someone needs to do a compare/contrast against
websec's key pinning but also DANE and JOSE for this
bit. Not sure its quite right now.

- 3.2: You need to add support for hash(public-key)
which could be done like DANE or even via RFC6920
URIs if that made sense (no idea, so don't take this
as me pushing an RFC I co-authored:-). That's needed
for bare-keys TLS anyway, and is just a good plan (tm).

- somewhere: why not have a KeyIDType somewhere here
where the client/server can signal what kind(s) of
key identifiers (or containers) are being, or to be,
used. Probably something that maps to an existing
TLS construct. Who knows maybe someday someone will
come up with a privacy-friendly way to identify
public keys that'd even help with this in TLS1.2 and
earlier? So having that here would be a good plan
I think.

- Its not clear to me how or if this ought be bound
to the TLS session. I think that'd be a good thing
to ponder, but I've not:-) OTOH, it'd be a pain to
define this but also have it work via e.g. a TLS
MITM as that would utterly make it meaningless as a
strong client authentication scheme. Not sure what's
doable there but maybe the UA could send an Authorization
header field based on the challenge and a TLS extractor
(RFC5704) value and its public key as at least an
option that'd detect MITMs or maybe some other forms
of attack.

- I'd like if this were commensurate with HOBA [1]
so that in principle the same key pair could be
used. That's probably not that important to anyone
else though;-) And of course in contrast to what
I just suggested HOBA would work via a TLS MITM
but that's justified by HOBA's primary goal of being
a password replacement drop-in, whereas I think
you're aiming higher here.

- I'm sure you'll need changes to keep the http
auth scheme police happy:-) [1] seems to have now
achieved that status so copying from there may help.

S.

[1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba