Re: [radext] Fwd: New Version Notification for draft-dekok-radext-radiusv11-03.txt

[Alexander Clouter <[e-mail]>]

On Mon, 3 Apr 2023, at 16:35, Alan DeKok wrote:
>   I've updated the document based on feedback from the meeting last week.
> 
>   At this point, I think the content is pretty close to being done
> 
>> Name: draft-dekok-radext-radiusv11
>> Revision: 03
>> Title: RADIUS Version 1.1
>> Document date: 2023-04-03
>> Group: Individual Submission
>> Pages: 21
>> URL:            https://www.ietf.org/archive/id/draft-dekok-radext-radiusv11-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-radiusv11/
>> Html:           https://www.ietf.org/archive/id/draft-dekok-radext-radiusv11-03.html
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-radext-radiusv11
>> Diff:           https://author-tools.ietf.org/iddiff?url2=draft-dekok-radext-radiusv11-03

The links at the top for point to 'rfcRFC...' for some reason:

Updates: RFC6613 <https://www.rfc-editor.org/rfc/rfcRFC6613>, RFC7360 <https://www.rfc-editor.org/rfc/rfcRFC7360> (if approved)

Typos (well ones aspell found):

 * s/extenion/extension/g - should catch the same plural typos
 * s/enitrely/entirely/g
 * s/interchangably/interchangeably/g
 * s/protcol/protocol/g
 * s/administative/administrative/g
 * s/ bave / have /g

For section 5.2, I would find it helpful to see the whole RADIUS packet (you have shown 80% of it already anyway!):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Token                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Reserved                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

As the first thing I think is "okay, what do we know do with the Identifier field" I think it may even deserve its own section. As it is the recommendations for receiving and sending is only described in the receiving section (5.2.2). Alternatively, move the 'recommend it is set to zero' to the sending section? I suspect breaking it out will make it easier to read/follow than blending it in with the Token field section.

On a related note. Has anyone thought of a situation where an implementation would need Identifier to continue to function? I know the backwards compatibility was aimed to reduce code churn but I suspect if Identifier was also made reserved, the additional work on top of supporting the removal of Authenticator and switching tracks to from RADIUS v1.0 and RADIUS v1.1 this would require an additional 1% effort? Suggesting it now as I see an opportunity to reclaim an otherwise unused field in a manner that I cannot see having an impact...something that we may not be able to do later.

Section 6.1, Obfuscated Attributes,

> As a result, any claims that passwords are sent "in the clear" are false.

I completely agree with the statement and the reasoning backing it, an argument I have used too.

There is another reason for the push back, there is a concern about the transmitting of the credential (User-Password) to the 'wrong' end system, or passing through a hostile hop.

Of course we can (and should) retort with "well if you are not going to verify the certs of your peers and/or peer with anything that rocks on up to your door then you are going to have a Bad Day(tm)".

I do think the wording could reflect on more that as the *method* of transmission and the *risks* involved are identical to each time you log into a website or fetch your email.

So maybe something like:

"For the unsure reader the use of TLS here to transmit your credentials is the same mechanism used with matching risks each time you log into a website, send and receive email, etc. As a result, any claims that passwords are sent "in the clear" are irrelevant."

Not completely happy with that wording, but it lands it closer to where I think it should be.

Section 6.2, Message-Authenticator

On the topic of 'invalid' attributes, RFC6929, section 2.8 says "if you are a proxy, thou shalt embrace the brokenness and proxy onward..." whilst this section causes a bit of a grey area when you are a proxy recommending instead that you discard the attribute.

I suggest stating "Message-Authenticator is now a non-special attribute, ignore when you have the role as the server or client, and forward verbatim when you are the proxy".

At some stage in the future, someone may want to repurpose it as some sort of end-to-end authenticator to verify the proxies in between have behaved; similar to a DNS TSIG RR.

Cheers