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