Subject: [secdir] Security review of draft-ietf-oauth-dyn-reg-management-12

From: Ben Laurie <[email-masked]>
Date: Wed, 1 Apr 2015 13:29:31 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: ready with issues.

Nit: the Security Consideration section contains normative
requirements. I don't know if this is strictly wrong, but it is
unusual. The style I am used to has the normative requirements in the
main body of the I-D, with Security Considerations confining itself to
explaining what is going on security-wise.

Issue: "Note that the authorization server decides the frequency of the
   credential rotation and not the client.  Methods by which the client
   can request credential rotation are outside the scope of this
   document."

Clients are presumably as likely as servers to cause credential
compromise, hence a mechanism by which a client can request a new
credential seems wise.

Of course, this could be used by an attacker to lock a client out, so
more thought required.

Issue: size limits.

There don't appear to be any limits (minimum server must accept, max
client must send) for client data. Not necessarily a security issue,
but seems likely to cause interop problems.

Issue: "Configuration Endpoint" (not a security issue)

It looks like the definition of this is deferred to
draft-ietf-oauth-dyn-reg, but I couldn't find it there either.

Issue: "The server MUST support TLS 1.2" - it seems unwise to mandate
a particular version of TLS - work on TLS 1.3 is already under way,
and TLS 1.2 is not (it seems) that far off deprecation!

Issue: " Since the client configuration endpoint is an OAuth 2.0 protected
   resource, it SHOULD have some rate limiting on failures to prevent
   the registration access token from being disclosed though repeated
   access attempts."

I am not sure what this is getting at. Limits on key re-use? Some kind
of BEAST defence? Something else?

Without some quantification of the threat, it seems hard to act on
this requirement.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 01 Apr 2015 16:26:13 +0200

Hi Ben,

I would like to respond to this issue:

> and TLS 1.2 is not (it seems) that far off deprecation!

We had a lengthy debate in OAuth around the issue of
mandatory-to-implement security functionality. Earlier we just pointed
to the use of TLS but then the question arises what version of TLS and
what ciphersuites to use.

Then, we came up with this text for all of our documents but it creates
the problem you outlined. In essence, all our documents will point to an
old TLS version in approx. 1 year from now when TLS 1.3 is finalized.

I believe this is a broader issue that needs to be solved in the
security area and not just with OAuth, namely should specifications
contain MTI security functionality when we know already at the time of
writing that they will be outdated within a reasonable amount of time?
In some sense, I see a bit of overlap with the crypto agility debate and
the attempt to reduce the overhead for standardization in introducing
new cryptographic algorithms.

I personally would like to replace these types of recommendations with
references to a page on the IETF website that talks about the most
recent TLS & ciphersuite recommendations. I am aware that this might
create problems with claiming interoperability with a specific RFC...

Help appreciated.

Ciao
Hannes

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Apr 2015 12:11:44 -0400 (EDT)

> create problems with claiming interoperability with a specific RFC...

Why not a BCP document for TLS usage?  It seems to be a charter item for
the uta WG already...

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 17:14:40 +0100

> Why not a BCP document for TLS usage?  It seems to be a charter item for

Well, initially OAuth wanted some specifics that matched the
deployments then seen, but yeah, I think the world may have
moved on sufficiently that a simple reference to the UTA BCP
(which is in the RFC editor queue) [1] might be fine. I'd
say it's defo worth asking the wg if they'd have a problem
with that now.

S.

[1] https://www.rfc-editor.org/queue2.html#draft-ietf-uta-tls-bcp

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 01 Apr 2015 19:05:44 +0200

Ben, Stephen,

I believe that this would be a good idea although it does not really
solve the underlying problem. Why? If we put a reference to the UTA BCP
in there then we end up in the need to update our documents in the not
too distance future to point to a new UTA BCP that talks about TLS 1.3.

Ciao
Hannes

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 1 Apr 2015 13:18:44 -0400

On Wed, Apr 1, 2015 at 1:05 PM, Hannes Tschofenig <[email-masked]
> wrote:

> too distance future to point to a new UTA BCP that talks about TLS 1.3.

I agree with Hannes here.  Having MTI for TLS 1.2 is fine for right now, it
must be supported, but doesn't mean other versions can't be supported once
libraries are available and it makes sense.  We can't hold this up because
TLS 1.3 is coming soon and would prefer that folks know they should be
implementing at least TLS 1.2.  A reference to the TLS BCP with this is
fine as well.  But this is one of the many OAuth drafts and not really the
place to call out specific requirements, like which of the recommended
cipher suites int eh BCP should be implemented for Oauth (I don't think
that has been done as it has for other protocols), but is not the right
place to do too much.

The web page/registry idea is a good one, so we can state current
recommendations.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: [email-masked]
Date: Wed, 1 Apr 2015 17:36:43 +0000

> too distance future to point to a new UTA BCP that talks about TLS 1.3.

No. Put in the bcp number and not the rfc number.

S

---

From: Ben Laurie <[email-masked]>
Date: Thu, 2 Apr 2015 18:15:52 +0100

On 1 April 2015 at 18:18, Kathleen Moriarty
<[email-masked]> wrote:
> implementing at least TLS 1.2.  A reference to the TLS BCP with this is fine
> as well.  But this is one of the many OAuth drafts and not really the place
> to call out specific requirements, like which of the recommended cipher
> suites int eh BCP should be implemented for Oauth (I don't think that has
> been done as it has for other protocols), but is not the right place to do
> too much.

Call it out wherever you want. _My_ job is to review this particular
I-D, and this is an issue with this particular I-D. I don't see how
the fact it is also an issue with many other I-Ds fixes that problem.

---

From: Radia Perlman <[email-masked]>
Date: Thu, 2 Apr 2015 13:25:21 -0400

Can't it just say "MUST support version 1.2 or later version of TLS"?

On Thu, Apr 2, 2015 at 1:15 PM, Ben Laurie <[email-masked]> wrote:

> fine
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 Apr 2015 20:42:00 +0200

Radia,

this is what we wrote in RFC 6749:

----

1.6.  TLS Version

   Whenever Transport Layer Security (TLS) is used by this
   specification, the appropriate version (or versions) of TLS will vary
   over time, based on the widespread deployment and known security
   vulnerabilities.  At the time of this writing, TLS version 1.2
   [RFC5246] is the most recent version, but has a very limited
   deployment base and might not be readily available for
   implementation.  TLS version 1.0 [RFC2246] is the most widely
   deployed version and will provide the broadest interoperability.

----

We then moved on to something shorter in RFC 7009:

----

The authorization
   server MUST use Transport Layer Security (TLS) [RFC5246] in a version
   compliant with [RFC6749], Section 1.6.  Implementations MAY also
   support additional transport-layer security mechanisms that meet
   their security requirements.

----

and now we are at:

----

   the server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY
   support additional transport-layer mechanisms meeting its security
   requirements.

----

I personally don't care too much what we are saying since folks in the
OAuth group would like to say the right thing anyway: we want to use the
most recent version of TLS. Unfortunately that is not specific enough.

If the trick Stephen suggested with referencing BCP numbers (instead of
RFCs) helps then I would go for that.

Ciao
Hannes

---

From: Ben Laurie <[email-masked]>
Date: Thu, 2 Apr 2015 21:35:19 +0100

> No. Put in the bcp number and not the rfc number.

I'd love to believe that story, because that would be awesome.

But when I look at BCPs, I see, for example:

BCP49 Delegation of IP6.ARPA R. Bush [ August 2001 ] ( TXT = 5727
bytes)(Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766,
RFC2553, RFC1886) (Also RFC3152) (Status: BEST CURRENT PRACTICE)

Obsoleted? Updates? Also?

What am I, as an implementer, supposed to do, if I'm told "follow BCP
49"? "Obsoleted" is particularly worrying.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 11:05:30 +0100

> 49"? "Obsoleted" is particularly worrying.

In this particular case, it's a reference to [1] we'd be adding
and that, I believe, is clear for a developer and there is really
no immediate liklihood that we obsolete the TLS protocol. We
don't need to solve the general problem of relationships between
RFCs.

S.

[1] https://tools.ietf.org/html/draft-ietf-uta-tls-bcp

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Apr 2015 10:09:54 -0400

Sorry, I was at a conference yesterday and not able to respond.

Sent from my iPhone

> On Apr 2, 2015, at 1:15 PM, Ben Laurie <[email-masked]> wrote:
> 

Yes and your review is very much appreciated.  We need to discuss the review to figure out what changes and doesn't in a draft.  Ideally, all of the security needs would have been clear in a foundational document, but as Hannes pointed out, requirements evolved as OAuth developed.

At this point in time, TLS 1.2 is the base requirement, which is appropriate.  As is a reference to the BCP that explains security for that version.  When support for 1.3 makes that feasible, an 'updates' draft can fix that.  If the BCP for 1.3 updates the current one for 1.2 (maybe there will be enough of a difference to make a new #), then the BCP number will already be in this draft.  We can't predict the future, but we can go off of what we know now and just move into the other questions raised in this review.

Thank you,
Kathleen

---

From: Ben Laurie <[email-masked]>
Date: Fri, 3 Apr 2015 18:11:54 +0100

On 3 April 2015 at 17:57, Justin Richer <[email-masked]> wrote:
> Ben, thanks for the review. Responses to particular points inline.
>
>> On Apr 1, 2015, at 8:29 AM, Ben Laurie <[email-masked]> wrote:
> I’m confused by this issue: “Client Configuration Endpoint” is defined as a term in §1.2 and its function and use are defined in §2, which is the majority of the spec’s content. I see no use of “configuration endpoint” apart from the full term of “client configuration endpoint” in the current document version.

Sorry about that, I think I just got lost. You appear to be correct.

> The rate limiting is going to take a number of different forms depending on the platform and deployment characteristics of the authorization server, so we don’t recommend any particular approach. This is also something that’s going to be changing quickly over the years, and instead of prescribing a specific solution we thought it better to describe the problem here and say that it must be mitigated.

Solution to what? This is precisely my issue - you haven't described
the problem, you've described a solution to some problem I'm finding
hard to guess.

In other words: how could the registration access token be disclosed
through repeated access attempts?

---

From: Ben Laurie <[email-masked]>
Date: Fri, 3 Apr 2015 18:26:20 +0100

On 3 April 2015 at 18:22, Justin Richer <[email-masked]> wrote:
> An attacker could keep poking at a client configuration endpoint with random self-generated tokens until it finds one that works. There’s no oracle attack or other portion that lets the attacker know they’re getting closer to a good token, just a basic repeated hammering of a protected resource This problem is mitigated by having a sufficiently random token (as recommended in RFC6750 and RFC6819) as well as rate-limiting the connections to the endpoint (also suggested by RFC6819). This is fairly common advice for any endpoint protected by a secret (in this case, an OAuth token). Is there a better way to state this so that it’s more clear to developers what they should look out for?

How about making it a non-problem by requiring sufficiently strong
tokens that there is no possibility of brute force?

Mildly astonished that this attack is even considered feasible.

---

From: Justin Richer <[email-masked]>
Date: Fri, 3 Apr 2015 12:57:28 -0400

> explaining what is going on security-wise.

I’ve seen both styles, and we can easily switch to having no normative text in this section if that is preferable to the AD and others here.

> compromise, hence a mechanism by which a client can request a new

Client rotation of secrets was considered and discussed by the working group, but ultimately dropped from this (experimental) version of the spec and deferred to a future extension or update of this spec. There are a lot of considerations on how to do that properly, and nobody has (to my knowledge) implemented a client-driven secret rotation yet.

> Of course, this could be used by an attacker to lock a client out, so

That’s only a concern if the attacker also gains the registration access token, which would presumably protect the credential rotation call as well. Since the registration access token is the mechanism by which a client is authorized by at the client configuration endpoint.

> but seems likely to cause interop problems.

I don’t see a good way to have a reasonable size recommendation across different platforms and deployments. The server is free to reject any metadata values that it doesn’t like, including those that are too long. The server chooses the client_id and client_secret, so those aren’t an issue on the server side, but a client will need to be able to deal with “a JSON string” value for each of these for widest interoperability. If you have suggested text for size restrictions that would be reasonable across platforms, please send it along.

> and TLS 1.2 is not (it seems) that far off deprecation!

The current text is at the request of the AD (Kathleen) and it’s meant to point to the best practice at the time of spec publication. My goal here is just to get people to use TLS and use it properly to protect the endpoints in question, but there’s not a good official way to say “just use TLS and don’t be stupid" in the IETF yet. This, you’ll note, is the topic of the thread resulting from this original email. I’ll defer to the outcome of that thread on this point and change the draft’s text if required.

Thanks again for your review,
 — Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 3 Apr 2015 13:22:20 -0400

Thanks,
 — Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 3 Apr 2015 15:02:58 -0400

> Mildly astonished that this attack is even considered feasible.

I’m fine with that resolution, or with just deferring to the appropriate sections of 6750 and 6819 here, if the AD’s are amenable to that change.

 — Justin

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 Apr 2015 15:14:04 -0400

On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer <[email-masked]> wrote:

> >>>> The rate limiting is going to take a number of different forms
> depending on the platform and deployment characteristics of the
> authorization server, so we don’t recommend any particular approach. This
> is also something that’s going to be changing quickly over the years, and
> instead of prescribing a specific solution we thought it better to describe
> the problem here and say that it must be mitigated.
> >>>
> >> An attacker could keep poking at a client configuration endpoint with
> random self-generated tokens until it finds one that works. There’s no
> oracle attack or other portion that lets the attacker know they’re getting
> closer to a good token, just a basic repeated hammering of a protected
> resource This problem is mitigated by having a sufficiently random token
> (as recommended in RFC6750 and RFC6819) as well as rate-limiting the
> connections to the endpoint (also suggested by RFC6819). This is fairly
> common advice for any endpoint protected by a secret (in this case, an
> OAuth token). Is there a better way to state this so that it’s more clear
> to developers what they should look out for?
> >
> I’m fine with that resolution, or with just deferring to the appropriate
> sections of 6750 and 6819 here, if the AD’s are amenable to that change.
>

If the WG is good with the change and there is no reason to make this a
non-problem, that would be ideal.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Apr 2015 13:14:45 -0700

Ben et. al.,

I took the proposal to the WG and have changed the draft text based on their feedback. The results are published here:

  http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-13

 — Justin

> On Apr 3, 2015, at 12:14 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Fri, Apr 3, 2015 at 3:02 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Apr 3, 2015, at 1:26 PM, Ben Laurie <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > On 3 April 2015 at 18:22, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> If the WG is good with the change and there is no reason to make this a non-problem, that would be ideal.
> 
> Thanks,
> Kathleen
> 
>  — Justin
> 
> 
> 
> --
> 
> Best regards,
> Kathleen

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Apr 2015 12:38:01 +0100

On 6 April 2015 at 21:14, Justin Richer <[email-masked]> wrote:
> Ben et. al.,
>
> I took the proposal to the WG and have changed the draft text based on their
> feedback. The results are published here:
>

Looks good.

>
>  — Justin
>
> On Apr 3, 2015, at 12:14 PM, Kathleen Moriarty
>> >>>> authorization server, so we don’t recommend any particular approach. This is
>> >>>> also something that’s going to be changing quickly over the years, and
>> >> resource This problem is mitigated by having a sufficiently random token (as
>> >> recommended in RFC6750 and RFC6819) as well as rate-limiting the connections
>> >> to the endpoint (also suggested by RFC6819). This is fairly common advice
>> >> for any endpoint protected by a secret (in this case, an OAuth token). Is
>> >> there a better way to state this so that it’s more clear to developers what
>> >> they should look out for?
>> >