Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove support for unspecified SCRAM variants #6

Closed
horazont opened this issue Sep 25, 2018 · 0 comments
Closed

Remove support for unspecified SCRAM variants #6

horazont opened this issue Sep 25, 2018 · 0 comments
Labels
bug
Milestone
0.4

Comments

@horazont
Copy link
Owner

horazont commented Sep 25, 2018 •
edited
Loading

The following SCRAM variants are supported by aiosasl, but not specified in any IETF document:

  • SCRAM-SHA-224(-PLUS)
  • SCRAM-SHA-384(-PLUS)
  • SCRAM-SHA-512(-PLUS)

The only SCRAM-SHA-* specifications are: RFC7677 (-256) and RFC5802 (-1). Of those, RFC 7677 explicitly states:

Note: Members of this family MUST be explicitly registered using the "IETF Review" [RFC5226] registration procedure. Reviews MUST be requested on the KITTEN mailing list kitten@ietf.org (or a successor designated by the responsible Security Area Director).
[…]
Note to future SASL SCRAM mechanism designers: each new SASL SCRAM mechanism MUST be explicitly registered with IANA and MUST comply with the SCRAM-mechanism naming convention defined in Section 4 of [RFC5802].

So while the mechanisms outlined above adhere to the naming convention, they’re not registered with the IANA at this point in time.

This is thus a violation of the specification/unauthorized extension of the registered set of algorithms for no good reason. We should drop them to stay within the specification.

In addition, an argument can be made that it’s not our place to invent new SCRAM variants without review.
@horazont horazont added the bug label Sep 25, 2018
horazont added a commit that referenced this issue Nov 8, 2018
@horazont
Drop unspecified SCRAM(-PLUS) variants
04949c0 
The following SCRAM variants were previously supported by aiosasl,
but not specified in any IETF document:

* SCRAM-SHA-224(-PLUS)
* SCRAM-SHA-384(-PLUS)
* SCRAM-SHA-512(-PLUS)

The only SCRAM-SHA-* specifications are:

* RFC 7677 <https://tools.ietf.org/html/rfc7677> (SCRAM-SHA-256) and
* RFC 5802 <https://tools.ietf.org/html/rfc5802> (SCRAM-SHA-1).

Of those, RFC 7677 (which defines the registry) explicitly states:

> Note: Members of this family MUST be explicitly registered using
> the "IETF Review" [RFC5226] registration procedure.  Reviews MUST
> be requested on the KITTEN mailing list kitten@ietf.org (or a
> successor designated by the responsible Security Area Director).
>
> […]
>
> Note to future SASL SCRAM mechanism designers: each new SASL
> SCRAM mechanism MUST be explicitly registered with IANA and MUST
> comply with the SCRAM-mechanism naming convention defined in
> Section 4 of [RFC5802].

So while the unspecified mechanisms outlined above adhere to the
naming convention, they’re  not registered with the IANA (see
<https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml>)
at this point in time.

This is thus a violation of the specification/unauthorized
extension of the registered set of algorithms for no good reason.
We should drop them to stay within the specification.

In addition, an argument can be made that it’s not our place to
invent new SCRAM variants without review.

Fixes #6.
@horazont horazont mentioned this issue Nov 8, 2018
Merged
@horazont horazont added this to the 0.4.0 milestone Nov 8, 2018
horazont added a commit that referenced this issue Nov 8, 2018
@horazont
Drop unspecified SCRAM(-PLUS) variants
7c2e54f 
The following SCRAM variants were previously supported by aiosasl,
but not specified in any IETF document:

* SCRAM-SHA-224(-PLUS)
* SCRAM-SHA-384(-PLUS)
* SCRAM-SHA-512(-PLUS)

The only SCRAM-SHA-* specifications are:

* RFC 7677 <https://tools.ietf.org/html/rfc7677> (SCRAM-SHA-256) and
* RFC 5802 <https://tools.ietf.org/html/rfc5802> (SCRAM-SHA-1).

Of those, RFC 7677 (which defines the registry) explicitly states:

> Note: Members of this family MUST be explicitly registered using
> the "IETF Review" [RFC5226] registration procedure.  Reviews MUST
> be requested on the KITTEN mailing list kitten@ietf.org (or a
> successor designated by the responsible Security Area Director).
>
> […]
>
> Note to future SASL SCRAM mechanism designers: each new SASL
> SCRAM mechanism MUST be explicitly registered with IANA and MUST
> comply with the SCRAM-mechanism naming convention defined in
> Section 4 of [RFC5802].

So while the unspecified mechanisms outlined above adhere to the
naming convention, they’re  not registered with the IANA (see
<https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml>)
at this point in time.

This is thus a violation of the specification/unauthorized
extension of the registered set of algorithms for no good reason.
We should drop them to stay within the specification.

In addition, an argument can be made that it’s not our place to
invent new SCRAM variants without review.

Fixes #6.
@horazont horazont mentioned this issue Aug 17, 2019
Closed
@SamWhited SamWhited mentioned this issue May 14, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
0.4
Development

No branches or pull requests
1 participant
@horazont