Glen Zorn wrote:
No. There _are_ implementations as I rather clearly stated at the meeting
in SF, using the Experimental attribute space.
So the implementations have to be updated to use the IANA code points,
independent of them possibly using the extended attributes format.
Given that there are already multiple interoperable implementations and all
of the attributes are security related, I see no pressing need to make
people change running code to satisfy your personal preferences.
The contents of the design guidelines document reflect the WG consensus
after years of effort and review. It by *no* means reflects solely my
personal preference, as seems to be implied here.
Sorry if
these attributes were designed to be easy to implement for people writing
PKM code, rather than RADIUS code.
There's no need to follow the RADIUS design guidelines, because the
attributes refer to data that interacts with non-RADIUS systems...
What value, then, is in the design guidelines, WG consensus, or IETF
review? Can we just over-ride them willy-nilly because a vendor has an
implementation of a spec?
In Section 3.4. PKM-Cryptosuite-List, can the attribute be longer
than 253 bytes?
No. There are exactly
This response seems to have been cut off.
Would it be sufficient to require that the Access-Accept contains a
Message-Authenticator for integrity protection?
If you consider MD5 to be "strong integrity protection".
It appears to be good enough for the rest of RADIUS, at least until
the TLS-based methods are standardized.
MPPE-Send-Key is broken; I don't see the value in requiring the use of
broken technology. There are much better ways to encrypt attributes for
transmission, in which (once again) the radext WG has shown near zero
interest. Maybe it should be a cisco VSA?
If it's documented, sure.
Alan DeKok.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf