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@ietf.org https://www.ietf.org/mailman/listinfo/ietf