The "secret-token" URI Scheme
draft-nottingham-how-did-that-get-into-the-repo-02

[Ballot comment]
Section 1

Per the comment in the shepherd writeup, RFC 6750 has a passable definition of "bearer
token".

Section 2

Perhaps an example Authorization header field (a la RFC 6750) would
demonstrate the "required for later access" aspect?

Section 4

  The token ABNF rule allows tokens as small as one character.  This is
  not recommended practice; applications should evaluate their
  requirements for entropy and issue tokens correspondingly.

I feel like we have some more concrete guidelines regarding token
entropy floating around.  BCP 106 is the obvious candidate, though its
emphasis is different than I would prefer.  I guess Section 8 is
tolerable.

  If it is difficult to correctly handle secret material, or unclear as
  to what the appropriate handling is, users might choose to obfuscate
  their secret tokens in order to evade detection (for example,
  removing the URI scheme for storage).  Clear guidelines and helpful
  tools are good mitigations here.

What would those "clear guidelines" be?

[Ballot comment]
Section 1. Typo. s/ike CSRF/like CSRF/

Section 4.  Easy to find tokens will cut both ways.  This URI scheme would make it trivial (with likely an acceptable false positive rate) for a CI system to trigger on the presence of a token in a repo.  It would also be worth mentioning that adoption of this scheme would also further lower the bar for attackers when scanning for these tokens too – even less semantic parsing of source code would be required.

[Ballot comment]
It's not clear to me whether or not this will truly help, but I don't see it causing any harm to the internet, and I think that it is good to try to mitigate against folk who either accidentally commit security tokens or deliberately commit them without any awareness of the consequences.

[Ballot comment]
It's not clear to me whether or not this will truly help, but I don't see it is causing any harm to the internet, and I think that it is good to try to mitigate against folks who either accidentally commit security tokens or deliberately commit them without any awareness of the consequences.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-nottingham-how-did-that-get-into-the-repo-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Uniform Resource Identifier (URI) Schemes registry located at:

https://www.iana.org/assignments/uri-schemes/

a new registration will be made as follows:

URI Scheme: secret-token
Template: [ TBD-at-Registration ]
Description: secret-token
Status: provisional
Well-known URI Support:
Reference: [ RFC-to-be ]
Notes:

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-03-12):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, superuser@gmail.com, draft-nottingham-how-did-that-get-into-the-repo@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The secret-token URI Scheme) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'The secret-token URI Scheme'
  as Informational
  RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document registers the "secret-token" URI scheme, to aid in the
  identification of authentication tokens.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get-into-the-repo/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get-into-the-repo/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Murray Kucherawy is the document shepherd.  Alexey Melnikov is the responsible Area Director.

  This document registers the "secret-token" URI scheme, to aid in the
  identification of authentication tokens.

The document seeks informational status, which is appropriate as it does not specify a standards-track protocol and instead registers a URI scheme and describes its intended use.

2. Review and Consensus

The document was discussed in the DISPATCH working group, where there was general support for the idea but no support for the notion of creating a working group around it.  DISPATCH recommended Area Director sponsorship and Alexey volunteered.

3. Intellectual Property

The author affirms compliance with BCPs 78 and 79.  No undeclared IPR claims are known.

4. Other Points

This document is informational, and as such downward references are not a concern.

The IANA Considerations section appears to be correct (with respect to RFC 7595) and complete.  Provisional registrations are first come first served, so this does not require expert review.

The document appears to be ready for publication.  About the only suggestion I have personally is that the term "bearer token" might deserve a reference to a formal definition, or at least an example ("e.g., password" maybe?).

No formal directorate reviews are required, other than the ones that will be triggered automatically anyway.

There is some ABNF in the document but it appears to be correct and complete.

Ship it!