[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 224: Comments
Issue 224: Comments
Submitter name: Jouni Malinen
Submitter email address: jkm@devicescape.com
Date first submitted: January 8, 2007
Reference:
Document: RADIUS WLAN
Comment type: T
Priority: S
Section: 2.1, 2.2, 2.3, 2.7
Rationale/Explanation of issue:
2.1 and 2.3
I think I understood what Allowed-SSID and Allowed-Called-Station-ID
attributes are defined for. However, the way I interpret the current
text would make these attributes more or less useless..
NAS is required to silently discard these attributes if the specified
SSID/BSSID does not match with their own configuration. If all the
allowed values are silently discarded, the Access-Accept message is
processed without any Allowed-SSID or Allowed-Called-Station-ID
attributes. I would interpret that to mean that there is no
restriction on SSID or BSSID.. In other words, there would be no way
for the AS to specify this restriction in a way that NAS would act on
it. Should there be text saying that if one or more Allowed-SSID (and
similarly for Allowed-Called-Station-ID) attributes were present, the
client would not be allowed to use the NAS if none of them
matched. For this to work, the attributes cannot be silently ignored.
2.2 SSID
Isn't RFC 3580 already defining a mechanism for including SSID in
Called-Station-Id? Why add a duplicated attribute for delivering this?
RFC 3580 marks the SSID as "SHOULD" and this new attribute is only
"MAY".
2.3 Allowed-Called-Station-ID
typo: this should be -Id, not -ID (both Allowed-Called-Station-Id and
Called-Station-Id)
The requirement of not including SSID (MUST NOT) sounds a bit odd here
taken into account that RFC 3580 has "where the SSID is known, it
SHOULD be appended to the Access Point MAC address" in description of
Called-Station-Id. This is at least confusing, if not
conflicting..
How would a NAS determine whether a Called-Station-Id (which includes an
SSID) is allowed or not, if the set of Allowed-Called-Station-Id
attributes do not include SSID? Is the NAS supposed to strip SSID from
the Called-Station-Id attribute before comparing it to the
Allowed-Called-Station-Id attribute(s)?
Is the goal here to also remove SSID from Called-Station-Id (which
would explain the new SSID attribute)? If yes, that should be stated
explicitly by modifying Called-Station-Id definition of RFC 3580. If
not, Allowed-Called-Station-Id should also include SSID or at least
should have instructions on how the NAS is to compare these two
attributes that have conflicting definition as far as inclusion of SSID
is concerned.
2.7 Mobility-Domain-Id
This attribute is recommended to use UTF-8 encoding. However, 802.11r
defines MDID as a 48-bit value that looks very much like a MAC
address. There is not much point in trying to use UTF-8 for that. In
order to avoid confusion, I would suggest removing the comment about
UTF-8 here. I would expect that this attribute would be using
"undistinguished octets" with 6 octets and not an ASCII hexdump of
this value.
[IEEE-802.11r]
Refering 802.11r/D1.2 does not look very good.. At minimum, this
should be marked as "Work in Progress" like IETF drafts are refered to
and this should also be updated to the latest draft version.
[KEYFRAME]
This should also be refered as "Work in Progress" unless keyframe draft
is published as an RFC before RADEXT WLAN.
-----------------
> Should there be text saying that if one or more Allowed-SSID (and
> similarly for Allowed-Called-Station-ID) attributes were present, the
> client would not be allowed to use the NAS if none of them
> matched. For this to work, the attributes cannot be silently ignored.
That would make sense for implementations of the specification. However,
legacy implementations may well ignore these (and other) attributes they
do not understand. So it's probably a good idea to put in a warning
saying that the Allowed-SSID and Allowed-Called-Station-Id attributes
should only be sent to authenticators known to support them.
If the authenticator does not support them, the attributes will be
ignored, so no harm there as far as I can tell. However, what I would
like to see added is a clarification for the case where these attributes
are supported, but none of the included attributes actually match with
the current configuration of the NAS. At least as far as
Allowed-Called-Station-Id is concerned, I don't think the attributes
should be silently ignored in such a case.
For example, with 802.11r, the initial association could get a set of
Allowed-Called-Station-Id attributes. R0KH would need to store the full
set of attributes, including the addresses for foreign devices, with the
PMK-R0 SA and then deliver these to R1KHs in order to allow them to do
this kind of filtering on allowed Called-Station-Id addresses. Same
would apply for opportunistic key caching with 802.11i.
"If the Called-Stationd Id included in the Allowed-Called-Station-Id
attribute does not describe a layer 2 endpoint of the NAS, the attribute
is silently discarded." seems to prevent the kind of use I described
above.
> 2.2 SSID
Yes, RFC 3580 does enable the SSID to be placed in the Called-Station-Id.
Quite a few implementations do this, but others seem to prefer sending this
in a separate (vendor specific) attribute. So the question was whether
there is enough interest in standardizing that alternative.
OK. I just implemented this based on RFC 3580 and haven't looked into
other implementations. If there are indeed number of implementations
that use VSA for this and the vendors would be interested in replacing
those with this new attribute, this sounds fine.
> How would a NAS determine whether a Called-Station-Id (which includes an
> SSID) is allowed or not, if the set of Allowed-Called-Station-Id
> attributes do not include SSID? Is the NAS supposed to strip SSID from
> the Called-Station-Id attribute before comparing it to the
> Allowed-Called-Station-Id attribute(s)?
OK. I hadn't thought of the potential need to restrict use of certain
BSSIDs with certain SSIDs, but it make sense. In that case it probably
makes sense to enable an Allowed-Called-Station-Id attribute to contain an
SSID. And if this is done, there may be a need for only one attribute.
That would be one case, but more importantly, there needs to be a clear
description on how the comparison is to be done if this is done at the
RADIUS attribute level. If NAS is comparing the exact contents of
Allowed-Called-Station-Id and Called-Station-Id, there could be
mismatches based on whether the SSID is included in none/one/both of
them. If the comparison is done outside the "RADIUS context" by storing
just the BSSID list from the Allowed-Called-Station-Id attributes, this
is less likely to cause problems.
One more comment: It might be useful to standardize on a mechanism to
allow NAS to indicate that the authentication is for 802.11i
pre-authentication case. I have not seen this described anywhere and
don't know how other implementations are taking care of this (if they
are). I ended up using "IEEE 802.11i Pre-Authentication" as the
Connect-Info attribure for this, but this is not really defined
anywhere. Anyway, I don't see anything in either RFC 2869 or RFC 3580
conflicting with this kind of use.
Somewhat related question would be whether there is any need for
indicating the difference between IEEE 802.11i and 802.11r in
Access-Request. There has been some discussion on this in TGr when the
topic of pre-authentication for 802.11r came up and there seemed to be
consensus on the same MSK/PMK not being allowed for both uses, so this
would need to be prevented at the authenticator. AS does not really need
to know about this, but it could be useful information if there is any
desire to describe different behavior for 802.11r and 802.11i cases.
--
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/>