[radext] Small issues in the ALPN draft

[Jan-Frederik Rieckers <[e-mail]>]

Hi,

I've will post my Doc Shepherd Write-Up for the RADIUS ALPN (RADIUSv1.1) 
draft in a few moments. (I wanted to have the archive link to this mail 
first)

While reading through the document one last time, I've found some small 
issues.
Neither of those issues justify holding the process again, I just want 
to keep them in mind, maybe get feedback from the other reviewers, if 
these issues actually exist (for some of the issues), or just to have 
them in mind for a possibly new version or the Auth48, if no other major 
issues are found:


In Section 1 Introduction:

"All attributes which have simple encodings (i.e. without using MD5 
obfuscation), all have the same encoding and meaning as before,"

remove ", all" in the middle.
Also I'd remove the "i.e." and replace it with "meaning" or something 
similar, since only attributes with shared-secret-based MD5-obfuscation 
are encoded differently.


In Section 2 Terminology:

I'd reorder the terminology, so "historic RADIUS/TLS" is ordered after 
"RADIUS over TLS" and I'd also replace the "RADIUS/TLS" in the 
description for "Historic RADIUS/TLS" with "RADIUS over TLS", since 
"RAIDUS/TLS" is defined as RFC6614 and "RADIUS over TLS" as RFC6614 or 
RFC7360


In Section 3.3:

One paragraph states that implementations which are set to forbid 
RADIUS/1.1 behave like RFC6614/RFC7360 implementations, but that is not 
completely accurate.
Those implementations may still send "RADIUS/1.0" ALPN in the TLS Client 
Hello, in fact it is specified (without an RFC2119 modifier) that 
clients should do that.


Section 3.3.1:

As far as I read this section, the text assumes that the packet format 
of the Protocol-Error packet is equal to RADIUS/1.0, since it mentions 
the Response Authenticator. The Response Authenticator does not exist in 
RADIUS/1.1.
It may be worth to explicitly state which packet format should be used 
and explicitly state what packet identifier should be used and if other 
attributes than the one specified are allowed.


Section 3.3.2:

"The server ACKs with..."
I think the "ACK" should be replaced, it's always good to assume that 
not everyone understands terminology, and although I think most 
implementers will understand what "to ACK something" means, some may not.


Section 4.2.1:
Typo: "For An implementation" -> "For an implementation"


Section 4.2.2:
The first section states "e.g. TLS transport" for deduplication, but 
with DTLS we may still need deduplication.
Since we introduced "TLS" as "TLS or DTLS" in the terminology, it would 
be good to explicitly exclude DTLS here.

After having read the document again, I'm also not exactly clear about 
the reasoning behind the 3rd paragraph (closing a connection that 
re-uses token values).
Having a rationale behind this specification would be good.


Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822