RADIUS/1.1, Leveraging ALPN to remove MD5
draft-ietf-radext-radiusv11-11

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-radext-radiusv11-10

Thank you for the work put into this document. I really like the document and wish it will become standard ASAP but there are several (minor) issues, see below.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jan-Frederik Rieckers for the shepherd's detailed write-up including the WG consensus and the justification of the intended status, which was very useful for the experimental status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Should version 1.1 be mentioned in the abstract and title ?

## Section 1

AFAIK, MD5 cannot be used to "sign" but only "authenticate", should `sign packets` be rewritten ?

s/those transport protocols still rel*ied* on MD5/those transport protocols still rel*y* on MD5/ ?

I feel uncomfortable about the mention of "FIPS-140", which is a US (AFAIK) specification albeit used worldwide, in an IETF document. At the bare minimum, add an informational reference to it and make it clear that FIPS-140 is "e.g.", i.e., just an example.

As in the other document, the use of the personal pronoun "we" is not really suitable in an IETF document... does it represent the author ? the WG ? the IETF community ? Rather use the passive voice (and I know that Alan does not like it ;-) ).

"RADIUS/1.1" is mentioned without being formally defined as "this specification" ? But can an experimental draft define a standard protocol version ?

Where is "home server" defined ?

`can remove all uses of MD4` but the title and abstract are about MD5 only...

## Section 3.1

`Implementations MUST NOT have an administrative flag which causes a connection to use "radius/1.1", but which does not signal that protocol via ALPN.` seems redundant with the previous sentence.

## Section 3.3

In my own understanding, flag means boolean variable and not a multiple 'enum' such as the four choices in this section. I.e., please s/flag/variable or enum/

I am also unsure whether local configuration is part of an IETF document (this comment can be ignored). Moreover, this section mixed normative BCP14 language about the features and one implementation syntax, this is rather confusing.

## Section 4.1

While the ALPN should differentiate between the packet format, I find it 'dangerous' to re-use the same packet format with different semantic, e.g., could the Code field be used to indicate RADIUS/1.1 ? E.g., by using the MSB of the field ? I sincerely wonder why the header was not fully redefined.

## Section 12

The first paragraph is not about acknowledgements, but it feels more like 'blaming', please remove it or move it to section 1.

# NITS (non-blocking / cosmetic)

## Section 3.1

s/protocols it supports../protocols it supports./

## Section 3.3

s/configuratiun/configuration/

[Ballot comment]
# Internet AD comments for draft-ietf-radext-radiusv11-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3.1

* "supports.." -> "supports."

### S3.3

* "capable performing" -> "capable of performing"

* "version string with MUST" -> "version string which MUST"

### S4.2.1

* "such changing" -> "such as changing"

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

IANA has completed its review of draft-ietf-radext-radiusv11-07. If any part of this review is inaccurate, please let us know.

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

In the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry in the Transport Layer Security (TLS) Extensions registry group located at:

https://www.iana.org/assignments/tls-extensiontype-values/

two new registrations will be made as follows:

Protocol: RADIUS/1.0
Identification Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x30
("radius/1.0")
Reference: [ RFC-to-be ]

Protocol: RADIUS/1.1
Identification Sequence: Id. Sequence: 0x72 0x61 0x64 0x69 0x75 0x73 0x2f 0x31 0x2e 0x31
("radius/1.1")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-radext-radiusv11@ietf.org, mrcullen42@gmail.com, paul.wouters@aiven.io, radext-chairs@ietf.org, radext@ietf.org, rieckers@dfn.de, rieckers@uni-bremen.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RADIUS ALPN and removing MD5) to Experimental RFC


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document: - 'RADIUS ALPN and removing MD5'
  as Experimental 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 2024-06-26. 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 defines Application-Layer Protocol Negotiation
  Extensions for use with RADIUS/TLS and RADIUS/DTLS.  These extensions
  permit the negotiation of an additional application protocol for
  RADIUS over (D)TLS.  No changes are made to RADIUS/UDP or RADIUS/TCP.
  The extensions allow the negotiation of a transport profile where the
  RADIUS shared secret is no longer used, and all MD5-based packet
  signing and attribute obfuscation methods are removed.  When this
  extension is used, the previous Authenticator field is repurposed to
  contain an explicit request / response identifier, called a Token.
  The Token also allows more than 256 packets to be outstanding on one
  connection.

  This extension can be seen as a transport profile for RADIUS, as it
  is not an entirely new protocol.  It uses the existing RADIUS packet
  layout and attribute format without change.  As such, it can carry
  all present and future RADIUS attributes.  Implementation of this
  extension requires only minor changes to the protocol encoder and
  decoder functionality.  The protocol defined by this extension is
  named "RADIUS version 1.1", or "RADIUS/1.1".

  This document updates RFC5176, RFC6614, and RFC 7360.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/



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

# Document Shepherd Write-Up for draft-ietf-radext-radiusv11

*Using the template for Shepherd Write-Ups dated 4 July 2022.*
The reviewed version of the document is https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-04.txt

## Document History

> Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a broad consensus of the WG that this work is useful.
In the first WGLC only three people expressed their explicit support, after a first review and a second (1-week) WGLC, more people expressed support and nobody objected.



> Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy around the naming of the new specification. Ultimately it was decided to not name the document "RADIUS version 1.1", since it is not really a new RADIUS version, however, this name is still present in the ALPN label.

Another point of controversy was around the specific language regarding FIPS-140 compliance, especially regarding the ability to be FIPS complient despite using cryptographic methods like MD5, if they are not used for security. Input from several individuals that have experience in this area should have resolved these issues, so that the document reflects a correct representation of the topic regarding FIPS-140 compliance.



> Has anyone threatened an appeal or otherwise indicated extreme discontent?
 
No.



> For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There is an implementation of this draft available in FreeRADIUS.
Other implementers have signaled their willingness to implement, namely radsecproxy and RADIATOR.



## Additional Reviews

> Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document closely interacts with TLS, in particular the ALPN feature.
There has been no explicit review of the document in the TLS working group yet, but the document shepherd believes that a review of by the TLS WG would be of benefit, especially since the document shepherd is not as experienced in the TLS specification.
One specific topic for the TLS WG to review would be the specification about TLS session resumption and ALPN.



> Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are required.



> If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation?

This document does not contain YANG.



> Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain any formal language that needs to be validated.



## Document Shepherd Checks

> Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well-written and well-structured.
The specification is clear and complete.
The ALPN feature for RADIUS/(D)TLS with the additional benifits of increased ID space for increased number of parallel pending authentications and losing the dependency MD5 is definitely needed.

There are still some small issues, that are summarized in this message to the radext WG mailinglist:
https://mailarchive.ietf.org/arch/msg/radext/fPFY7ZafCsMVAxqS6AjOqdmO2Zg

These issues do not warrent a further hold, the document can be handed off to the AD and the issues can be addressed during the publication process.


> Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

From the Doc Shepherd's perspective, this document should not have any issues that are listed in common issues outside the SEC area. As previously stated, review from TLS experts is encouraged, since this document makes use of several TLS features.



>What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document currently intends to be published as Experimental.
The document header states this, as does the datatracker attribute.
An issue regarding this status has been raised by the responsible AD Paul Wouters, who requested to add considerations about the experimental status of the draft with a timeline when this new specification will be moved to standards track.
Given the reliance on the still-experimental documents RFC6614 and RFC7360, the experimental status is appropriate. Waiting for the RADIUS/(D)TLS-bis draft was concidered by the working group, but ultimately the WG chose to move forward with the document as-is and possibly re-publish it in the standards track after the RADIUS/(D)TLS-bis draft is published as standards-track RFC.



> Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed?

There have been no IPR disclosures, and neither the author, the chairs, nor the document shepherd are aware of other IPR claims.



> Has each author, editor, and contributor shown their willingness to be
    listed as such?

Yes.



> Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

From the content guidelines, the following issues arise:

The security consideration section does not contain specific text. Since the whole document addresses security considerations raised against RADIUS and explains them inline, this could be seen as sufficient.

The idnits tool issued the following warnings:
  * Unused/Duplicate Reference `[BCP14]`
      * Section 2 (Terminology) references both RFC2119 and RFC8174. Probably the reference to `[BCP14]` could be just removed from the normative references section.
  * Obsolete reference to RFC 5077 (Stateless TLS Session Resumption)
      * This reference is part of a citation from RFC 8301, Section 3.1
  * No mention of the updated RFCs in the abstract
      * The abstract does not have direct references to the RFC-numbers, but mentions the protocol names defined in these RFCs (RFC6614 RADIUS/TLS, RFC7360 RADIUS/DTLS). RFC 5176 is not mentioned in the abstract, only in the introduction. Since the update of RFC 5176 is minimal (allowing the "Error-Cause" attribute to appear in Access-Rejects), the Doc Shepherd thinks this is sufficient, a separate mention of the update in the abstract would needlessly lengthen the abstract.



> Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
The curent document lists RFC6614 (RADIUS/TLS), RFC7360 (RADIUS/DTLS) and RFC5175 (Dynamic Authorization Extensions to RADIUS) as documents to be updated, but they are referenced only informatively.
The document shepherd believes that at least RFC6614 and RFC7360 should be normative references, since this document is based on these two documents and understanding the specification in those documents is neccessary to understand the specification in this document.



> List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are RFCs and therefore freely available.



> Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
The current specification does not contain downward references.



> Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The current specification does not have references to work in progress documents.
There is currently work done in the radext WG that will deprecate RFC6614 and RFC7360 by issuing a -bis document (draft-ietf-radext-radius-dtls-bis)
The progress on that bis-draft is mostly independent from the ALPN document, the ALPN document can be published without a problem.


> Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The updated RFCs are stated on the title page. (For details about Abstract/Introduction see answer to idnits above.)

The document changes some RADIUS attributes that were defined in the original RADIUS documents and later additions (RFC2865, RFC2548, RFC2868).
Since those updates are specific to this document and the list is not exhaustive (i.e. other vendor-specific attributes may also implement an obfuscation based on the shared secret), it is reasonable to not include these RFCs in the "Updates:" part of this document.



> Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section aligns with the rest of the document.
The document inserts two new values in the TLS ALPN Protocol IDs registry, which has the Registration procedure "Expert Review". The registry entries in the document match the required data for the IANA registry.

An expert review has not taken place yet.



> List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document does not allocate new IANA registries.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-radext-radiusv11

*Using the template for Shepherd Write-Ups dated 4 July 2022.*
The reviewed version of the document is https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-04.txt

## Document History

> Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a broad consensus of the WG that this work is useful.
In the first WGLC only three people expressed their explicit support, after a first review and a second (1-week) WGLC, more people expressed support and nobody objected.



> Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy around the naming of the new specification. Ultimately it was decided to not name the document "RADIUS version 1.1", since it is not really a new RADIUS version, however, this name is still present in the ALPN label.

Another point of controversy was around the specific language regarding FIPS-140 compliance, especially regarding the ability to be FIPS complient despite using cryptographic methods like MD5, if they are not used for security. Input from several individuals that have experience in this area should have resolved these issues, so that the document reflects a correct representation of the topic regarding FIPS-140 compliance.



> Has anyone threatened an appeal or otherwise indicated extreme discontent?
 
No.



> For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There is an implementation of this draft available in FreeRADIUS.
Other implementers have signaled their willingness to implement, namely radsecproxy and RADIATOR.



## Additional Reviews

> Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document closely interacts with TLS, in particular the ALPN feature.
There has been no explicit review of the document in the TLS working group yet, but the document shepherd believes that a review of by the TLS WG would be of benefit, especially since the document shepherd is not as experienced in the TLS specification.
One specific topic for the TLS WG to review would be the specification about TLS session resumption and ALPN.



> Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are required.



> If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation?

This document does not contain YANG.



> Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain any formal language that needs to be validated.



## Document Shepherd Checks

> Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well-written and well-structured.
The specification is clear and complete.
The ALPN feature for RADIUS/(D)TLS with the additional benifits of increased ID space for increased number of parallel pending authentications and losing the dependency MD5 is definitely needed.

There are still some small issues, that are summarized in this message to the radext WG mailinglist:
https://mailarchive.ietf.org/arch/msg/radext/fPFY7ZafCsMVAxqS6AjOqdmO2Zg

These issues do not warrent a further hold, the document can be handed off to the AD and the issues can be addressed during the publication process.


> Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

From the Doc Shepherd's perspective, this document should not have any issues that are listed in common issues outside the SEC area. As previously stated, review from TLS experts is encouraged, since this document makes use of several TLS features.



>What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document currently intends to be published as Experimental.
The document header states this, as does the datatracker attribute.
An issue regarding this status has been raised by the responsible AD Paul Wouters, who requested to add considerations about the experimental status of the draft with a timeline when this new specification will be moved to standards track.
Given the reliance on the still-experimental documents RFC6614 and RFC7360, the experimental status is appropriate. Waiting for the RADIUS/(D)TLS-bis draft was concidered by the working group, but ultimately the WG chose to move forward with the document as-is and possibly re-publish it in the standards track after the RADIUS/(D)TLS-bis draft is published as standards-track RFC.



> Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed?

There have been no IPR disclosures, and neither the author, the chairs, nor the document shepherd are aware of other IPR claims.



> Has each author, editor, and contributor shown their willingness to be
    listed as such?

Yes.



> Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

From the content guidelines, the following issues arise:

The security consideration section does not contain specific text. Since the whole document addresses security considerations raised against RADIUS and explains them inline, this could be seen as sufficient.

The idnits tool issued the following warnings:
  * Unused/Duplicate Reference `[BCP14]`
      * Section 2 (Terminology) references both RFC2119 and RFC8174. Probably the reference to `[BCP14]` could be just removed from the normative references section.
  * Obsolete reference to RFC 5077 (Stateless TLS Session Resumption)
      * This reference is part of a citation from RFC 8301, Section 3.1
  * No mention of the updated RFCs in the abstract
      * The abstract does not have direct references to the RFC-numbers, but mentions the protocol names defined in these RFCs (RFC6614 RADIUS/TLS, RFC7360 RADIUS/DTLS). RFC 5176 is not mentioned in the abstract, only in the introduction. Since the update of RFC 5176 is minimal (allowing the "Error-Cause" attribute to appear in Access-Rejects), the Doc Shepherd thinks this is sufficient, a separate mention of the update in the abstract would needlessly lengthen the abstract.



> Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
The curent document lists RFC6614 (RADIUS/TLS), RFC7360 (RADIUS/DTLS) and RFC5175 (Dynamic Authorization Extensions to RADIUS) as documents to be updated, but they are referenced only informatively.
The document shepherd believes that at least RFC6614 and RFC7360 should be normative references, since this document is based on these two documents and understanding the specification in those documents is neccessary to understand the specification in this document.



> List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are RFCs and therefore freely available.



> Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
The current specification does not contain downward references.



> Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The current specification does not have references to work in progress documents.
There is currently work done in the radext WG that will deprecate RFC6614 and RFC7360 by issuing a -bis document (draft-ietf-radext-radius-dtls-bis)
The progress on that bis-draft is mostly independent from the ALPN document, the ALPN document can be published without a problem.


> Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The updated RFCs are stated on the title page. (For details about Abstract/Introduction see answer to idnits above.)

The document changes some RADIUS attributes that were defined in the original RADIUS documents and later additions (RFC2865, RFC2548, RFC2868).
Since those updates are specific to this document and the list is not exhaustive (i.e. other vendor-specific attributes may also implement an obfuscation based on the shared secret), it is reasonable to not include these RFCs in the "Updates:" part of this document.



> Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section aligns with the rest of the document.
The document inserts two new values in the TLS ALPN Protocol IDs registry, which has the Registration procedure "Expert Review". The registry entries in the document match the required data for the IANA registry.

An expert review has not taken place yet.



> List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document does not allocate new IANA registries.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for draft-ietf-radext-radiusv11

*Using the template for Shepherd Write-Ups dated 4 July 2022.*
The reviewed version of the document is https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-04.txt

## Document History

> Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is a broad consensus of the WG that this work is useful.
In the first WGLC only three people expressed their explicit support, after a first review and a second (1-week) WGLC, more people expressed support and nobody objected.



> Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy around the naming of the new specification. Ultimately it was decided to not name the document "RADIUS version 1.1", since it is not really a new RADIUS version, however, this name is still present in the ALPN label.

Another point of controversy was around the specific language regarding FIPS-140 compliance, especially regarding the ability to be FIPS complient despite using cryptographic methods like MD5, if they are not used for security. Input from several individuals that have experience in this area should have resolved these issues, so that the document reflects a correct representation of the topic regarding FIPS-140 compliance.



> Has anyone threatened an appeal or otherwise indicated extreme discontent?
 
No.



> For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
 
There is an implementation of this draft available in FreeRADIUS.
Other implementers have signaled their willingness to implement, namely radsecproxy and RADIATOR.



## Additional Reviews

> Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document closely interacts with TLS, in particular the ALPN feature.
There has been no explicit review of the document in the TLS working group yet, but the document shepherd believes that a review of by the TLS WG would be of benefit, especially since the document shepherd is not as experienced in the TLS specification.
One specific topic for the TLS WG to review would be the specification about TLS session resumption and ALPN.



> Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are required.



> If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation?

This document does not contain YANG.



> Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain any formal language that needs to be validated.



## Document Shepherd Checks

> Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is well-written and well-structured.
The specification is clear and complete.
The ALPN feature for RADIUS/(D)TLS with the additional benifits of increased ID space for increased number of parallel pending authentications and losing the dependency MD5 is definitely needed.

There are still some small issues, that are summarized in this message to the radext WG mailinglist:
https://mailarchive.ietf.org/arch/msg/radext/fPFY7ZafCsMVAxqS6AjOqdmO2Zg

These documents do not warrent a further hold, the document can be handed off to the AD and the issues can be addressed during the publication process.


> Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

From the Doc Shepherd's perspective, this document should not have any issues that are listed in common issues outside the SEC area. As previously stated, review from TLS experts is encouraged, since this document makes use of several TLS features.



>What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document currently intends to be published as Experimental.
The document header states this, as does the datatracker attribute.
An issue regarding this status has been raised by the responsible AD Paul Wouters, who requested to add considerations about the experimental status of the draft with a timeline when this new specification will be moved to standards track.
Given the reliance on the still-experimental documents RFC6614 and RFC7360, the experimental status is appropriate. Waiting for the RADIUS/(D)TLS-bis draft was concidered by the working group, but ultimately the WG chose to move forward with the document as-is and possibly re-publish it in the standards track after the RADIUS/(D)TLS-bis draft is published as standards-track RFC.



> Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed?

There have been no IPR disclosures, and neither the author, the chairs, nor the document shepherd are aware of other IPR claims.



> Has each author, editor, and contributor shown their willingness to be
    listed as such?

Yes.



> Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

From the content guidelines, the following issues arise:

The security consideration section does not contain specific text. Since the whole document addresses security considerations raised against RADIUS and explains them inline, this could be seen as sufficient.

The idnits tool issued the following warnings:
  * Unused/Duplicate Reference `[BCP14]`
      * Section 2 (Terminology) references both RFC2119 and RFC8174. Probably the reference to `[BCP14]` could be just removed from the normative references section.
  * Obsolete reference to RFC 5077 (Stateless TLS Session Resumption)
      * This reference is part of a citation from RFC 8301, Section 3.1
  * No mention of the updated RFCs in the abstract
      * The abstract does not have direct references to the RFC-numbers, but mentions the protocol names defined in these RFCs (RFC6614 RADIUS/TLS, RFC7360 RADIUS/DTLS). RFC 5176 is not mentioned in the abstract, only in the introduction. Since the update of RFC 5176 is minimal (allowing the "Error-Cause" attribute to appear in Access-Rejects), the Doc Shepherd thinks this is sufficient, a separate mention of the update in the abstract would needlessly lengthen the abstract.



> Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
The curent document lists RFC6614 (RADIUS/TLS), RFC7360 (RADIUS/DTLS) and RFC5175 (Dynamic Authorization Extensions to RADIUS) as documents to be updated, but they are referenced only informatively.
The document shepherd believes that at least RFC6614 and RFC7360 should be normative references, since this document is based on these two documents and understanding the specification in those documents is neccessary to understand the specification in this document.



> List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are RFCs and therefore freely available.



> Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
   
The current specification does not contain downward references.



> Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

The current specification does not have references to work in progress documents.
There is currently work done in the radext WG that will deprecate RFC6614 and RFC7360 by issuing a -bis document (draft-ietf-radext-radius-dtls-bis)
The progress on that bis-draft is mostly independent from the ALPN document, the ALPN document can be published without a problem.


> Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The updated RFCs are stated on the title page. (For details about Abstract/Introduction see answer to idnits above.)

The document changes some RADIUS attributes that were defined in the original RADIUS documents and later additions (RFC2865, RFC2548, RFC2868).
Since those updates are specific to this document and the list is not exhaustive (i.e. other vendor-specific attributes may also implement an obfuscation based on the shared secret), it is reasonable to not include these RFCs in the "Updates:" part of this document.



> Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section aligns with the rest of the document.
The document inserts two new values in the TLS ALPN Protocol IDs registry, which has the Registration procedure "Expert Review". The registry entries in the document match the required data for the IANA registry.

An expert review has not taken place yet.



> List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document does not allocate new IANA registries.



[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/