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

Wearing my editor's hat here (did I do that right?) and looking to bring this to a close so the draft can proceed - I don't see a consensus for additional confirmation methods in this draft. On Tue, May 1, 2018 at 3:08 AM, Neil Madden wrote: > JOSE and many other

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

JOSE and many other specs have allowed algorithms to be specified at multiple security levels: a baseline 128-bit level, and then usually 192- and 256-bit levels too. It seems odd that a draft that is ostensibly for high security assurance environments would choose to only specify the lowest

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

We allow for new thumbprint algorithms to be defined and used with this spec. I think that we all agree that is a good thing. The question is if we should define them here or as part of JWT/CWT based on broader demand. Including them in this document may be a distraction in my opinion. There

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

Responses inline again. On Mon, 30 Apr 2018 at 19:44, John Bradley wrote: > Inline. > > > On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: > > Hi John, > > On 30 Apr 2018, at 15:07, John Bradley wrote: > > I lean towards

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

Yes that is an issue. I think one of the things that kicked this off was a question of will this make it pointless for people to use algs such as AES GCM256 when it is perceived that our choice of hash somehow limits overall security to 128bits. Let me take another run at this. Things like

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

On Mon, Apr 30, 2018 at 9:57 AM, Neil Madden wrote: > > > On 30 Apr 2018, at 15:07, John Bradley wrote: > > > My concern is that people will see a bigger number and decide it is > better if we define it in the spec. > > We may be getting people to

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

Inline. > On Apr 30, 2018, at 12:57 PM, Neil Madden > wrote: > > Hi John, > >> On 30 Apr 2018, at 15:07, John Bradley > > wrote: >> >> I lean towards letting new certificate

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

Hi John, > On 30 Apr 2018, at 15:07, John Bradley wrote: > > I lean towards letting new certificate thumbprints be defined someplace else. > > With SHA256, it is really second preimage resistance that we care about for a > certificate thumbprint, rather than simple

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

radley Sent: Monday, April 30, 2018 7:07 AM To: Brian Campbell <bcampb...@pingidentity.com> Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 I lean towards letting new certificate thumbprints be defined someplace else. With SHA256, it is really second p

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

I lean towards letting new certificate thumbprints be defined someplace else. With SHA256, it is really second preimage resistance that we care about for a certificate thumbprint, rather than simple collision resistance. MD5 failed quite badly with chosen prefix collision attacks against

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

That's pretty much in line with my on-the-fence position on it. On Fri, Apr 20, 2018 at 4:43 PM, Justin Richer wrote: > Additional confirmation methods can be easily defined outside of this > draft. That said, I think those two in particular are pretty > straightforward to add

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

Additional confirmation methods can be easily defined outside of this draft. That said, I think those two in particular are pretty straightforward to add (well-known algorithms that are widely available) so it might make sense to just toss them in now? I think it’s fine either way. — Justin

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

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

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

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

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

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/ &

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

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

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

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

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

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

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

That's true about it being opaque to the client. I was thinking of client metadata (config or registration) as a way for the AS to decide if to bind the AT to a cert. And moving from a boolean to a conf method as an extension of that. It would be more meaningful in RS discovery, if there was such

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

Inline Snip > > > 12. The use of only SHA-256 fingerprints means that the security strength of > the sender-constrained access tokens is limited by the collision resistance > of SHA-256 - roughly “128-bit security" - without a new specification for a > new thumbprint algorithm. An

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

Thanks for the schooling, Ben. On Thu, Apr 12, 2018 at 7:26 AM, Benjamin Kaduk wrote: > Just replying on one thing... > > On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden wrote: > > Hi Brian, > > > > Thanks for the detailed responses. Comments in line below (marked with >

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

Just replying on one thing... On Thu, Apr 12, 2018 at 10:03:11AM +0100, Neil Madden 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 > >

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

a MOST common scenario in a real world. And we don’t want > > > > everyone come up with their own names for the header. There should be > > > > some kind of standardization around the header names. > > > > > > > > Regards > > > > Vi

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

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 > wrote: > Thanks for the review and feedback, Neil. I apologize for my being

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

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

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

be some >> kind of standardization around the header names. >> >> Regards >> Vivek Biswas, CISSP >> >> *From:* John Bradley [mailto:ve7...@ve7jtb.com <ve7...@ve7jtb.com>] >> *Sent:* Thursday, March 29, 2018 11:57 AM >> *To:* Neil

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

on’t want everyone > come up with their own names for the header. There should be some kind of > standardization around the header names. > > Regards > Vivek Biswas, CISSP > > *From:* John Bradley [mailto:ve7...@ve7jtb.com <ve7...@ve7jtb.com>] > *Sent:* Thursday, March 2

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

adley [mailto:ve7...@ve7jtb.com] > Sent: Thursday, March 29, 2018 11:57 AM > To: Neil Madden > Cc: oauth > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07 > > Yes that is quite a common deployment scenario. I think that is the way > most of the Open Banking implementatio

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

  From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Thursday, March 29, 2018 11:57 AM To: Neil Madden Cc: oauth Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07   Yes that is quite a common deployment scenario.   I think that is the way most of the Open Banking implementations have

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

Yes that is quite a common deployment scenario. I think that is the way most of the Open Banking implementations have deployed it currently. The intent is to support that. One problem is that how the certificate is transmitted to the application tends to be load balancer/reverse proxy

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

Thanks, and understood. The privacy concerns are mostly around correlating activity of *clients*, which may or may not reveal activity patterns of users using those clients. I don’t know how much of a concern that is in reality, but thought it should be mentioned. A colleague also made the

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

Thanks for the feedback. We will review your comments and reply. One data point is that this will not be the only POP spec. The spec using token binding vs mtls has better privacy properties. It is UK Open banking that has pressed us to come up with a standard to help with

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

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.

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

I talked with Justin briefly yesterday after the meeting and he pointed out that the document is currently rather ambiguous about whether or not the base64 pad "=" character is to be used on the encoding of "x5t#S256" member. The intent was that padding be omitted and I'll take it as a WGLC