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

[Brian Campbell]

Okay, so I retract the idea of metadata indicating the hash alg/cnf method
(based on John pointing out that it doesn't really make sense).

That still leaves the question of whether or not to define additional
confirmation methods in this document (and if so, what they would be though
x5t#S384 and x5t#S512 seem the most likely).

There's some reasonable rational for both adding one or two new hash alg
confirmation methods in the doc now vs. sticking with just SHA256 for now.
I'll note again that the doc doesn't preclude using or later defining other
confirmation methods.

I'm kind of on the fence about it, to be honest. But that doesn't really
matter because the draft should reflect rough WG consensus. So I'm looking
to get a rough gauge of rough consensus. At this point there's one comment
out of WGLC asking for additional confirmation method(s). I don't think
that makes for consensus. But I'd ask others from the WG to chime in, if
appropriate, to help me better gauge consensus.

On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden 
wrote:

> I’m not particularly wedded to SHA-512, just that it should be possible to
> use something else. At the moment, the draft seems pretty wedded to
> SHA-256. SHA-512 may be overkill, but it is fast (faster than SHA-256 on
> many 64-bit machines) and provides a very wide security margin against any
> future crypto advances (quantum or otherwise). I’d also be happy with
> SHA-384, SHA3-512, Blake2 etc but SHA-512 seems pretty widely available.
>
> I don’t think short-lived access tokens is a help if the likelihood is
> that certs will be reused for many access tokens.
>
> Public Web PKI certs tend to only use SHA-256 as it has broad support, and
> I gather there were some compatibility issues with SHA-512 certs in TLS.
> There are a handful of SHA-384 certs - e.g., the Comodo CA certs for
> https://home.cern/ are signed with SHA-384 (although with RSA-2048, which
> NSA estimates at only ~112-bit security). SHA-512 is used on some internal
> networks where there is more control over components being used, which is
> also where people are mostly likely to care about security beyond 128-bit
> level (eg government internal networks).
>
> By the way, I just mentioned quantum attacks as an example of something
> that might weaken the hash in future. Obviously, quantum attacks completely
> destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it
> provides a considerable margin to hedge against future quantum *or
> classical* advances while allowing the paranoid to pick a stronger security
> level now. We have customers that ask for 256-bit AES already.
>
> (I also misremembered the quantum attack - “Serious Cryptography” by
> Aumasson tells me the best known quantum attack against collision
> resistance is O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) space
> so is impractical. I don’t know if that is the last word though).
>
> As for SHA-1, doesn’t that prove the point? SHA-1 is pretty broken now
> with practical collisions having been demonstrated. The kind of attacks on
> CA certs demonstrated for MD5 [1] are probably not too far off for SHA-1
> now. As far as I am aware, we’re nowhere near those kinds of attacks on
> SHA-256, but I’d prefer that there was a backup plan in place already
> rather than waiting to see (and waiting for everyone to have hard-coded
> SHA-256 everywhere).
>
> Now I have to get back to my daughter’s birthday party… :-)
>
> [1] http://www.win.tue.nl/hashclash/rogue-ca/
>
> Neil
>
>
> On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley 
> wrote:
> The WG discusses RS meta-data as part of one of Dick’s proposals.   I am
> unclear on who is going to work on it in what draft.
>
> If the client is doing mtls to both the Token endpoint and RS the
> information in the confirmation method is not relevant to the client as
> long as the AS and RS are in agreement like with most tokens.
>
> The hash on the certificate and length of the signing key are equally or
> more vulnerable to any sort of attack.
> At least with AT the tokens are not long lived.
>
> Doing anything better than SHA256 only makes sense if the cert is signed
> by something stronger like SHA512 with a 2048bit RSA key.   That seems sort
> of unlikely in the near term.
>
> I prefer to wait to see what general fix is proposed before we jump the
> gun with a bandade for a small part of the overall problem.
>
> People are typically using SHA1 fingerprints.  We added SHA256 for JWT and
> got push back on that as overkill.
> I don’t think this is the correct place to be deciding this.
>
> We could say that if new thumbprints are defined the AS and RS can decide
> to use them as necessary.
> That is sort of the situation we have now.
>
> The correct solution may be a thousand rounds of PBKDF2 or something like
> that to make finding collisions more difficult rather than longer hashes.
>
> John B.
>
> > On Apr 12, 2018, at 5:20 PM, Brian Campbell 
> wrote:
> >
> > That's true about 

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

[Brian Campbell]

Thanks. Will do.

On Thu, Apr 19, 2018 at 8:57 AM, Benjamin Kaduk  wrote:

> I would go ahead and put them in.  The blog post might get some
> pushback, but I think there's plenty of precedent for academic
> papers.
>
> -Ben
>
> On Wed, Apr 18, 2018 at 09:34:23AM -0600, Brian Campbell wrote:
> > Thanks for the text, Neil. And the nit on the text, Ben. I'll include it
> in
> > the next draft.
> >
> > Ben, bit of a procedural question for you: can or should I include those
> > references (https://www.cryptologie.net/article/374/common-x509-
> certificate-
> > validationcreation-pitfalls/ & http://www.cs.utexas.edu/~
> > shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as
> > informational? Or? I'm honestly not sure if it's okay to cite a blog post
> > or university paper.
> >
> >
> >  validationcreation-pitfalls/>
> >
> >
> >
> >
> > On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk  wrote:
> >
> > > Picking nits, but maybe "established and well-tested X.509 library
> > > (such as one used by an established TLS library)", noting that TLS
> > > 1.3 has added a new protocol feature that allows for TLS and X.509
> > > library capabilities to be separately indicated (as would be needed
> > > if they were organizationally separate).
> > >
> > > -Ben
> > >
> > > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote:
> > > > OK, here’s a stab at a new security considerations section on X.509
> > > parsing and validation:
> > > >
> > > > ---
> > > > 5.3 X.509 Certificate Parsing and Validation Complexity
> > > >
> > > > Parsing and validation of X.509 certificates and certificate chains
> is
> > > complex and implementation mistakes have previously exposed security
> > > vulnerabilities. Complexities of validation include (but are not
> limited
> > > to) [1][2][3]:
> > > > - checking of Basic Constraints, basic and extended Key Usage
> > > constraints, validity periods, and critical extensions;
> > > > - handling of null-terminator bytes and non-canonical string
> > > representations in subject names;
> > > > - handling of wildcard patterns in subject names;
> > > > - recursive verification of certificate chains and checking
> certificate
> > > revocation.
> > > > For these reasons, implementors SHOULD use an established and
> > > well-tested TLS library for validation of X.509 certificate chains and
> > > SHOULD NOT attempt to write their own X.509 certificate validation
> > > procedures.
> > > >
> > > > [1] https://www.cryptologie.net/article/374/common-x509-certificate-
> > > validationcreation-pitfalls/  > > article/374/common-x509-certificate-validationcreation-pitfalls/>
> > > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf <
> > > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>
> > > > [3] https://tools.ietf.org/html/rfc5280 <
> https://tools.ietf.org/html/
> > > rfc5280>
> > > >
> > > > ---
> > > >
> > > > NB - this blog post [1] is the best concise summary of attacks I
> could
> > > find. Most of these attacks have been published as Black Hat talks and
> I
> > > can’t seem to find definitive references or good survey papers (beyond
> [2],
> > > which is a little older).
> > > >
> > > > Let me know what you think,
> > > >
> > > > Neil
> > > >
> > > >
> > > > > On 12 Apr 2018, at 20:42, Brian Campbell <
> bcampb...@pingidentity.com>
> > > wrote:
> > > > >
> > > > > Thanks Neil.
> > > > >
> > > > > Other than the potential metadata changes, which I'd like more WG
> > > input on and may raise in a new thread, I think I've got enough to make
> > > updates addressing your comments.  But please do send text for that
> > > Security Considerations bit, if you come up with something.
> > > > >
> > > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden <
> > > neil.mad...@forgerock.com > wrote:
> > > > > Hi Brian,
> > > > >
> > > > > Thanks for the detailed responses. Comments in line below (marked
> with
> > > ***).
> > > > >
> > > > > Neil
> > > > >
> > > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell <
> > > bcampb...@pingidentity.com > wrote:
> > > > > Thanks for the review and feedback, Neil. I apologize for my being
> > > slow to respond. As I said to Justin recently <
> > > https://mailarchive.ietf.org/arch/msg/oauth/cNmk8fSuxp37L-
> z8Rvr6_EnyCug>,
> > > 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 <
> > > neil.mad...@forgerock.com > wrote:
> > > > > Hi,
> > > > >
> > > > > I have reviewed this draft and have a number of comments, below.
> > > ForgeRock have not yet implemented this draft, but there i

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

[Benjamin Kaduk]

I would go ahead and put them in.  The blog post might get some
pushback, but I think there's plenty of precedent for academic
papers.

-Ben

On Wed, Apr 18, 2018 at 09:34:23AM -0600, Brian Campbell wrote:
> Thanks for the text, Neil. And the nit on the text, Ben. I'll include it in
> the next draft.
> 
> Ben, bit of a procedural question for you: can or should I include those
> references (https://www.cryptologie.net/article/374/common-x509-certificate-
> validationcreation-pitfalls/ & http://www.cs.utexas.edu/~
> shmat/shmat_ccs12.pdf) that Neil had with the text in the draft as
> informational? Or? I'm honestly not sure if it's okay to cite a blog post
> or university paper.
> 
> 
> 
> 
> 
> 
> 
> On Tue, Apr 17, 2018 at 8:13 AM, Benjamin Kaduk  wrote:
> 
> > Picking nits, but maybe "established and well-tested X.509 library
> > (such as one used by an established TLS library)", noting that TLS
> > 1.3 has added a new protocol feature that allows for TLS and X.509
> > library capabilities to be separately indicated (as would be needed
> > if they were organizationally separate).
> >
> > -Ben
> >
> > On Tue, Apr 17, 2018 at 10:48:04AM +0100, Neil Madden wrote:
> > > OK, here’s a stab at a new security considerations section on X.509
> > parsing and validation:
> > >
> > > ---
> > > 5.3 X.509 Certificate Parsing and Validation Complexity
> > >
> > > Parsing and validation of X.509 certificates and certificate chains is
> > complex and implementation mistakes have previously exposed security
> > vulnerabilities. Complexities of validation include (but are not limited
> > to) [1][2][3]:
> > > - checking of Basic Constraints, basic and extended Key Usage
> > constraints, validity periods, and critical extensions;
> > > - handling of null-terminator bytes and non-canonical string
> > representations in subject names;
> > > - handling of wildcard patterns in subject names;
> > > - recursive verification of certificate chains and checking certificate
> > revocation.
> > > For these reasons, implementors SHOULD use an established and
> > well-tested TLS library for validation of X.509 certificate chains and
> > SHOULD NOT attempt to write their own X.509 certificate validation
> > procedures.
> > >
> > > [1] https://www.cryptologie.net/article/374/common-x509-certificate-
> > validationcreation-pitfalls/  > article/374/common-x509-certificate-validationcreation-pitfalls/>
> > > [2] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf <
> > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>
> > > [3] https://tools.ietf.org/html/rfc5280  > rfc5280>
> > >
> > > ---
> > >
> > > NB - this blog post [1] is the best concise summary of attacks I could
> > find. Most of these attacks have been published as Black Hat talks and I
> > can’t seem to find definitive references or good survey papers (beyond [2],
> > which is a little older).
> > >
> > > Let me know what you think,
> > >
> > > Neil
> > >
> > >
> > > > On 12 Apr 2018, at 20:42, Brian Campbell 
> > wrote:
> > > >
> > > > Thanks Neil.
> > > >
> > > > Other than the potential metadata changes, which I'd like more WG
> > input on and may raise in a new thread, I think I've got enough to make
> > updates addressing your comments.  But please do send text for that
> > Security Considerations bit, if you come up with something.
> > > >
> > > > On Thu, Apr 12, 2018 at 3:03 AM, Neil Madden <
> > neil.mad...@forgerock.com > wrote:
> > > > Hi Brian,
> > > >
> > > > Thanks for the detailed responses. Comments in line below (marked with
> > ***).
> > > >
> > > > Neil
> > > >
> > > > On Wednesday, Apr 11, 2018 at 9:47 pm, Brian Campbell <
> > bcampb...@pingidentity.com > wrote:
> > > > Thanks for the review and feedback, Neil. I apologize for my being
> > slow to respond. As I said to Justin recently <
> > https://mailarchive.ietf.org/arch/msg/oauth/cNmk8fSuxp37L-z8Rvr6_EnyCug>,
> > 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 <
> > neil.mad...@forgerock.com > 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 <
> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1> defines
> > a new confirmation method “x5t#

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

[Torsten Lodderstedt]

+1 - It will makes thinks much simpler.

> Am 19.04.2018 um 00:58 schrieb Mike Jones :
> 
> I’m OK with this change, given it makes the OAuth suite of specs more 
> self-consistent.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Brian Campbell
> Sent: Wednesday, April 18, 2018 8:17 AM
> To: Torsten Lodderstedt 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12
>  
> The draft-ietf-oauth-token-exchange document makes use of scope and at some 
> point in that work it came to light that, despite the concept of scope being 
> used lots of places elsewhere, there was no officially registered JWT claim 
> for scope. As a result, we (the WG) decided to have 
> draft-ietf-oauth-token-exchange define and register a JWT claim for scope. 
> It's kind of an awkward place for it really but that's how it came to be 
> there.
> 
> When I added it to the draft, I opted for the semi-convention of JWT using 
> three letter short claim names.. And decided to use a JSON array to convey 
> multiple values rather than space delimiting. It seemed like a good idea at 
> the time - more consistent with other JWT claim names and cleaner to use the 
> facilities of JSON rather than a delimited string. That was the thinking at 
> the time anyway and, as I recall, I asked the WG about doing it that way at 
> one of the meetings and there was general, if somewhat absent, nodding in the 
> room.
> 
> Looking at this again in the context of the question from Torsten and his 
> developers, I think using a different name and syntax for the JWT claim vs.. 
> the Introspection response member/parameter/claim is probably a mistake.  
> While RFC 7662 Introspection response parameters aren't exactly the same as 
> JWT claims, they are similar in many respects. So giving consistent treatment 
> across them to something like scope is
> 
> Therefore I propose that the JWT claim for representing scope in 
> draft-ietf-oauth-token-exchange be changed to be consistent with the 
> treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. That 
> effectively means changing the name from "scp" to "scope" and the value from 
> a JSON array to a string delimited by spaces.
> 
> I realize it's late in the process to make this change but believe doing so 
> will significantly reduce confusion and issues in the long run. 
> 
>  
>  
> 
>  
>  
> On Sun, Apr 15, 2018 at 10:43 AM, Torsten Lodderstedt 
> mailto:tors...@lodderstedt.net>> wrote:
> Hi all,
> 
> I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ 
> to carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the 
> same purpose. As far as I understand the text, the intension is to represent 
> a list of RFC6749 scopes. Is this correct? What’s the rationale behind?
> 
> Different claim names for representing scope values confuse people. I 
> realized that when one of our developers pointed out that difference 
> recently. 
> 
> best regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
>  
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited..  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth