Subject: [eap] Issue 133: IESG comments on RFC 2869bis

From: [email-masked] (Bernard Aboba)
Date: Thu, 15 May 2003 11:02:12 -0700 (PDT)

Submitter name: Russ Housley
Submitter email address: [email-masked]
Date first submitted: May 15, 2003
Reference:
Document: RFC2869bis-21
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
 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.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 15 May 2003 23:12:57 +0300

> should not be split between these two paragraphs.

I agree.

> "Initiate IPsec, from me to any destination port UDP 1812". This

Maybe "... client is to require IPsec from this node to any
destination port UDP 182. This ..."

We don't appear to have any standard language for
expressing IPsec policies in text like this. Also,
"initiate" sounds like it is an IKE-only construct.

> IPsec-Capable-RADIUS-Server, destination port UDP 1812".

Maybe: ... will be needed: IPsec is reqquired from this node to any of
the IPsec capable RADIUS servers on destination port UDP 1812.

--Jari