[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More comments on draft-ietf-radext-fixes-06.txt
Expires: February 27, 2007
Shouldn't this be 2008?
In contrast, Access-Requests which are intended to perform
authorization checks MUST contain a State attribute in order to tie
the authorization check to a previous authentication session. This
last requirement often means that an Access-Accept needs to contain a
State attribute, which is then used in a later Access-Request that
performs authorization checks.
[BA] The MUST here seems to be contradicted by text below relating to
Call Check. My advice is to i ntegrate the last sentence into one of the
paragraphs below and delete the first sentence.
Access-Request packets that contain a Service-Type attribute with
value Authorize Only (17) MUST contain a State attribute. Access-
Request packets that contain a Service-Type attribute with value Call
Check (10) SHOULD NOT contain a State attribute. Any other Access-
Request packet that performs authorization checks MUST contain a
[BA] This paragraph seems to state the requirement more clearly.
The standard use case for Call-Check is pre-screening authentication
based solely on the end-point identifier information, such as phone
number or MAC address in Calling-Station-ID and optionally Called-
Station-ID. In that use case there is no source of the State
attribute in the NAS.
[BA] Suggest changing to "In this use case, the NAS has no way to obtain
a State Attribute suitable for inclusion in an Access-Request."
Other, non-standard, uses of Call-Check may
require or permit the use of a State Attribute, but are beyond the
scope of this document.
Implementing Call Check functionality via requests where the User-
Name and User-Password contain the same information (e.g. MAC
address) is NOT RECOMMENDED.
[BA] Suggest rewriting to: "In an Access-Request with a Service-Type
Attribute with value "Call Check", it is NOT RECOMMENDED for the User-Name
and User-Password attributes to contain the same values (e.g. a MAC
This practice gives an attacker both
the clear-text and cipher-text of the User-Password field, which
permits many additional attacks on the security of the RADIUS
protocol. For example, if the Request Authenticator does not satisfy
the [RFC2865] requirements on global and temporal uniqueness, the
practice described above may lead to the compromise of the User-
Password attribute in other Access-Requests for unrelated users.
Access to the cipher-text also greatly simplifies offline dictionary
attacks, potentially exposing the shared secret, and compromising the
entire RADIUS protocol.
[BA] I think you mean "Access to the cleartext", no? BTW, how does this
simplify offline dictionary attacks? Seems like an attack on the Response
Authenticator or Message-Authenticator attributes remains the weak link.
Any Access-Request packet that performs authorization checks,
including Call Check, MUST contain a Message-Authenticator attribute.
Any response to an Access-Request performing an authorization check
MUST NOT contain confidential information about any user (such as
Tunnel-Password), unless that Access-Request contains a State
attribute. The use of State here permits the authorization check to
be tied to an earlier user authentication. In that case, the server
MAY respond to the NAS with confidential information about that user.
The server MUST NOT respond to that authorization check with
confidential information about any other user.
[BA] Given that Call Check is defined in RFC 2865, which does not require
Message-Authenticator this appears to be imposing requirements on legacy
implementations. Today Call Check can return any attribute that is
configured; I am not sure how this would modify that.
Rather than talking about "confidential information" (which is somewhat
vague), it probably makes more sense to recommend how a RADIUS server
should response to an Access-Request implementing an authorization check
that does not include a State attribute. Since earlier it is stated
that an "Authorize Only" Access-Request MUST contain a State attribute,
it would seem that the RADIUS server should send an Access-Reject, no?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.