Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

[Brian Campbell]

Thanks for the review and feedback, Neil. I apologize for my being slow to
respond. As I said to Justin recently
,
I've been away from things for a while. Also there's a lot here to get
through so took me some time.

It looks like John touched on some of your comments but not all. I'll try
and reply to them as best I can inline below.


On Thu, Mar 29, 2018 at 9:18 AM, Neil Madden 
wrote:

> Hi,
>
> I have reviewed this draft and have a number of comments, below. ForgeRock
> have not yet implemented this draft, but there is interest in implementing
> it at some point. (Disclaimer: We have no firm commitments on this at the
> moment, I do not speak for ForgeRock, etc).
>
> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1
> defines a new confirmation method “x5t#S256”. However, there is already a
> confirmation method “jwk” that can contain a JSON Web Key, which itself can
> contain a “x5t#S526” claim with exactly the same syntax and semantics. The
> draft proposes:
>
> { “cnf”: { “x5t#S256”: “…” } }
>
> but you can already do:
>
> { “cnf”: { “jwk”: { … , “x5t#S256”: “…” } } }
>
> If the intent is just to save some space and avoid the mandatory fields of
> the existing JWK types, maybe this would be better addressed by defining a
> new JWK type which only has a thumbprint? e.g., { “kty”: “x5t”, “x5t#S256”:
> “…” }.
>

The intent of the x5t#S256 confirmation method was to be space efficient
and straightforward while utilizing the framework and registry that RFC
7800 gives.  Even a new JWK type like that would still use more space. And
I'd argue that the new confirmation method is considerably more
straightforward than registering a new JWK type (and the implications that
would have on JWK implementations in general) in order to use the existing
"jwk" confirmation method.



>
> 2. I find the naming “mutual TLS” and “mTLS” a bit of a misnomer: it’s
> really only the client authentication that we are interested here, and the
> fact that the server also authenticates with a certificate is not hugely
> relevant to this particular spec (although it is to the overall security of
> OAuth). Also, TLS defines non-certificate based authentication mechanisms
> (e.g. TLS-SRP extension for password authenticated key exchange, PSK for
> pre-shared key authentication) and even non-X.509 certificate types (
> https://www.iana.org/assignments/tls-extensiontype-values/t
> ls-extensiontype-values.xhtml#tls-extensiontype-values-3). I’d prefer
> that the draft explicitly referred to “X.509 Client Certificate
> Authentication” rather than mutual TLS, and changed identifiers like
> ‘tls_client_auth’ (https://tools.ietf.org/html/d
> raft-ietf-oauth-mtls-07#section-2.1.1) to something more explicit like
> ‘tls_x509_pki_client_auth’.
>
> This is especially confusing in section 3 on sender constrained access
> tokens, as there are two different servers involved: the AS and the
> protected resource server, but there is no “mutual” authentication between
> them, only between each of them and the client.
>

Choosing names and terminology is difficult and the "right" wording is
often subjective. I believe that the current wording sufficiently conveys
what is going on in the draft to most readers. Most readers thus far seem
to agree. There is some text now that does say that the mutual auth in the
draft is in fact X.509 client cert authn but, in the next revision, I'll
look for other opportunities where it could be stated more clearly.



>
> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC
> only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The
> wording in Section 5.1 doesn’t seem clear if this could also be used with
> TLS 1.0 or 1.1, or whether it is only referring to future TLS versions.
>

The reference to BCP 195 (which unfortunately the original OAuth 2.0 RFC
doesn't have because it didn't exist then) is meant to account for changing
versions and recommendations around TLS. Currently that BCP says TLS 1.2 is
a must and suggests against 1.1 & 1.0 but doesn't outright prohibit them.



>
> 4. It might be useful to have a discussion for implementors of whether TLS
> session resumption (and PSK in TLS 1.3) and/or renegotiation impact the use
> of client certificates, if at all?
>

That might well be useful but I don't myself know what it would say. I've
(maybe naively) figured those are deployment details that will just work
out. Perhaps you could propose some text around such a discussion that the
WG could consider?



>
> 5. Section 3 defines sender-constrained access tokens in terms of the
> confirmation key claims (e.g., RFC 7800 for JWT). However, the OAuth 2.0
> Pop Architecture draft defines sender constraint and key confirmation as
> different things (https://tools.ietf.org/html/d
> raft-ietf-oauth-pop-architecture-08#section-6.2). The draft should decide
> which of those it is impl

[OAUTH-WG] Confirm

[Solen win]

-- 
Solenwin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth