[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 120: Message-Authenticator
Issue 120: Message-Authenticator
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: T
Priority: S
Section: 8
Rationale/Explanation of issue:
The document appears to mandate use of Message-Authenticator in all RADIUS
usage.
Section 8
Change:
"8. Security Considerations
The RADIUS extensions described in this document make RADIUS a
transport protocol for the data that is required to perform a digest
calculation. It adds the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) to those of RADIUS (see [RFC2865], Section 8 or
Section 4 of [RFC3579]).
If an attacker gains control over a RADIUS client or RADIUS proxy, he
can perform man-in-the-middle attacks even if the paths between A, B
and B, C (Figure 2) have been secured with TLS or IPsec.
The RADIUS server MUST check the Digest-Realm attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.
RADIUS clients implementing the extension described in this document
authenticate layer 3 requests received from the Internet. This is in
contrast to the original use of RADIUS, where layer 2 sessions are
authenticated. In layer 2 access networks, attackers can usually
tracked down more easily.
An attacker could try to overload the RADIUS infrastructure by
excessively sending HTTP-style requests. To make simple denial of
service attacks more difficult, the nonce issuer (RADIUS client or
server) MUST check if it has generated the nonce received from an
HTTP-style client. This SHOULD be done statelessly. For example, a
nonce could consist of a cryptographically random part and some kind
of signature of the RADIUS client, as described in [RFC2617], section
3.2.1.
RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
attributes in Access-Challenge messages. A man in the middle can
modify or remove those attributes in a bidding down attack. In this
case, the RADIUS client would use a weaker authentication scheme than
intended. RfC 3579 [RFC3579], section 3.2 describes a Message-
Authenticator attribute which MUST be used to improve the integrity
protection of RADIUS messages. The RADIUS server can use this
attribute to verify the identity of the RADIUS client.
The Digest-HA1 attribute contains no random components if the
algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
attacks easier and can be used for replay attacks.
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. Instead of TLS, IPsec can be used,
too. TLS or IPsec secure the connection while Digest Authentication
authenticates the user. The RADIUS transaction can be regarded as
one leg on the path between the HTTP-style client and the HTTP-style
server. To prevent the RADIUS transaction from being the weakest hop
on the path, a RADIUS client receiving an HTTP-style request via TLS
or IPsec MUST use an equally secure connection to the RADIUS server.
There are two ways to achieve this:
o the RADIUS client rejects HTTP-style requests received over TLS or
IPsec
o the operator of the RADIUS client takes actions to ensure that
RADIUS traffic is exclusively sent and received using IPsec.
When using IPsec, it MUST be set up as described [RFC3579] section
4.2."
To:
"8. Security Considerations
The RADIUS extensions described in this document enable RADIUS to
transport the data that required to perform a digest calculation.
As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
[RFC2617], section 4) in addition to RADIUS security vulnerabilities
described in [RFC2865] Section 8 and [RFC3579] Section 4.
An attacker compromising a RADIUS client or proxy can carry out
man-in-the-middle attacks even if the paths between A, B
and B, C (Figure 2) have been secured with TLS or IPsec.
The RADIUS server MUST check the Digest-Realm attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.
RADIUS clients implementing the extension described in this document
may authenticate HTTP-style requests received over the Internet. As
compared with use of RADIUS to authenticate link layer network
access, an attacker may find it easier to cover their tracks in
such a scenario.
An attacker can attempt a denial of service attack on one or
more RADIUS servers by sending a large number of HTTP-style
requests. To make simple denial of service attacks more difficult,
the nonce issuer (RADIUS client or server) MUST check if it has
generated the nonce received from an HTTP-style client.
This SHOULD be done statelessly. For example, a nonce could
consist of a cryptographically random part and some kind
of signature provided by the RADIUS client, as described in [RFC2617],
section
3.2.1.
RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
attributes in Access-Challenge messages. A man in the middle can
modify or remove those attributes in a bidding down attack, causing
the RADIUS client to use a weaker authentication scheme than
intended.
The Message-Authenticator attribute, described in [RFC3579]
section 3.2 MUST be included in Access-Request, Access-Challenge,
Access-Reject and Access-Accept messages that contain attributes
described in this specificaiton.
The Digest-HA1 attribute contains no random components if the
algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
attacks easier and enables replay attacks.
HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. Instead of TLS, IPsec can be used,
too. TLS or IPsec secure the connection while Digest Authentication
authenticates the user. The RADIUS transaction can be regarded as
one leg on the path between the HTTP-style client and the HTTP-style
server. To prevent RADIUS from representing the weak link, a
RADIUS client receiving an HTTP-style request via TLS
or IPsec MUST use an equally secure connection to the RADIUS server.
There are two ways to achieve this:
o the RADIUS client may reject HTTP-style requests received over TLS or
IPsec
o the RADIUS client require that traffic be sent and recieved over
IPsec.
RADIUS over IPsec, if used, MUST conform to the requirements
described in [RFC3579] section 4.2."
--
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/>