draft-aboba-radius-rfc2869bis-21

[Russ Housley <housley@vigilsec.com>]

  Why isn't this document on the standards track?

  Section 4.1 says:

    RADIUS/EAP is used in order to provide authentication and authorization
    for network access.  As a result, both the RADIUS and EAP portions of
    the conversation are open to attack.

  Does "open to attack" mean likely target of attack?  If so, please use 
these words.  If not, please clarify.

  Section 4.2 says:

    When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the
    encryption transform, and per-packet authentication, integrity and
    replay protection MUST be used.  A typical IPsec policy for an IPsec-
    capable RADIUS client is "Initiate IPsec, from me to any destination
    port UDP 1812".

    This causes an IPsec SA to be set up by the RADIUS client prior to
    sending RADIUS traffic.  If some RADIUS servers contacted by the client
    do not support IPsec, then a more granular policy will be required:
    "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
    port UDP 1812".

  I agree that DES-CBC should not be used; however, we ought to tell the 
implementors what algorithm ought to be used for 
interoperability.  Further, the text requires integrity protection, but no 
integrity mechanisms are discussed.  Also, the discussion of IPsec policy 
should not be split between these two paragraphs.

  I propose the following:

    When IPsec ESP is used with RADIUS, per-packet authentication,
    integrity and replay protection MUST be used.  AES-CBC SHOULD be
    used as the encryption transform, and HMAC-SHA1-96 SHOULD be used
    as the authentication function.  DES-CBC SHOULD NOT be used as the
    encryption transform.

    A typical IPsec policy for an IPsec-capable RADIUS client is
    "Initiate IPsec, from me to any destination port UDP 1812".  This
    IPsec policy causes an IPsec SA to be set up by the RADIUS client
    prior to sending RADIUS traffic.  If some RADIUS servers contacted
    by the client do not support IPsec, then a more granular policy
    will be required: "Initiate IPsec, from me to
    IPsec-Capable-RADIUS-Server, destination port UDP 1812".

  Later in section 4.2, the text says: "... it is important that trust be 
demonstrated ..."  In this context, "trust" is very ambiguous.  Please 
reword.  I think that the paragraph should discuss "authentication" and 
"authorization."

  Later in section 4.2, change "Certificate Authority (CA)" to 
"Certification Authority (CA)."

  In section 4.3.1, please add an informative reference for ARP.

  In section 4.3.2, please add a pointer to Section 4.2 in the very last 
sentence.

  In section 4.3.8, please change "even where IPsec is utilized for 
transmission layer security" to "even where IPsec is used."

  In section 4.3.9, the text says: "As described in Section 4 ..."  Since 
this text appears in a subsection of section 4 and there is no text 
following the single digit heading, a more precise pointer is appropriate.

  In section 4.3.9, the last paragraph should tell what security services 
are expected from the "wrapping mechanism."  I believe that they are 
confidentiality, integrity, and data origin authentication.