Re: AD review of draft-zorn-radius-pkmv1-04.txt

[Alan DeKok <aland@deployingradius.com>]

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.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>