Comments on draft-ietf-radext-radsec-02 for WGLC

["Joseph Salowey (jsalowey)" <jsalowey@cisco.com>]

Here are some working group last call comments on RADSEC:

1.  How is backward compatibility/forward migration of RADSEC handled?
Operational recommendations in this area should be discussed.   The
potential for rollback attacks should also be covered in the security
considerations section.  

2.  I think the certificate handling and authorization section needs to
be more specific for supporting mandatory to implement options.
Currently, the document implicitly requires trust root based
authorization where all certs issued by a given trust root are
authorized.  Some more specific rules are discussed in an informative
section.  I believe some of this needs to be normative and more specific
in order to have interoperable implementations.  This should also be
discussed in the security considerations. 

3.  I'm not sure I understand the choice of ciphersuites.

Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
much preferable to use AES or 3DES? 

4.  The document should state that the fixed string "radsec" shared
secret MUST NOT be used when TLS is not available.  

5. The terms "dynamic peer resolution" and "dynamic peer discovery" are
used in the document and not clearly defined.  

6. Would RADSEC benefit from a mechanism that did not require a PKI?
This could be achieved by specifying a certificate fingerprint or PSK
mode of operation.  

Cheers,

Joe

--
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/>