[radext] RADIUS/1.1 ALPN minor suggestions

[Matthew Newton <[e-mail]>]

A first pass at trivial and (hopefully) non-contentious suggestions and 
fixes for draft-dekok-radext-radiusv11-04.txt. Mostly typos or minor 
English issues (some may be just personal preference so take as you 
like.) Maybe too early in the game for fine detail fixes but I've 
noticed them so may as well feed back.

I've got other more detailed comments which I'm working through and will 
send separately.


Section 1 para 3

has/have

-   The ensuing years has shown that it is important for RADIUS to remove
+   The ensuing years have shown that it is important for RADIUS to remove


List of changes (para 5) - inconsistencies. Suggest either 1) each
bullet point is a sentence with capital letter and full stop, or
2) they are one continuous sentence, each starting with lowercase
and ending in a semicolon, except the last. The former probably
works better here.

e.g.

comma to full stop

-   *  ALPN is used for negotiation of this extension,
+   *  ALPN is used for negotiation of this extension.

above plus capital

-   *  all uses of the RADIUS shared secret have been removed,
+   *  All uses of the RADIUS shared secret have been removed.

Suggest removing comma before and in most cases, e.g.

-   *  The Identifier field is no longer used, and has been replaced by
-      the Token field,
+   *  The Identifier field is no longer used as it has been replaced by
+      the Token field.

and

     *  The Message-Authenticator attribute ([RFC3579] Section 3.2) is not
-      sent in any packet, and if received is ignored,
+      sent in any packet. If received it is ignored.


Change to RFC crazy "string" terminology.

-      "octets" ([RFC8044] Section 3.5), without the previous MD5-based
+      "string" ([RFC8044] Section 3.5), without the previous MD5-based


No comma needed.

-      obfuscation.  This obfuscation is no longer necessary, as the data
+      obfuscation.  This obfuscation is no longer necessary as the data
        is secured and kept private through the use of TLS.


Similar comments in the second list - sentences probably make more
sense than ending in commas (or semicolons), especially as one
point is multiple sentences anyway.

e.g.

-   *  the RADIUS packet header is the same size, and the Code and Length
+   *  The RADIUS packet header is the same size, and the Code and Length

-      as before,
+      as before.


Connection"s"

-      server connection), it does not impact any other connection used
+      server connection), it does not impact any other connections used


First paragraph after second list

Fix comma / full stop

     A major benefit of this extensions is that a home server which
     implements it can also choose to also implement full FIPS-140
-   compliance, That is, a home server can remove all uses of MD4 and
+   compliance. That is, a home server can remove all uses of MD4 and


Comma-separated list, rather than A or B or C.

-   MD5.  In that case, however, the home server will not support CHAP or
-   MS-CHAP, or any authentication method which uses MD4 or MD5.  We note
+   MD5.  In that case, however, the home server will not support CHAP,
+   MS-CHAP, or any other authentication method which uses MD4 or MD5. 
We note


Two paragraphs further down, suggest slight rewrite to avoid doing
"this specification. This specification"

     We reiterate that the decision to support (or not) any authentication
     method is entirely site local, and is not a requirement of this
-   specification.  This specification does not not modify the content or
-   meaning of any RADIUS attribute other than Message-Authenticator (and
-   similar attributes), and the only change to the Message-Authenticator
+   specification. The contents or meaning of any RADIUS attribute, other
+   than Message-Authenticator (and similar attributes, see below), are not
+   modified. The only change to the Message-Authenticator
     attribute is that is no longer used.


Section 2

Consistency - full stops on some not others:

     *  ALPN

-      Application-Layer Protocol Negotiation, as defined in [RFC7301]
+      Application-Layer Protocol Negotiation, as defined in [RFC7301].

     *  RADIUS/TCP

-      RADIUS over the Transmission Control Protocol [RFC6613]
+      RADIUS over the Transmission Control Protocol [RFC6613].

     *  RADIUS/TLS

-      RADIUS over the Transport Layer Security protocol [RFC6614]
+      RADIUS over the Transport Layer Security protocol [RFC6614].

     *  RADIUS/DTLS

        RADIUS over the Datagram Transport Layer Security protocol
-         [RFC7360]
+         [RFC7360].

     *  TLS

-      the Transport Layer Security protocol.  Generally when we refer
+      The Transport Layer Security protocol.  Generally, when we refer
           to TLS in this document, we are referring interchangeably to
           TLS or DTLS transport.

Section 4

        "radius/1.1"

-         The protocol defined by specification.
+         The protocol defined by this specification.

Section 4.2


-      The value "RADIUS-1.1" flag is used by the client to determine
+      The value of the "RADIUS-1.1" configuration flag is used by the 
client to determine
        what to send:

-         forbid - no ALPN
+         forbid - ALPN is not used


Section 4.4

Use [link] as elsewhere

-      When session resumption or session tickets (RFC5077) are used, the
+      When session resumption or session tickets [RFC5077] are used, the


Section 5.1

Comma list not A and B and C

-   different meaning.  The Identifier and the Request Authenticator and
+   different meaning.  The Identifier, Request Authenticator and
     Response Authenticator fields are no longer used.  Any operations


In the list of fields:

Not "definition in RADIUS" - maybe "unchanged from the previous
RADIUS specification", or just "of". Or (see other e-mail) "is unchanged 
from standard RADIUS" if "standard RADIUS" is defined in the terminology 
section.

        The meaning of the Code field is unchanged from the previous
-      definition in RADIUS.
+      definition of RADIUS.

        The meaning of the Length field is unchanged from the previous
-      definition in RADIUS.
+      definition of RADIUS.


Section 5.2.1 para 4

Comma

     from a 32-bit counter which is unique to each connection.  Such a
     counter SHOULD be initialized to a random value, taken from a random
-   number generator whenever a new connection is opened.  The counter
+   number generator, whenever a new connection is opened.  The counter


Section 5.2.2 para 2

Move comma

     Accounting-Request.  This overlap requires that RADIUS clients and
-   servers, track the Identifier field not only on a per-connection
+   servers track the Identifier field, not only on a per-connection
     basis, but also on a per-packet type basis.  This behavior adds
     complexity to implementations.


Section 6.1 para 1

Missing full stop

-   observer
+   observer.


Para 2

If they are obfuscated then they have already been obfuscated so
they can't not be obfuscated.

-   Attributes which are obfuscated with MD5 no longer have the
+   Attributes defined as being obfuscated with MD5 no longer have the
     obfuscation step applied when RADIUSv11 is used.  Instead, those


Para 3 - Make it a bit more concrete

-   We understand that there is often concern in RADIUS that passwords
+   There are often concerns where RADIUS is used that passwords
     are sent "in cleartext" across the network.  This allegation was


Para 5

Remove extraneous space

-   These others ways to mitigate these risks .  One is by ensuring that
+   These others ways to mitigate these risks.  One is by ensuring that


Section 6.1.1

Para 1 - Incorrect ref

     The User-Password attribute ([RFC2865] Section 5.2) MUST be encoded
     the same as any other attribute of data type 'string' ([RFC8044]
-   Section 3.4).
+   Section 3.5).


Para 3 - Incorrect ref

     The contents of the User-Password attribute do not have to printable
     text, or UTF-8 data as per the definition of the 'text' data type in
-   [RFC8044] Section 3.5.
+   [RFC8044] Section 3.4.


Section 6.1.2

Possible modification just to make the text flow better?

     use a Request Authenticator field, proxies may receive an Access-
     Request containing a CHAP-Password attribute ([RFC2865] Section 5.2)
     but without a CHAP-Challenge attribute ([RFC2865] Section 5.40).
-   Proxies which forward that CHAP-Password attribute over a RADIUSv11
+   In this case, proxies which forward that CHAP-Password attribute 
over a RADIUSv11
     connection MUST create a CHAP-Challenge attribute in the proxied
     packet using the contents from the Request Authenticator.


Section 6.1.3 para 1

Comma to full stop

-   field or Data-Length fields as described in [RFC2868] Section 3,5,
+   field or Data-Length fields as described in [RFC2868] Section 3.5,


Para 2 - Incorrect ref

     data type here, even though the attribute is no longer obfuscated.
     The contents of the Tunnel-Password attribute do not have to
     printable text, or UTF-8 data as per the definition of the 'text'
-   data type in [RFC8044] Section 3.5.
+   data type in [RFC8044] Section 3.4.


Section 6.2 para 2

Remove comma for consistency with the rest of the document

     If the Message-Authenticator attribute is received over a RADIUSv11
     connection, the attribute MUST be silently discarded, or treated an
-   as "invalid attribute", as defined in [RFC6929], Section 2.8.  That
+   as "invalid attribute", as defined in [RFC6929] Section 2.8.  That


Section 7.1 para 2

Fix typos and full stop

     The rational for reserving one value of the Identifier field was the
     limited number of Identifiers available (256), and the overlap in
     Identifiers between Access-Request packets and Status-Server
-   packers..  If all 256 Identifier values had been used to send Access-
+   packets.  If all 256 Identifier values had been used to send Access-
     Request packets, there would be no Identifier value available for
-   sending a Status-Sercer Packet.
+   sending a Status-Server Packet.


Para 3

Avoid using 'which' twice in one sentence

     special meaning.  The edge condition is that there are 2^32
     outstanding packets on one connection with no new Token value
-   available for Status-Server.  In which case there are other issues
-   which are more serious, such allowing billions of packets to be
+   available for Status-Server.  In this case there are other more serious
+   issues, such allowing billions of packets to be
     oustanding.  The safest way forward is likely to just close the
     connection.


Section 7.3 para 4

Typo

-   All crypto-agility needed or use by this specification is implemented
+   All crypto-agility needed or used by this specification is implemented


Section 7.4 para 2

Fix brackets by adding comma
Change "octets" to "string"

     how those new attributes are transported in RADIUSv11.  Since
     RADIUSv11 does not use MD5, any obfuscated attributes will by
-   definition be transported as their underlying data type ("text"
+   definition be transported as their underlying data type, "text"
-   ([RFC8044] Section 3.4) or "octets" ([RFC8044] Section 3.5).
+   ([RFC8044] Section 3.4) or "string" ([RFC8044] Section 3.5).


Section 11 - typo

-   IANA is request to update the "TLS Application-Layer Protocol
+   IANA is requested to update the "TLS Application-Layer Protocol
     Negotiation (ALPN) Protocol IDs" registry with one new entry:


-- 
Matthew