[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 101: WG Last Call Review
I deleted some stuff to focus on the three items:
>
> Egress-VLANID doesn't necessarily need any special code in
> the management interface if it supports entering hexadecimal
> numbers (e.g. tagged VID 6 could be entered as 0x01000006).
>
> And VLAN-Name attribute already uses 8 bits to represent
> these two values; changing that from 0x01/0x02 to, say,
> 0x31/0x32 wouldn't use anything more... (and would not
> prevent us from defining value values later any more than
> 0x01/0x02 does)
Ok. I'd still like to keep the attributes as similar as possible, so I
propose we also change the value of tagged and untagged to 0x31 and 0x32
in the Egress-VLANID attribute as well. Thus, your example above of
tagged VID 6 would be entered as 0x31000006.
>
> I don't think significant changes are needed; basically, only
> a couple of small changes would clarify the document significantly.
> The most important ones would IMHO be:
>
> - combining the two figures in 3.1
>
> - fixing the figure in 4.1 (explicitly show that the attribute
> contains both a 64-bit counter and a string according to
> NAS-Filter-Rule; calling the counter a part of the string
> is misleading, since it doesn't even consist of printable
> characters...)
>
> - Add figure to section 3.3 (explicitly showing that the
> attribute contains two different items)
>
Ok, this isn't too bad, we can make these specific changes.
>
> There's no need to imagine all things that could happen if a
> RADIUS server is compromised, but it is IMHO necessary to at
> least briefly discuss how implementing _this_ document
> changes the existing situation.
>
> Maybe something like this:
>
I'm assuming the text you provided would be in addition to what is
already there? Below, I've merged your text into the existing text as
an entirely new Security section.
How about the following:
7. Security Considerations
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in IEEE 802.1X-
enabled networks, it is vulnerable to all of the threats that are
present in other RADIUS applications. For a discussion of these
threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576],
[RFC3579], and [RFC3580].
Vulnerabilities include:
Packet modification or forgery
Dictionary attacks
Known plaintext attacks
Compromised RADIUS Server or Proxy
7.1. Packet Modification or Forgery
As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS
packets MUST be authenticated and integrity protected. In
addition, as described in [RFC3579], Section 4.2:
To address the security vulnerabilities of RADIUS/EAP,
implementations of this specification SHOULD support IPsec
[RFC2401] along with IKE [RFC2409] for key management. IPsec
ESP [RFC2406] with non-null transform SHOULD be supported, and
IPsec ESP with a non-null encryption transform and
authentication support SHOULD be used to provide per-packet
confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used for key management.
7.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret
is vulnerable to offline dictionary attack, based on capture of
the Response Authenticator or Message-Authenticator attribute. In
order to decrease the level of vulnerability, [RFC2865], Section 3
recommends:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least
16 octets.
In addition, the risk of an offline dictionary attack can be
further mitigated by employing IPsec ESP with non-null
transform in order to encrypt the RADIUS conversation, as
described in [RFC3579], Section 4.2.
7.3. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the
RADIUS User-Password attribute is not used to carry hidden user
passwords. The hiding mechanism utilizes MD5, defined in
[RFC1321], in order to generate a key stream based on the RADIUS
shared secret and the Request Authenticator. Where PAP is in
use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS
conversations corresponding to a PAP authentication attempt using
a known password. Since the User-Password is known, the key stream
corresponding to a given Request Authenticator can be determined
and stored.
The vulnerability is described in detail in [RFC3579], Section
4.3.4. Even though IEEE 802.1X Authenticators do not support PAP
authentication, a security vulnerability can still exist where the
same RADIUS shared secret is used for hiding User-Password as well
as other attributes. This can occur, for example, if the same
RADIUS proxy handles authentication requests for both IEEE 802.1X
(which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-
Recv-Key attributes) and GPRS (which may hide the User-Password
attribute).
The threat can be mitigated by protecting RADIUS with IPsec ESP
with non-null transform, as described in [RFC3579], Section 4.2.
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
7.4 Compromised RADIUS Server or Proxy
This documents specifies new attributes that can be included
in existing RADIUS messages. These messages are protected
using existing security mechanisms; see [RFC2865] and
[RFC3576] for a more detailed description and related security
considerations.
The security mechanisms in [RFC2865] and [RFC3576] are
primarily concerned with an outside attacker who modifies
messages in transit or inserts new messages. They do not
prevent an authorized RADIUS server or proxy from inserting
attributes with a malicious purpose in message it sends.
An attacker who compromises an authorized RADIUS server or
proxy can use the attributes defined in this document to
influence the behavior of the NAS in ways that previously may
not have been possible. For example, modifications to the
VLAN-related attributes may cause the NAS to permit access to
other VLANs that were intended. To give another example,
inserting suitable redirection rules to the NAS-Filter-Rule
attribute may allow the attacker to eavesdrop or modify
packets sent by a legitimate client.
In general, the NAS cannot know whether the attribute values
it receives from an authenticated and authorized server are
well-intentioned or malicious, and thus it is not possible to
completely protect against attacks by compromised nodes. In
some cases, the extent of the possible attacks can be limited
by performing more fine-grained authorization checks at the NAS.
For instance, a NAS could be configured to accept only certain
VLAN IDs from a certain RADIUS server/proxy, or not to accept
any redirection rules if it is known they are not used in
this environment.
--
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/>