Re: draft-thomson-httpbis-cant

On 22/10/14 15:52, Ilari Liusvaara wrote:
> On Wed, Oct 22, 2014 at 03:10:45PM +0100, Stephen Farrell wrote:
>>
>> 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.
> 
> Looks like the name is "ClientCertificate" (the first
> paragraph)

Yup. I'm suggesting a change. Which as Martin noted
might amount to a different scope.

>  
>> - 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.
> 
> It is not for backwards compatiblity. TLS 1.0-1.2
> have the equivalent field. TLS 1.3 probably not.
> 
> And besides, having it available at HTTP level saves
> a handshake attempt to obtain the list of acceptable
> CAs.

But turns out that (the acceptable CA list) doesn't work
well except in enterprise cases, in which case it's probably
a no-brainer anwyay.

> 
>> - 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?).
> 
> The matching looks the simplest possible: Raw opaque
> binary blob (to be compared using memcmp()) Base64url
> encoded.

Matching isn't the problem here, but rather en/de-coding
and presentation. Its worth being less flexible than is
allowed by X.500 names.

> 
>> - 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.
> 
> - This uses existing registry of hashes, whereas
>   HPKP defines just SHA-256, DANE has its own set
>   in registry and I think JOSE just defines SHA-1
>   and SHA-256.
> - Websec and JOSE pinning pins just keys inside
>   certificates, whereas this pins whole certificates.
>   DANE can pin either keys or whole certificate.

Right. There're a few things to check is the point and
a few nearly-trivially different choices to make.

> 
>> - 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).
> 
> I read the section that if the certificate is RPK,
> then the hash matches the RPK.
> 
> (Of course, this runs into trouble with identification).

Maybe just more clarity is all that's needed then. And
its easily fixed regardless.

> 
>> - 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.
> 
> Identifying the public key itself runs into trouble
> with identification.
> 
> If one does not use X509, one would presumably need
> some sort of tag to identify public key (and actually
> with X509, the CA can be such tag, since there is
> no requirement for the client to trust the CA).

I'm suggesting to use whatever TLS uses to identify
the public key id/container. Again, not a huge deal.

> 
>> - 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.
> 
> It will be a new TLS session.

Sure. Still worth figuring out though.

>> - 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
> 
> 
> Another thing that isn't clear: The spec says that the
> scheme can't be used with http://. What about HTTP/2
> oppsec http://? If not via proxy, there is presumably
> direct connection, suitable for using TLS client certificates.

Good point. I agree that needs to be figured out and
that there're a few possible sensible answers that
could be offered.

S.

> 
> 
> -Ilari
>

Received on Wednesday, 22 October 2014 16:08:11 UTC