radex mailer: quick review #2
Description
Just a review based on scanning it quickly.
-
I don't see a need for a long list of "this attribute isn't used by BLE authenticators". If it's not used, it can be omitted
-
There's no need to re-define what the attributes are.
-
e.g. User-Password is encrypted. Just state what it contains.
-
Called-Station-Id already has a defined format in RFC 3580 section 3.20.
-
Generally just say "This attribute has value X". There's no need for exhaustive lists and re-redefinitions
-
for new attributes, RFC 8044 says we can skip the ASCII art. Just define the name and the data type.
Using extended attributes makes ASCII art more difficult, so less work is better work
-
BLE-Keying-Material is a complex structure. See https://www.rfc-editor.org/rfc/rfc6158#section-3.2.3
If it's possible to just reference another specification for the format, that would be best. i.e. if the RADIUS client/server don't need to decode the fields of this structure, then it should be defined as an opaque blob. That blob can be obtained from something else by the RADIUS server, and sent by the RADIUS client to something else.
If the fields need to be understood by the RADIUS client/server, then it may be better to separate them out into individual attributes.
It's not clear why this attribute requires a Message-Authenticator to be present. The Message-Authenticator is really useful only for Access-Request packets, which otherwise have no signatures. In reply packets like Access-Accept, etc. Message-Authenticator offers little value.
The "Keying Material Data" field should arguably be "protected" with the attribute obfuscation defined for User-Password. It's ugly, but it's what we have.