Issue 100: Security Considerations Submitter name: Alan DeKok Submitter email address: aland@ox.org Date first submitted: July 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00524.html Document: IEEE802-00 Comment type: T Priority: S Section: 7.3 Rationale/Explanation of issue:
The last sentence of section 7 has strong new requirements on RADIUS
The last sentence of section 7 is also the last section of the
document, and says:
In addition, the same RADIUS shared secret MUST NOT used for both
IEEE 802.1X authentication and PAP authentication.
It's a little surprising to have a requirement with such a large
impact as the last sentence in the document, with no further
discussion.
This requirement means that it may be impossible for implementations
to call themselves "unconditionally compliant". Since RADIUS servers
cannot control the authentication methods used by a NAS, there is no
way for an implementation to know if a particular shared secret is
used for IEEE 802.1X or PAP authentication.
When a RADIUS server is proxying requests from one or more NASes to
a home server, it may not have a choice about how many shared secrets
it uses. In order to satisfy the MUST in section 7.3, the proxying
server MUST send packets from two different IP addresses. This
configuration may not be possible in many deployments.In addition, 802.1X devices may pass through EAP for user authentication, but also implement device administrator authentication via RADIUS. Implementers should be guided as to how to implement administrator authentication without breaking the security of user authentication. Requested change: 1. Change the MUST to a SHOULD. 2. Add the following suggested text: Implementers are strongly cautioned to treat the preceding SHOULD as a MUST. Issues with the RADIUS protocol prevent the above requirement from being a MUST in all deployments. If the device supports administrator authentication via RADIUS, that authentication MUST NOT use PAP. That is, a device such as an access point that implements IEEE 802.1X authentication MUST NOT send a User-Password attribute in any Access-Request packet. Another authentication method MUST be used, though we do not suggest one here. RADIUS server implementations that proxy both PAP and IEEE 802.1X authentication to another RADIUS server SHOULD use multiple source IP addresses for the proxied packets. Where this configuration is used, the implementation MUST NOT use the same source IP address for both IEEE 802.1X authentication and for PAP authentication. In those deployments, the same RADIUS shared secret MUST NOT used for both IEEE 802.1X authentication and PAP authentication.
[Mauricio Sanchez]
One could say that the cat is out of the bag. Section 7 was taken mostly from existing RFCs, in particular RFC3580. The specific sentence your issue relates to already exists verbatim in RFC3580 section 5.3. My proposal is to change the last sentence in section 7 to: "For IEEE 802.X environments, best practices outlined in [RFC3580] mandate the use of different RADIUS shared secrets for IEEE 802.1X authentication and PAP authentication." An normative reference will also need to be added to RFC3580 in section 8.1.
[Bernard Aboba]
A bit about the intention of the cited sentence in [RFC3580]. Section 5.3 relates to known plaintext attacks against PAP, where the attacker attempts to authenticate to a NAS and then collects the User-Password attribute sent by the RADIUS client, in order to derive the keystream used for attribute hiding. This attack is easy to mount because RFC 2865 does not require that the RADIUS Access-Request be integrity protected. Since the User-Password keystream is a function of the Shared Secret and the Request Authenticator, a user's password should be considered compromised if the Request Authenticator (User-Password) repeats on any NAS utilizing a given RADIUS shared secret. In order to prevent this attack, RFC 2865 requires the Request Authenticator to be globally and temporally unique, but not all NASes satisfy this requirement. For example, a NAS can attempt to satisfy the global uniqueness property by utilizing the IP address in the high order bits of the RA and then utilizing a pseudo-random number in the low order bits. However, not all NAS devices have sufficient entropy to produce high quality pseudo-random numbers. If in addition, the same RADIUS shared secret is used on for more than one NAS, the chance of compromise increases significantly. Once an attacker has compromised user passwords, they can gain access to all media which utilize those credentials, enabling known plaintext attacks on other hidden attributes such as Tunnel-Password and MPPE-Keys. These other hidden attributes cannot be attacked by an unauthenticated attacker because these attributes are only sent in an Access-Accept, which implies a successful authentication. So the attacker must first obtain access to compromised passwords before trying this more difficult attack. However, once this attacks collects sufficient keystream material, if the RA + salt ever repeats on a NAS utilizing a given shared secret, then the EAP MSK or Tunnel-Password is compromised. As a result, Section 5.3 is attempting to discourage the use of PAP and the potential cascading vulnerablities that this can cause. If PAP cannot be deprecated entirely, then it is best if its use is isolated to accounts that have limited access rights. Also, EAP made a conscious decision not to support PAP, so re-introduction of PAP support into EAP is undesirable. If these principles are followed, it possible to limit the use of PAP without forcing a RADIUS proxy to utilize a different IP address for PAP and EAP authentication.
Proposed Resolution: Discuss
Issue 101: WG Last Call Review Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00527.html Document: IEEE802-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
Overall impression: NAS/QoS-Filter-Rule part is quite messy,
other parts are reasonably OK. I'll send my comments about
NAS-Filter-Rule in a separate email.
1) Section 1.1 contains some unnecessary terminology that is not
used anywhere later in the document: "Access Point (AP)",
"Association", "Port Access Entity (PAE)", "Station (STA)"
2) Section 2.2: "If accounting is enabled on the NAS, it MUST
generate an Accounting-Request (Stop) message upon session
termination."
So the NAS must send a Stop message, even though it has not sent
a Start message for this session yet? RFC 2866 seems suggest
that a session always has a Start message before Stop, but does
not seem to outright prohibit sending a stand-alone Stop
message. Is this a common practice, or are there any problems
associated with it?
3) Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that
convention? (but maybe VLANID is more understandable)
4) Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD"
instead of "MUST"? (according to RFC 2119, it would mean there
are valid reasons to send something else in some circumstances?)
(This same issue occurs also in Section 4.2.)
5) Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?
6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF
TEXT" (0x02) control characters to indicate tagged/untagged
might make it unnecessarily difficult to enter this attribute
in a management interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
7) Section 3.3: Probably should have reference to UTF-8? [RFC3629]
8) Section 3.4: "The table, expressed as an 8 octet string, maps
the incoming priority (if one exists - the default is 0) into
one of seven regenerated priorities." If the regenerated
priority is an integer in range 0-7, should that be "eight
regenerated priorities"?
9) A comment about the bit figures in Section 3 and 4.
Currently, all the figures are basically identical: they contain
the RADIUS Type and Length fields, plus one other field
(variably called either "Integer", "String" or "Text").
The contents of this field are then described in English.
I think it would be much more understandable if the figure also
showed the structure. For instance, instead of this (Section 3.1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this would IMHO be more readable:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(zero) | VLANID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Note that I'm not proposing changing the attribute formats at all --
so no changes to any software --, just how they are presented in the
document. And we can keep all the zero padding there if we want...)
10) Section 5: If the semantics of Acct-EAP-Auth-Method are
identical to Diameter EAP (as Section 4.2 claims), then it can
also be included in Access-Accept messages. (Or if it can't,
then the semantics are not identical, and need to be described
in this document.)
11) Section 7: It looks like this security considerations
section was just copied from somewhere without much thought for
how well it actually applies to this document. Most of the text
looks redundant to me; we don't need to describe how to use
IPsec with RADIUS in every document that defines a new RADIUS
attribute.
On the other hand, there's exactly zero discussion about new
threats caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a
malicious or compromised RADIUS server or proxy could do with
these attributes (compared to the situation where NAS does not
support these attributes). At least Egress-VLANID,
Ingress-Filters and NAS-Filter-Rule have some pretty obvious
possibilities for abuse... (and maybe some non-obvious as well)
12) References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.
13) References: Document cites [DiamEAP] and [NASREQ], but
they're not included in the references section. Both are
normative.[Paul Congdon]
Here are some proposed resolutions to Pasi's Issue 101 WG review
comments:
Overall impression: NAS/QoS-Filter-Rule part is quite messy, other parts
are reasonably OK. I'll send my comments about NAS-Filter-Rule in a
separate email.
1) Section 1.1 contains some unnecessary terminology that is not used
anywhere later in the document: "Access Point (AP)", "Association",
"Port Access Entity (PAE)", "Station (STA)"
[pc] - agreed, to be removed.
2) Section 2.2: "If accounting is enabled on the NAS, it MUST generate
an Accounting-Request (Stop) message upon session termination."
So the NAS must send a Stop message, even though it has not sent a Start
message for this session yet? RFC 2866 seems suggest that a session
always has a Start message before Stop, but does not seem to outright
prohibit sending a stand-alone Stop message. Is this a common practice,
or are there any problems associated with it?
[pc] I believe that this should not cause any problem, but to be honest,
we could use some input from others. I'm aware of some implementations
that send a start and then immediately follow with a stop, but this
could be more resource intensive than needed. The stop without a start
would either be ignored by the server or appropriately acknowledge the
termination of the session that didn't start. This could be useful for
diagnostic purposes. I'd love to hear from other Radius vendors as to
whether this would be a problem or not. Again, my assumption is that it
isn't.
3) Section 3.1: 802.1Q does not use the abbreviation "VLANID"
but rather "VID". Should this document also follow that convention?
(but maybe VLANID is more understandable)
[pc] Yes, 802.1Q most often uses VID for VLAN Identifier. It sometimes
uses VLAN ID (with a space). However, RFC 3580 uses VLANID and since
this document is most likely used in conjunction with RFC 3580, I
suggest we just leave VLANID as is.
4) Section 3.1: "Padding bits SHOULD be 0 (zero)." Why "SHOULD"
instead of "MUST"? (according to RFC 2119, it would mean there are valid
reasons to send something else in some circumstances?) (This same issue
occurs also in Section 4.2.)
[pc] This can be changed to MUST. The desired behavior, IMO, is to
require the bits to be set to 0, but not require them to be checked on
receipt. The simple MUST or SHOULD wording doesn't really reflect this,
so it is probably best that we make this a MUST. Agree to change this
SHOULD to a MUST here and in 4.2
5) Section 3.3: If VLAN-Name has basically the same meaning as
Egress-VLANID, IMHO their names should reflect this. Perhaps
"Egress-VLAN-Name"?
[pc] Sure, no objection. Change the name of the VLAN-Name attribute to
Egress-VLAN-Name everywhere in the document.
6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF TEXT"
(0x02) control characters to indicate tagged/untagged might make it
unnecessarily difficult to enter this attribute in a management
interface... maybe something like 0x74/0x75
("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
[pc] We were trying to get Egress-VLANID and (now called)
Egress-VLAN-Name to have as similar a format as possible. While
Egress-VLAN-Name could be made to be an all text type of management
interface, Egress-VLANID can not. The VLANID is a simple 12-bit number
and won't map well to the keyboard input optimization no matter what we
do, so some form of special formatting for the management interface will
be required to support these two attributes. Also, tagged and untagged
are the only flags we need today, but perhaps this field would need to
be extended someday (e.g. 802.1ad support), and using more bits to
represent the two values needed today would seems to be wasteful. I
propose no change here.
7) Section 3.3: Probably should have reference to UTF-8? [RFC3629]
[pc] yes, Add a reference to [RFC3629] here and then a formal reference
in section 8.
8) Section 3.4: "The table, expressed as an 8 octet string, maps the
incoming priority (if one exists - the default is 0) into one of seven
regenerated priorities." If the regenerated priority is an integer in
range 0-7, should that be "eight regenerated priorities"?
[pc] yes, change to "eight regenerated priorities"
9) A comment about the bit figures in Section 3 and 4.
Currently, all the figures are basically identical: they contain the
RADIUS Type and Length fields, plus one other field (variably called
either "Integer", "String" or "Text").
The contents of this field are then described in English.
I think it would be much more understandable if the figure also showed
the structure. For instance, instead of this (Section 3.1),
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this would IMHO be more readable:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | (zero)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(zero) | VLANID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Note that I'm not proposing changing the attribute formats at all -- so
no changes to any software --, just how they are presented in the
document. And we can keep all the zero padding there if we want...)
[pc] To make this clean and follow your recommendation I believe it has
significant structural changes to the document. Most of the attributes
do not have diagrams at all. There would need to be a lot of new ASCII
art added and it would be difficult for string based fields like
NAS-Filter-Rule to accommodate this. If we put all the internal field
names in the base attribute diagram along with Type and Length, it would
seem that we would need to describe each of the other fields
individually rather than indicating how to format the Integer, Text or
String portion. I'd rather keep the bulk of the attribute sections
intact and only provide a diagram describing how to format the Integer,
Text or String porition - as is done in 3.1. We could certainly make
3.2, 3.3 and 3.4 more consistent with 3.1 and add a diagram on how to
format the Integer, Text and/or String component. Would this work?
10) Section 5: If the semantics of Acct-EAP-Auth-Method are identical to
Diameter EAP (as Section 4.2 claims), then it can also be included in
Access-Accept messages. (Or if it can't, then the semantics are not
identical, and need to be described in this document.)
[pc] agreed, but I believe this attribute is going to be removed from
the draft per issue 114.
11) Section 7: It looks like this security considerations section was
just copied from somewhere without much thought for how well it actually
applies to this document. Most of the text looks redundant to me; we
don't need to describe how to use IPsec with RADIUS in every document
that defines a new RADIUS attribute.
On the other hand, there's exactly zero discussion about new threats
caused by the attributes defined in _this_ document.
And to me it looks like there are new attacks that e.g. a malicious or
compromised RADIUS server or proxy could do with these attributes
(compared to the situation where NAS does not support these attributes).
At least Egress-VLANID, Ingress-Filters and NAS-Filter-Rule have some
pretty obvious possibilities for abuse... (and maybe some non-obvious as
well)
[pc] Yes, much of this text was copied from 3580, but short of trying to
imagine all the things that could happen if a RADIUS server is
comprimized, I'm not sure what else to put here. We could puts some
words here about how modified settings of things like Ingress-Filters or
Filter-Rules could change the expected behavior, but the discussion
would not be exhaustive. I thought the point of this section was to
document what the vulnerabilities are, not how they might be used. For
example, the scheme is vulnerable to packet modification attacks, but
we can't document what might happen with every possible modification of
a packet. Please provide some more explanation or examples of what you
are looking for here.
12) References: Both 802.1Q and .1D look normative to me, but
RFC1321 and 802.11i probably are just informative.
[pc] agreed. Swap these reference locations.
13) References: Document cites [DiamEAP] and [NASREQ], but they're not
included in the references section. Both are normative.
[pc] agreed. Add these references.> No, the text was intended as a replacement of what's already there.
>
> The existing text is IMHO unnecessary because it doesn't
> describe any security considerations of _this_ document. I
> don't think we need to repeat what's already said in RFC 2865
> and 3579 in every document that defines a new RADIUS
> attribute: we just need to describe what new security
> considerations this document has (in addition to those
> already adequately described in 2865/3579).
>
I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply. I'd like to at least leave the introductory
paragraph, followed by your text. The security section would then look
as follows:
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], [RFC3162], [RFC3579], and [RFC3580].
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.[Pasi Eronen]
paul.congdon@hp.com wrote:
> [pc] Here are some proposed resolutions to Pasi's Issue 101 WG
> review comments:
I'm happy with most of these proposals; see comments below
for the rest...
> 6) Section 3.3: Using "START OF HEADING" (0x01) and "START OF
> TEXT" (0x02) control characters to indicate tagged/untagged
> might make it unnecessarily difficult to enter this attribute
> in a management interface... maybe something like 0x74/0x75
> ("t"/"u") or 0x31/0x32 ("1"/"2") would be easier?
>
> [pc] We were trying to get Egress-VLANID and (now called)
> Egress-VLAN-Name to have as similar a format as possible.
> While Egress-VLAN-Name could be made to be an all text type of
> management interface, Egress-VLANID can not. The VLANID is a
> simple 12-bit number and won't map well to the keyboard input
> optimization no matter what we do, so some form of special
> formatting for the management interface will be required to
> support these two attributes. Also, tagged and untagged are
> the only flags we need today, but perhaps this field would
> need to be extended someday (e.g. 802.1ad support), and using
> more bits to represent the two values needed today would seems
> to be wasteful. I propose no change here.
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)
> 9) A comment about the bit figures in Section 3 and 4.
> Currently, all the figures are basically identical: they
> contain the RADIUS Type and Length fields, plus one other
> field (variably called either "Integer", "String" or "Text").
> The contents of this field are then described in English.
>
> I think it would be much more understandable if the figure also showed
> the structure. For instance, instead of this (Section 3.1),
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Integer
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Integer(cont.) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> this would IMHO be more readable:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Tag Option | (zero)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (zero) | VLANID (12 bits) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> (Note that I'm not proposing changing the attribute formats at
> all -- so no changes to any software --, just how they are
> presented in the document. And we can keep all the zero
> padding there if we want...)
>
> [pc] To make this clean and follow your recommendation I
> believe it has significant structural changes to the document.
> Most of the attributes do not have diagrams at all. There
> would need to be a lot of new ASCII art added and it would be
> difficult for string based fields like NAS-Filter-Rule to
> accommodate this. If we put all the internal field names in
> the base attribute diagram along with Type and Length, it
> would seem that we would need to describe each of the other
> fields individually rather than indicating how to format the
> Integer, Text or String portion. I'd rather keep the bulk of
> the attribute sections intact and only provide a diagram
> describing how to format the Integer, Text or String porition
> - as is done in 3.1. We could certainly make 3.2, 3.3 and 3.4
> more consistent with 3.1 and add a diagram on how to format
> the Integer, Text and/or String component. Would this work?
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)
> 11) Section 7: It looks like this security considerations
> section was just copied from somewhere without much thought
> for how well it actually applies to this document. Most of the
> text looks redundant to me; we don't need to describe how to
> use IPsec with RADIUS in every document that defines a new
> RADIUS attribute.
>
> On the other hand, there's exactly zero discussion about new
> threats caused by the attributes defined in _this_ document.
> And to me it looks like there are new attacks that e.g. a
> malicious or compromised RADIUS server or proxy could do with
> these attributes (compared to the situation where NAS does not
> support these attributes). At least Egress-VLANID,
> Ingress-Filters and NAS-Filter-Rule have some pretty obvious
> possibilities for abuse... (and maybe some non-obvious as
> well)
>
> [pc] Yes, much of this text was copied from 3580, but short of
> trying to imagine all the things that could happen if a RADIUS
> server is comprimized, I'm not sure what else to put here. We
> could puts some words here about how modified settings of
> things like Ingress-Filters or Filter-Rules could change the
> expected behavior, but the discussion would not be exhaustive.
> I thought the point of this section was to document what the
> vulnerabilities are, not how they might be used. For example,
> the scheme is vulnerable to packet modification attacks, but
> we can't document what might happen with every possible
> modification of a packet. Please provide some more
> explanation or examples of what you are looking for here.
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:
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 messagse 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.[Paul Congdon]
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.[Pasi Eronen]
> 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. No, the text was intended as a replacement of what's already there. The existing text is IMHO unnecessary because it doesn't describe any security considerations of _this_ document. I don't think we need to repeat what's already said in RFC 2865 and 3579 in every document that defines a new RADIUS attribute: we just need to describe what new security considerations this document has (in addition to those already adequately described in 2865/3579).
[Paul Congdon]
I think we are converging. Would love to hear from others if this is
acceptable...
> >
> > 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.
>
> No, the text was intended as a replacement of what's already there.
>
> The existing text is IMHO unnecessary because it doesn't
> describe any security considerations of _this_ document. I
> don't think we need to repeat what's already said in RFC 2865
> and 3579 in every document that defines a new RADIUS
> attribute: we just need to describe what new security
> considerations this document has (in addition to those
> already adequately described in 2865/3579).
>
I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply. I'd like to at least leave the introductory
paragraph, followed by your text. The security section would then look
as follows:
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], [RFC3162], [RFC3579], and [RFC3580].
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.[Emile Bergen] That text looks very good. [Bernard Aboba] Yes, I think the text is fine. [Pasi Eronen] This looks OK to me.
Proposed Resolution: Accept
Issue 102: NAS/QoS Filter Rule Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00526.html Document: IEEE802-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
1) Section 3.5 is currently quite difficult to follow since it
mixes L2, IP, tunneling and HTTP redirect rules... It's not
always even clear when some element is just a name for a rule
(like "ipno") and when it's a literal string (like "from").
So some editing work is needed here. Maybe describing the L2,
IP filtering, IP tunneling and HTTP rules one-by-one
(instead of mixing their descriptions) would make this more
understandable.
(The IPFilterRule description in RFC3588 isn't nearly as
complicated as this, since it doesn't have the L2, tunneling
or HTTP rules.)
2) Or would using ABNF be of any help? Here's a first sketch
(probably buggy..)
rule = flush-rule /
l2-filter-rule /
ip-filter-rule /
ip-tunnel-rule /
http-redirect-rule
flush-rule = "flush"
l2-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " l2-filter [" Cnt"]
l2-filter = l2-proto " from " l2-address " to " l2-address
l2-filter =/ l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" mask) / "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
mask = 1*2DIGIT
ip-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " ip-filter
ip-filter = ("ip" / ip-proto)
" from " ip-address [" " ip-ports]
" to " ip-address [" " ip-ports]
*(" " ip-option)
ip-proto = 1*3DIGIT
ip-address = ["!"] (ipv4-address ["/" bits] /
ipv6-address ["/" bits] /
"any" /
"assigned")
ipv4-address = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-address = ;; TODO
bits = 1*3DIGIT
ip-ports = ip-port *("," ip-port)
ip-port = 1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)
ip-option = "Cnt"
ip-option = "frag"
ip-option =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
ip-option =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
ip-option =/ "established"
ip-option =/ "setup"
ip-option =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
ip-option =/ "icmptypes " icmptype *("," icmptype)
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
icmptype = 1*3DIGIT
icmptype =/ 1*3DIGIT "-" 1*3DIGIT
icmptype =/ ;; TODO (names)
ip-tunnel-rule = "tunnel " tunnel-id " in " ip-filter
tunnel-id = ;; TODO
http-redirect-rule = "redirect " [redir-cnt " "]
redir-url " in " ip-filter
redir-cnt = 1*DIGIT
redir-url = ;; TODO
(Ok, maybe this is not so clear either... but at least it's
unambiguous when something is just a rule name and when it's
a literal string )
3) Example of "macaddr/mask": The example should use some other
width than /24 to make it clearer how the counting works. Also,
the example given is an invalid one, since it does not meet the
"The MAC address MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the
example.
4) Description of "ipno/bits" says "the IP number MUST NOT have
bits set beyond the mask", but the example given, "1.2.3.4/24",
does not follow this. Suggested change: use 192.0.2.0/24 as the
example.
5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID
includes spaces, for instance?)
6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched
at least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
7) The document does not seem to describe what HTTP filter rules
are or how they work (HTTP redirect rules are explained, but not
HTTP filter rules).
8) The document allows an IP tunnel rule with direction "out",
but does not describe what such a rule means (the description
seems to apply only to rules with direction "in")
9) Currently the text says "A flush rule MUST appear before all
other rule types." I first read this to mean that a flush rule
must always be present, but I guess that was not what was
meant. Furthermore, it's not easy to parse the ordering
requirements.
Suggested change: Rewrite that paragraph to "Furthermore, if the
list contains different types of rules, they MUST appear in the
following order: flush rules, base encapsulation filter rules,
IP tunnel rules, HTTP redirect rules, IP filter rules, and HTTP
filter rules."
10) The document should explain why different types of rules must
be given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally
obvious why other orderings need to be forbidden.
11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
12) The document should somewhere describe the differences to
Diameter's NAS-Filter-Rule syntax.
13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte
attribute length limit, then boundaries between individual rules
are lost. This is not necessarily a big problem, as it looks
like the syntax can be unambiguously parsed anyway, but should
be mentioned explicitly (alternatively, we could delimit the
individual rules somehow).[Paul Congdon]
[pc] Comments on Pasi's issue 102...
1) Section 3.5 is currently quite difficult to follow since it mixes L2,
IP, tunneling and HTTP redirect rules... It's not always even clear when
some element is just a name for a rule (like "ipno") and when it's a
literal string (like "from").
So some editing work is needed here. Maybe describing the L2, IP
filtering, IP tunneling and HTTP rules one-by-one (instead of mixing
their descriptions) would make this more understandable.
(The IPFilterRule description in RFC3588 isn't nearly as complicated as
this, since it doesn't have the L2, tunneling or HTTP rules.)
[pc] ok, assuming the rest of the discussion addresses this first point.
2) Or would using ABNF be of any help? Here's a first sketch (probably
buggy..)
rule = flush-rule /
l2-filter-rule /
ip-filter-rule /
ip-tunnel-rule /
http-redirect-rule
flush-rule = "flush"
l2-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " l2-filter [" Cnt"]
l2-filter = l2-proto " from " l2-address " to " l2-address
l2-filter =/ l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" mask) / "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
mask = 1*2DIGIT
ip-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " ip-filter
ip-filter = ("ip" / ip-proto)
" from " ip-address [" " ip-ports]
" to " ip-address [" " ip-ports]
*(" " ip-option)
ip-proto = 1*3DIGIT
ip-address = ["!"] (ipv4-address ["/" bits] /
ipv6-address ["/" bits] /
"any" /
"assigned")
ipv4-address = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-address = ;; TODO
bits = 1*3DIGIT
ip-ports = ip-port *("," ip-port)
ip-port = 1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)
ip-option = "Cnt"
ip-option = "frag"
ip-option =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
ip-option =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
ip-option =/ "established"
ip-option =/ "setup"
ip-option =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
ip-option =/ "icmptypes " icmptype *("," icmptype)
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
icmptype = 1*3DIGIT
icmptype =/ 1*3DIGIT "-" 1*3DIGIT
icmptype =/ ;; TODO (names)
ip-tunnel-rule = "tunnel " tunnel-id " in " ip-filter
tunnel-id = ;; TODO
http-redirect-rule = "redirect " [redir-cnt " "]
redir-url " in " ip-filter
redir-cnt = 1*DIGIT
redir-url = ;; TODO
(Ok, maybe this is not so clear either... but at least it's unambiguous
when something is just a rule name and when it's a literal string )
[pc] We can insert this if we can complete the TODO parts above. Do we
insert it before the current description or completely replace what is
there with just the ABNF? I'm assuming this would be inserted in front
of the current descriptions and we would leave the existing text with
fixes discussed below. Can you help complete the TODOs or provide a
good reference guide on ABNF somewhere?
3) Example of "macaddr/mask": The example should use some other width
than /24 to make it clearer how the counting works. Also, the example
given is an invalid one, since it does not meet the "The MAC address
MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example.
[pc] accept suggestion
4) Description of "ipno/bits" says "the IP number MUST NOT have bits set
beyond the mask", but the example given, "1.2.3.4/24", does not follow
this. Suggested change: use 192.0.2.0/24 as the example.
[pc] accept suggestion, maybe change the first 0 to something else to
further disambiguate.
5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID includes spaces,
for instance?)
[pc] Good observation. This needs fixing. Seems like we have two
choices; put restrictions on the usage of Tunnel-Assignment-ID so that
the strings are parse-able (not really a good idea), or encapsulate the
string in quotes when used in the rule. Since there are no restrictions
on the format of the string used in Tunnel-Assignment-ID we MUST provide
a way to parse it as a single element in the entire attribute string.
Of course, the Tunnel-Assignment-ID could itself contain quotes, so we
will also need to describe some escaping function before including them
in the rule. The escaping function would be: For all occurrence of "
replace with \" and for all occurrence of \ replace with \\. While this
is a little ugly, I think it is the only course of action.
6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched at least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
[pc] agreed, fix these and double check the rest..
7) The document does not seem to describe what HTTP filter rules are or
how they work (HTTP redirect rules are explained, but not HTTP filter
rules).
[pc] There really aren't specific HTTP filter rules per-se. We don't
filter based upon HTTP content, but it is possible to filter all HTTP
traffic using normal IP filter rules. The text is a little unclear at
the end of the section that indicates there are 'redirect' and 'filter'
rules. Seems like we need to discuss redirect rules separately from
filter rules. There are really two types of redirect rules; tunnel and
http, and two filter rules; L2 and IP.
8) The document allows an IP tunnel rule with direction "out", but does
not describe what such a rule means (the description seems to apply only
to rules with direction "in")
[pc] Avi has written a great description of how the tunnel facility
works and how the directions apply. I've attached a version of this
document - perhaps Avi has something more recent? We probably want to
consider how parts of his document are incorporated into an annex or
some part of the document to make this clear.
9) Currently the text says "A flush rule MUST appear before all other
rule types." I first read this to mean that a flush rule must always be
present, but I guess that was not what was meant. Furthermore, it's not
easy to parse the ordering requirements.
Suggested change: Rewrite that paragraph to "Furthermore, if the list
contains different types of rules, they MUST appear in the following
order: flush rules, base encapsulation filter rules, IP tunnel rules,
HTTP redirect rules, IP filter rules, and HTTP filter rules."
[pc] Agreed. This is better than my suggestion to change this part of
the text to, "Base encapsulation filter rules MUST appear after a flush
rule (if present) and before IP tunnel,..."
10) The document should explain why different types of rules must be
given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally obvious
why other orderings need to be forbidden.
[pc] We had considerable discussion about this early on in the document
development. If my memory serves me correctly, we decided upon this
order to maximize interoperability and to address the fact that it
didn't make sense to filter out packets before putting them into the
tunnel. Perhaps others can recall more detail - sorry.
11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
[pc] agreed.
12) The document should somewhere describe the differences to Diameter's
NAS-Filter-Rule syntax.
[pc] agreed this relates to Bernard's comment as well. Text to be
developed.
13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules are lost. This is
not necessarily a big problem, as it looks like the syntax can be
unambiguously parsed anyway, but should be mentioned explicitly
(alternatively, we could delimit the individual rules somehow).
[pc] yes, this should not be a problem and implementations will split
the string in different ways, but if they are following the rules of
fragmentation and reassembly properly there is no issue. We really
don't need to say anything here as this is part of standard attribute
parsing. No action proposed.Today when we create a tunnel we tunnel all the traffic through that tunnel.
There is no way to specify which flows should be tunneled and which flows should
not.
There is a need to support a method to select which flows to direct to a tunnel.
This concept is not new. Certain advanced VPN products allows us to select which
traffic should be routed to the VPN and which should not.
As well, in certain cases it maybe useful to have multiple tunnels. The tunnels
may have a different end points; or there maybe multiple tunnels but each tunnel
utilizes different technology. It maybe useful to direct certain flows to these
different tunnels.
We will describe a method for directing certain traffic flows to a tunnel; then
we will look at how to support multiple tunnels. We will also look at how to
apply this dynamcially.
This proposal will greatly clean up how hotlining is done and will be useful
beyond just hotlining.
NOTE: this discussion is for simple-ip not mobile-ip.
Tunneling specification for RADIUS is provided by RF2868.
We use NAS-Filter-Rule to specify what traffic to direct into the tunnel. The
syntax is as per NAS-Filter-Rule but with the following (mostly all the same):
action is tunnel (new)
Direction (in|out|inout) (inout is new)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Note direction: 'in' is from the terminal 'out' is to the terminal
As indicated, a couple of new things here, the rest is the same: New action
called 'tunnel' which can take a tunnel-id as a parameter when we have more then
one possible tunnels. We have added 'inout' to support bidirection to allow us
to specify whether the direction of the flows. This is an optimization -- if it
wasn't there you could use two rules, one with direction 'in' the other with
direction 'out'.
NOTE ON NOTATION
================
------> Flow in one direction
<-----> Flow in two directions
======> Flow in a tunnel in one direction
<=====> and in both direction
TEP Tunnel Endpoint
Directing flows to a single tunnel.
===================================
RADIUS server that wants all traffic that flows between the Mobile and
destination X will issue an Access-Accept that contains: The specification for
the tunnel using the attributes defined by RFC 2868 and an NAS-Filter-rule.
The NAS-Filter-rule will look like:
tunnel inout from assigned to 123.456.34.0
This will cause all traffic that flows between the the Mobile and the
destination (123.456..34.0) to be tunneled over the specified tunnel.
+-------+ +------+ +------+ +------+
| | | | |Tunnel| | |
|Mobile +<---------->+ NAS +<=======>+ End +<----->+Destin|
| | | | |Point | | |
+-------+ +------+ +------+ +------+
The direction attribute is important because it controls how information is
routed. The following will demonstrate how traffic is routed. In all these
diagrams time is increasing as we proceed down the page. As well, there is only
one tunnel.
When direction is out:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<-------------------| (flows directly to NAS)
| | | |
The out bound traffic gets placed in the tunnel to the TEP and then the TEP
forwards the traffic to the Destination. The flow from the destination to the
mobile is routed directly to the mobile via the NAS. The NAS just passes it to
the mobile. The Home network would use this capability if it was only interested
in metering or seeing the outbound traffic from the Mobile.
When direction is in:
Mobile NAS TEP DESTINATION
| | | |
|---------->|------------------->| (flows directly to Destin)
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
| | | |
Outgoing traffic from the mobile gets to the NAS and is passed to the
Destination. Traffic from the destination gets to the NAS and the NAS redirects
the traffic to the tunnel to the TEP. The TEP then sends it back into the tunnel
to the NAS and the NAS forwards the traffic to the Mobile. The Home
When direction is inout:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
This combines the two diagrams together. Output from the Mobile reaches the NAS
and gets directed into the tunnel to the TEP. The TEP forwards the flow to the
Destination. When the Destination sends data to the Mobile it reaches the NAS,
the NAS redirects it to the TEP via the Tunnel. The TEP sends it back to the NAS
via the tunnel and the NAS forwards it to the Mobile.
Inout is useful when the home network wants to examine both incoming and
outgoing traffic.
Note that the above schemes flows the data through the TEP in stealth. That is,
neither the Mobile or the Destination know that the traffic has been redirected.
Also note that there maybe other scenarios as when the TEP acts like a NAT.
If the TEP is acting like a NAT, then we have:
Mobile NAS TEP/NAT DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<========|<---------|
The mobile establishes a connection to the Destination but the TEP acting as
NAT, transforms the request source address (as NATs do) such that the
Destination sees the Source address of the incoming traffic from the Mobile as
TEP/NAT. Therefore any replies from the Destination are sent to the TEP/NAT.
Direction rule of 'in' is important. Direction set to 'out' won't work and
'inout' doesn't matter.
The TEP/NAT then forwards all traffic to the tunnel to the NAS. The NAS (as in
the cases above) always forwards any egressing traffic from the tunnel to the
Mobile.
Therefore, from the point of view of the NAS, it does not care whether the TEP
is transparent or has NAT like behavior, traffic egress a tunnel at the NAT gets
forwarded to the Mobile.
Multiple tunnels
================
As mentioned sometime we want to have different tunnels. The tunnels are either
terminating at different places or they use different technology and some flows
are more suited for some tunnels etc...
RFC 2868 allows for specifying more then one tunnel:
If the RADIUS server returns attributes describing multiple tunnels
then the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the
Tunnel-Preference Attribute in the set of Attributes pertaining to
each alternative tunnel.
2868 allows us to specify multiple tunnels but only one tunnel is constructed.
We want a different behavior. That is, we want to have multiple of these tunnels
established.
A NAS filter rule that can identify a tunnel would allow us to bind NAS-Filter
rules to tunnels. For example:
tunnel 5 inout from assigned to 123.456.789.0
Means if the rule matches the flow direct that flow to tunnel 5.
RFC 2868 allows us to label tunnels in two ways. If more then one tunnel
specification is in an Access-Accept then each one needs to be tagged with an
id. There are two options for using assigning an id to a tunnel. One is to use
the Tunnel-Preference attribute the other is the Tunnel-Assignment-ID. Reusing
these will break could break functionality and therefore I propose that we
define a new attribute called tunnel-id.
Note that there is a third possibility and that is to use the TAG as an
identifier. The only problem with a TAG is that the TAG is only valid within an
Access-Accept. TAG value may be different in subsequent COA messages.
Backwards compatibility
=======================
How does a NAS know what to do? That is when it sees multiple tunnel
specification in an Access-Accept, what does it do? Does it instantiate one of
the tunnels as per 2868 or does establish multiple tunnels and bind the Filter
rules to them as per this RFC.
One way forward is that if there is at least one NAS-Filter-Rule with an
action of tunnel then all the tunnels are subject to having flow specifiers
(that is are to behave as per this RFC if it is supported).
Note that if we introduce a new attribute such as tunnel-id to the tunnel
specification then we can use that to tell the NAS that the tunnel specification
is a tunnel that interoperates with NAS Filter-Rules.
If we ever got into a situation where both Tunnel type are present, that is
Tunnels bound to NAS-FIlter rule and the 'old' tyle tunnel then, traffic that
matches the rule will be directed to a specified tunnel and all other traffic
will fall into the 'old' style tunnel. This works neatly.
Dynamic Behavior
================
Instructing the NAS to tunnel traffic dynamically is useful. As well to add a
flow to a tunnel or remove a flow from a tunnel dymanically is also useful.
The toughest challange is to install a redirection via tunneling to a flow that
already exists.
Say the Mobile is already established a tunnel to the a destination. We want to
install the tunnel such that the communication is not interrupted between the
Mobile and the destination. That scenario is the same as shown earlier (and
appears below)
Useing a fitler rule:
tunnel x inout from assigned to 123.456.34.0
Mobile NAS TEP DESTINATION
Before COA message: Mobile and Des communicate directly through the NAS
| | | |
|<--------->|<--------|--------->|
| | | |
After COA Message: Tne NAS passed information to the tunnel in both
directions.
x
|---------->|========>|--------->|
| | | |
| +--|<--------|----------|
| | | x | |
| +--|========>|--+ |
| | x | | |
|<----------|<========|--+ |
| | | |
Summary:
========
It is possible with slight modification to achieve redirection both statically
and dynamically using existing technology in the NAS.
This is useful not only for Hotlining but also for other purposes.
With respect to holtining , where we are only interested to know that the user
is invoking a particular service we would just use NAS-Filter-Rule with a action
= tunnel and direction out.
The only issue is that while we can remove the rules etc dynamically by sending
a flush there is no way to remove a tunnel that has been installed dynamically.
This is probably not a problem since once all the rules are removed nothing will
flow through that tunnel. However, it may be possible to state that once the
rules that redirect traffic to a tunnel are removed then the NAS may close the
tunnel.
Also note that this scheme can use L2 and L3 type packets.
Finally, this feature seems to interoperate with the old style tunnels as
defined by 2868.[Pasi Eronen]
Whatever we do, we should avoid having multiple descriptions that are in conflict with each other (currently we have two, and they don't completely match). ABNF is described in RFC 2234. > 4) Description of "ipno/bits" says "the IP number MUST NOT have > bits set beyond the mask", but the example given, "1.2.3.4/24", > does not follow this. Suggested change: use 192.0.2.0/24 as the > example. > > [pc] accept suggestion, maybe change the first 0 to something > else to further disambiguate. No, we should use 192.0.2.0/24 since it's the block reserved for documentation use (RFC 3330). > 8) The document allows an IP tunnel rule with direction "out", > but does not describe what such a rule means (the description > seems to apply only to rules with direction "in") > > [pc] Avi has written a great description of how the tunnel facility > works and how the directions apply. I've attached a version of this > document - perhaps Avi has something more recent? We probably want to > consider how parts of his document are incorporated into an annex or > some part of the document to make this clear. Thanks, this explained things (but something along those lines needs to be included in the document). > 10) The document should explain why different types of rules > must be given in exactly that order. Placing L2 rules before IP > is understandable, but for some of the other cases it's not > totally obvious why other orderings need to be forbidden. > > [pc] We had considerable discussion about this early on in the > document development. If my memory serves me correctly, we > decided upon this order to maximize interoperability and to > address the fact that it didn't make sense to filter out > packets before putting them into the tunnel. Perhaps others > can recall more detail - sorry. Well, I think it could make sense in theory (e.g., first filter out some bad traffic using "deny" rules, then put all the rest to a tunnel)... but I'm OK with leaving in these restrictions. > 13) If the NAS just concatenates all the NAS-Filter-Rule (or > QoS-Filter-Rule) attributes together to overcome the 255-byte > attribute length limit, then boundaries between individual > rules are lost. This is not necessarily a big problem, as it > looks like the syntax can be unambiguously parsed anyway, but > should be mentioned explicitly (alternatively, we could delimit > the individual rules somehow). > > [pc] yes, this should not be a problem and implementations will > split the string in different ways, but if they are following > the rules of fragmentation and reassembly properly there is no > issue. We really don't need to say anything here as this is > part of standard attribute parsing. No action proposed. There would be an issue if the grammar allowed ambiguous parsings. For instance, if we had ICMP types "no" and "notunnel" (which we don't), the following string could be parsed in two different ways (where exactly does the first rule end and second rule start?) "deny in 1 from assigned to any icmptypes source quench,notunnel permit in ip from assigned to any" I don't think we have any such cases currently (running the grammar through some kind of parser generator tool might verify this...), but it means that extending the syntax later has to be done with great care. It also means that saying "A NAS that is unable to interpret or apply a deny rule MUST terminate the session" is probably a bad idea, since it seems to imply that ignoring a "permit" rule the NAS cannot interpret is allowed... but if the NAS cannot interpret the rule, it cannot really know where one rule ends and the next rule starts.
[Paul Congdon]
Since these rules govern access policies, it is believed that a strong hammer is better than simply ignoring things that aren't understood or implemented. These should apply equally for permit rules or deny rules. If the NAS can't interpret the rule, it can't enforce the desired policy either and still MUST terminate the session, so if it gets lost parsing things, this rule should also apply.
[Pasi Eronen] I agree
[Paul Congdon] I agree that we need to make sure parsing is unambiguous. I suppose we need a line feed at the end of each rule and perhaps this needs to be escaped as well for the tunnel-assignment-ID issue. [Pasi Eronen]
Yes, I also think that having an unambiguous "rule end" (or "rule separator") character (LF, NUL, or something) would simplify the parsing... It would be even nicer if the escape mechanism for tunnel-assignment-ID would "hide" these characters somehow. Perhaps we should use "percent-hex-hex" escaping like URIs? (e.g. NUL would turn to "%00", not backslash+NUL).
[Mauricio]
This is a recap of status for Issue 102 (raised by Pasi Eronen), which consists of a number of sub-issues. We believe all issues have acceptable action recommendations and unless we hear otherwise, the action noted will be taken. 102-1 Description: Section 3.5 is currently quite difficult to follow since it mixes L2, IP, tunneling and HTTP redirect rules... It's not always even clear when some element is just a name for a rule (like "ipno") and when it's a literal string (like "from"). So some editing work is needed here. Maybe describing the L2, IP filtering, IP tunneling and HTTP rules one-by-one(instead of mixing their descriptions) would make this moreunderstandable. (The IPFilterRule description in RFC3588 isn't nearly ascomplicated as this, since it doesn't have the L2, tunneling or HTTP rules.) Discussion: 9/23 - Paul Congdon suggests that this issue be solved through description of nas-filter-rule using ABNF. No additional discussion generated on this sub-issue. Action: Replace current 'nas-filter-rule' description that uses non-standard syntax language to use ABNF. --------------------------------------------------- 102-2 Description: Use ABNF to describe 'nas-filter-rule' Discussion: 9/23 - Paul accepts Posi's suggestion to use ABNF and questions whether it should replace existing non-standard syntax description or appended to it. 9/26 - Posi says that regardless of the way, multiple syntax descriptions should not be in conflict. No additional discussion. Action: Replace current 'nas-filter-rule' description that uses non-standard syntax language to use ABNF. --------------------------------------------------- 102-3 Description: Example of "macaddr/mask": The example should use some other width than /24 to make it clearer how the counting works. Also, the example given is an invalid one, since it does not meet the "The MAC address MUST NOT have bits set beyond the mask" requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example. Discussion: 9/23 - Paul accepts suggestion to change example. Action: Change example to use 00-10-A4-23-00-00/32 --------------------------------------------------- 102-4 Description: Description of "ipno/bits" says "the IP number MUST NOT have bits set beyond the mask", but the example given, "1.2.3.4/24", does not follow this. Suggested change: use 192.0.2.0/24 as the example. Discussion: 9/23 - Paul accepts suggestion to change example. Also suggests a different addres example. 9/26 - Pasi asserts RFC3330 mandates given address example. Action: Change example to use 192.0.2.0/24 . --------------------------------------------------- 102-5 Description: Description of tunnel_id: according to RFC 2868, there are no restrictions on the format of the Tunnel-Assignment-ID. Currently it's not clear if the NAS-Filter-Rule syntax supports correctly parsing arbitrary IDs (what happens if the ID includes spaces, for instance?) Discussion: 9/23 - Paul suggests use of escaping function, since there are no restrictions on the format of the string used in Tunnel-Assignment-ID we MUST provide a way to parse it as a single element in the entire attribute string. Of course, the Tunnel-Assignment-ID could itself contain quotes, so we will also need to describe some escaping function before including them in the rule. The escaping function would be: For all occurrence of " replace with \" and for all occurrence of \ replace with \\. Action: Modify paragraph describing role of 'tunnel-id' parameter for nas-filter-rule as follows: "A tunnel id. When the 'tunnel' rule matches, traffic is redirected over the tunnel with the specified tunnel_id. Traffic can only be redirected to or from named tunnels that have been established per [RFC2868] and named using the Tunnel-Assignment-ID attribute described therein. The tunnel id MUST be encapsulated in double quotes and use the following escape functions in case the tunnel id itself contains any quotes: For all occurances of " replace with \" For all occurances of \ replace with \\ Example: A tunnel with the name of tunnel "ppp1" would be specified as "tunnel /"pp1/"" within the rule." ------------------------------------------------------ 102-6 Description: Near the end of Section 3.5: The "concise syntax statements" don't exactly match the definitions earlier. I catched at least these: - IP rule is missing "[ports]" before "to" - IP rule is missing "|" after "redirect" - HTTP redirect rule is missing the "proto" part after the direction - HTTP redirect rule does not have "[ports]" Discussion: 9/23 - Paul accepts change Action: Per sub-issue 102-2 the description of nas-filter-rule will be using ABNF. The need for concise syntax statements no longer exists and will be removed from document. ------------------------------------------------------ 102-7 Description: The document does not seem to describe what HTTP filter rules are or how they work (HTTP redirect rules are explained, but not HTTP filter rules). Discussion: 9/23 - Paul agrees better description necessary. 12/2 - Mauricio responds with new text proposal to list. Action: Replace existing HTTP filter description with new text proposed on 12/2. ------------------------------------------------------ 102-8 Description: The document allows an IP tunnel rule with direction "out", but does not describe what such a rule means (the description seems to apply only to rules with direction "in") Discussion: 9/23 - Paul posted Avi's tunneling document 9/26 - Posi found the document useful 11/18 - Mauricio asked Posi for guidance on what to add to the document from Avi's document. 11/22 - Posi suggest inclusion of a portion of Avi's tunneling document as an Appendix to draft 12/13 - Paul posts to radext email list new proposed text for appendix A. Action: Add Paul's suggested text from 12/13 to appendix A. ------------------------------------------------------ 102-9 Description: Currently the text says "A flush rule MUST appear before all other rule types." I first read this to mean that a flush rule must always be present, but I guess that was not what was meant. Furthermore, it's not easy to parse the ordering requirements. Rewrite that paragraph to "Furthermore, if the list contains different types of rules, they MUST appear in the following order: flush rules, base encapsulation filter rules, IP tunnel rules, HTTP redirect rules, IP filter rules, and HTTP filter rules." Discussion: 9/23 - Paul accepts change. Action: Replace paragraph in question with Pasi's suggested text. ------------------------------------------------------ 102-10 Description: The document should explain why different types of rules must be given in exactly that order. Placing L2 rules before IP is understandable, but for some of the other cases it's not totally obvious why other orderings need to be forbidden. Discussion: 9/23 - Paul asserts proposed ordering rules are to maxium interoperability 9/26 - Pasi accepts Action: None ------------------------------------------------------ 102-11 Description: The document should have some examples of NAS filter rules, preferably showing most of the different features at least once. Discussion: 9/23 - Paul accepts Pasi's recommendation. Action: Add several example of NAS filter rules per Pasi's recommendation. ------------------------------------------------------ 102-12 Description: The document should somewhere describe the differences to Diameter's NAS-Filter-Rule syntax. Discussion: 9/23 - Paul accepts Pasi's recommendation Action: Add paragraph to description section detailing differences to Diameter's NAS-Filter-Rule ------------------------------------------------------ 102-13 Description: If the NAS just concatenates all the NAS-Filter-Rule (or QoS-Filter-Rule) attributes together to overcome the 255-byte attribute length limit, then boundaries between individual rules are lost. Parsing may be ambiguous. Discussion: 9/23 - Paul asserts that this should not be a problem. No action proposed. 9/26 - Pasi states that dependancies exist on grammer to be parsable in non-ambigous manner. Current grammer seems to have no opportunities for ambiguity. 9/26 - Paul agrees it would be nice to have a rule delimeter 9/26 - Pasi agrees with Paul. Pasi goes on to suggest usage of a rule delimeter field. Action: Add rule delimeter to filter syntax.
Proposed Resolution: Accept
Issue 103: Multi-Address NASes Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: July 20, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00548.html Document: FIXES-00 Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue:
A sub-portion of the Issue 87 discussion is being filed as a new and separate Issue. The relevant portion of that discussion, contributed by Bernard Aboba, follows. "However, this does bring up another issue, which is how the RADIUS server identifies the NAS if it is more than one hop away. NASes can have more than one IPv6 address and this makes it possible for a NAS to put a linkscope address in the NAS-IPv6-Address field. If the proxy is on the same link as the RADIUS client, the RADIUS server could receive a packet with a NAS-IPv6-Address as a linklocal address. The same issue can occur with IPv4 Link Local, and of course a NAS can have more than one IPv4 and IPv6 address. One potential suggestion might be to use the NAS-Identifier attribute in such a situation so as to avoid having to configure the RADIUS server with all potential NAS addresses."
Requested change: Proposed changes to the document. "One potential suggestion might be to use the NAS-Identifier attribute in such a situation so as to avoid having to configure the RADIUS server with all potential NAS addresses." "There are a number of situations in which a NAS may have multiple IP addresses. IPv4/IPv6 dual stack operation is one example, but it is also possible for a NAS to have multiple IPv6 or IPv4 addresses. A NAS that is a member of multiple VLANs would have an IPv4 address for each VLAN. A NAS also can have multiple IPv6 or IPv4 addresses on a single interface. [RFC2865] Section 5.44 states that only a single NAS-IP-Address attribute may be included in an Access-Request, and that it may not be included in other messages (Challenge, Reject, Accept). Similarly, [RFC3162] Section 3 provides the same restrictions for NAS-IPv6-Address. Since RADIUS only looks at the packet source address to determine the appropriate shared secret, if a NAS sends packets from different source addresses, then the RADIUS server needs to have a shared secret for each address. My recommendation is that RADIUS clients with multiple addresses SHOULD use the NAS-Identifier attribute instead of NAS-IPv4-Address or NAS-IPv6-Address."
Proposed Resolution: Discuss
Issue 104: Mismatch in Digest-Domain Submitter name: Hideo Morishita Submitter email address: manmos@stellar@co.jp Date first submitted: July 22, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: 3.17, 5 Rationale/Explanation of issue:
3.17 Digest-Domain attribute Description . . . protection space (see [RFC2617], section 3.2.1). RADIUS servers MAY send one or more attributes of this type in Access- ^^^^^^^^^^^ Challenge messages. This attribute MUST only be used in Access-Challenge messages. but 5. Table of Attributes +-------------------------+-----+-----+--------+--------+-----------+ | Attribute | # | Req | Accept | Reject | Challenge | +-------------------------+-----+-----+--------+--------+-----------+ . . . | Digest-Domain | TBD | 0 | 0 | 0 | 0-1 |
Proposed Resolution: Accept
Issue 105: IANA Registration Submitter name: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: July 28, 2005 Reference: Document: RFC3576MIBs-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
Both draft-ietf-radext-dynauth-client-mib-01.txt and
draft-ietf-radext-dynauth-server-mib-01.txt define
radiusDynamicAuthorization as
radiusDynamicAuthorization OBJECT IDENTIFIER ::= { mib-2 xxx }
And then define the respective MODULE-IDENTITY under
radiusDynamicAuthorization.
Defining the same node in two separate documents seems odd, although it
is IANA who is in charge with the xxx allocation. Also, this results in
smilint protesting with a level 4 warning:
Warning: module-identity-registration (level 4)
Message: uncontrolled MODULE-IDENTITY registration
Description: The identities of IETF MIB modules should be registered
below
mib-2, transmission, or snmpModules so that the
registration space can be controlled by IANA.
I wonder what are the good reasons to break this 'should'
recommendation. Proposed Resolution: Discuss
Issue 106: Vendor Specific Values Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: July 26, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00582.html Document: RADIUS Design Guidelines Comment type: 'T'echnical Priority: '1' Should fix Section: (new) Rationale/Explanation of issue: In addition to the well-documented Vendor Specific Attributes (VSA), implementation practice has extended to Vendor Specific Values (VSV) of IETF Standard RADIUS Attributes. A snippet from a RADEXT list thread: See: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/share/dictionary.bay?rev=1.5&content-type=text/x-cvsweb-markup Look for "Service-Type". Vendor-specific values are of the form ((vendor-id << 16) | num), One of the RFC's refers to this practice, but I can't recall which right now. Requested change: Describe the practice. Include recommendations for or against the practice, and standardize the recommend method of encoding, if the practice is encouraged.
[Alan DeKok]
After a bit of searching, RFC 2882, section 2.2.1 documents this.
I would recommend using the practice, and documenting the encoding
as defined above.
Proposed text:
In addition to Vendor-Specific Attributes (VSA's), it is useful for
vendors to define custom values for previously defined attributes.
These values may be called Vendor-Specific Values (VSV's). This
practice is encouraged, as it avoids overloading of existing values.
Given a choice between re-using an existing value in a context where
it may not be directly applicable, or defining a VSV, vendors SHOULD
define a new VSV.
A summary of the Vendor-Specific Value format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | Vendor-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id
2 octets of the SMI Network Management Private Enterprise Code
of the Vendor in network byte order, as defined in the "Assigned
Numbers" RFC [6].
Vendor-Value
2 octets defining the vendor-specific value.
VSV's MUST be defined only for attributes of type "integer", and
then only where the existing standards define one or more values for
the attribute.
Note that the Vendor-Id is defined here as a 16-bit number, where it
is defined as a 32-bit number in the Vendor-Specific attribute. This
choice may not be the best one, and is driven by the limitations of
the 32-bit integer field.> These values may be called Vendor-Specific Values (VSV's). 2882 uses Vendor-Specific Enumerations (VSE's). We should use that here.
[David Nelson]
RFC 2882 is certainly a fact-based document. It reports existing deployment behaviors. Its abstract reads: Abstract This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. IMHO, we should be careful about inferring any desired or implied level of standardization of any of the practices reported in 2882. If there is no good reason to the contrary, then following existing convention may be a good thing. OTOH, the fact that one or more vendors chose to implement a needed (or desired) function in a particular fashion should not set a binding precedent on the RADEXT WG. These extensions, in all likelihood, received no IETF review, or even third party review, prior to their implementation and deployment. We should look at these "ad hoc" extensions with a critical eye.
[Alan DeKok]
Absolutely. I have no objections to the use of VSE's, but I do have conditions on their use. Use and design of VSE's SHOULD follow from a standards process. Otherwise, existing standards are re-used in situations where they may not be appropriate. I view VSE's as a minor shortcoming in the original RADIUS spec. We have VSA's, so it isn't a large leap to standardize *some* form of VSE's.
[Bernard Aboba]
I think there is a basic issue with tackling this in the Issues & Fixes document. Self-allocation of VSVs is a revision of RFC 3575 (RADIUS IANA Allocations Policy) and therefore would need to be a standards track document, which the Issues & Fixes document is not. RFC 3575 defines that attribute values can be allocated via designated expert, with the exception of Service-Type, which requires IETF Consensus. All allocations require a specification. The allocation of Service-Type values was tightened because when it was FCFS it had been used (by IEEE 802.11F) to define new RADIUS commands outside the IETF process.
Proposed Resolution: Discuss
Issue 107: Interim Accounting Interval Submitter name: Saikrishnan Submitter email address: saig@cisco.com Date first submitted: July 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00528.html Document: FIXES-00 Comment type: 'T'echnical Priority: '1' Should fix Section: (new) Rationale/Explanation of issue:
In section 2.1 of RFC 2869, it is mentioned that the interim-accounting-interval coming from the RADIUS server is superceded by the local config on the NAS. Pl. find below the snippet. ----- 2.1. RADIUS support for Interim Accounting Updates When a user is authenticated, a RADIUS server issues an Access-Accept in response to a successful Access-Request. If the server wishes to receive interim accounting messages for the given user it must include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages. It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept. ---- But in terms of priority it makes more sense for the finer granularity config overriding the global config. For instance, if you want to apply an umbrella policy that all the sessions are done periodic accounting every 30 mins but for Jane's session, we need to do periodic accounting every 45 mins, the only way for provisioning this is by adding 45' to Jane's user profile. But the RFC MUSTs it out. I am copying the authors for clarification. Please note that in all the other attributes in Cisco IOS, the PER-USER attribute (the attribute defined in the user profile) overrides what is configured globally on the box. At minimum, this should be left for implementation. Pl. let me know if I am missing something.
[Bernard Aboba]
The Interim Accounting Interval is often set in order to ensure against loss of income by billing systems. So I can understand why there is concern if an Interim-Accounting-Interval attribute sent by a RADIUS server would be ignored by the NAS. Although I do not recall the conversations that lead to this paragraph being inserted, I think the concern may relate to inappropriately small values being sent by a RADIUS server. For example, if the implementation has a setting for "minimum Interim-Accounting-Interval" then I would say that this should not be overridden by a smaller value, but could be overridden by a larger one. However, if the nature of the implementation setting is "use value X by default, but allow the RADIUS server to override it" I don't understand why that should be prohibited.
[Barney Wolff]
I think the issue is whose policy shall apply, when the RADIUS server and NAS are under different administrative control. Setting the value in the NAS is the equivalent of overriding whatever value is set by the server in the proxy that (presumably) should exist between the NAS and the server in this case. > However, if the nature of the implementation setting is "use value X by > default, but allow the RADIUS server to override it" I don't understand > why that should be prohibited. One can always speculate on why values would be configured directly in the NAS if the proxy is under the same administration. Perhaps the thinking was that some NASes may be intelligent enough to pick the right server based on NAI or other info without an intervening proxy. In that case configuration of values on the NAS is the equivalent of doing so in a virtual proxy, and, since a proxy can always override attribute values, the NAS settings win. A definite choice, even if "wrong", is probably better than uncertainty in cases like this.
[Murtaza Chiba]
That's an interesting point. In wholesale environments sometimes the wholesaler wants to control specific config bits such as compression, for instance. For compression it would be undesirable for a retailer to turn it on for users as it significantly degrades the performance and hence would affect subscribers for other retailers as well. In this case too a smaller interim value would presumably chew up more resources, so I agree with Bernard that retailers should be able to change the interval time on a per user basis as long as they are not increasing the frequency of updates beyond a configured threshold.
[Nagi Reddy Jonnala]
This is really a valid question that one comes across many times and I also support Bernard's view point here. I would like to add the below as well. RFC-2869 text: "It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept. This scheme does not break backward interoperability since a RADIUS server not supporting this extension will simply not add the new Attribute. NASes not supporting this extension will ignore the Attribute." I'm not sure if the wording "NAS MUST override the value found in Access-Accept" exists in the view of not to break backward Compatibility. I don't think there would be any backward compatibility issues if the NAS honors the Radius server interim interval request (assuming that it can honor based on some locally configured value like minimum Interim interval). IMO, it is worth documenting it somewhere.
[Alan DeKok]
The following is proposed text to resolve ISSUE 107. If there are no
comments, the text will be included in the next revision of the document.
---
S.s.s. Interim-Accounting-Interval
[RFC2869] Section 2.1 states:
It is also possible to statically configure an interim value on
the NAS itself. Note that a locally configured value on the NAS
MUST override the value found in an Access-Accept.
This requirement may be phrased too strongly. It is conceivable that
a NAS implementation has a setting for a "minimum" value of Interim-
Accounting-Interval, based on resource constraints in the NAS, and
network loading in the local environment of the NAS. In such cases,
the value administratively provisioned in the NAS should not be over-
ridden by a smaller value from an Access-Accept massage. The NAS's
value could be over-ridden by a larger one, however. The intent is
that the NAS sends accounting information at fixed intervals, short
enough such that the potential loss of billable revenue is limited,
but also that the accounting updates are infrequent enough such that
the NAS is not overloaded.
[Bernard Aboba]
I think this resolution is generally OK. Change "massage" to "message".Also change "NAS is not overloaded" to "NAS, network and RADIUS server are not overloaded".
[Alan DeKok] I have no objection to those comments.
Proposed Resolution: Accept
Issue 108: redir_cnt not included as a method of redirection removal Submitter name: Paul Congdon Submitter email address: paul.congdon@hp.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00625.html Document: IEEE802-00 Comment type: T Priority: S Section: A.2.e, pg. 27, last paragraph Rationale/Explanation of issue:
This section talks about how the redirection process can be disabled. Since we added the redir_cnt parameter to the rule we should include it as a mechanism for disabling redirection. Also it isn't clear if a new session is created when the redir_cnt value becomes zero. If a new session is created, then the accounting records should also be sent. I will propose that we insert a paragraph before the last paragraph in this clause so the accounting scheme will remain intact.
Requested change:
Insert a paragraph before the last paragraph that describes the redir_cnt scheme. Suggest something like the following words: "When HTTP redirection is established via a NAS-Filter-Rule (TBD) it also possible to have HTTP redirection automatically removed by including a redir_cnt parameter along with the rule. The rule will be removed from the active rule set when the rule matches redir_cnt number of times. When the rule is removed, HTTP redirection will also be removed."
Proposed Resolution: Discuss
Issue 109: HTTP NAS-Filter-Rules Always Assume Port 80
Submitter name: Paul Congdon
Submitter email address: paul.congdon@hp.com
Date first submitted: 08-10-2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00626.html
Document: IEEE802-00
Comment type: T
Priority: S
Section: 3.5
Rationale/Explanation of issue:
There appears to be no way to augment the HTTP rules with a port number
if we want to attempt to match HTTP traffic on something other than port
80. This is likely useful in enterprise environments where proxies may
be used and browsers are configured to use something other than port 80.
Seems like we should add the ports options seen in the IP filter to the
HTTP rule.
Requested change:
Add the {port/port-port}[,ports[,...]] option that appears in the IP
rule to the HTTP rule as well.Proposed Resolution: Discuss
Issue 110: Compliance and Coherence Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 1.2, 3.5 Rationale/Explanation of issue: 1) Compliance vs. Functional Coherence
Most of the RADIUS RFCs tend to address a single functional area, e.g. IPv6 attributes, EAP, tunneling, etc. This is good because RFCs tend to become checkmarks on RFPs or customer requirements. This documents seems to combine functionality that is only related to IEEE 802 (VLANs) and things that are independent of access type. For example, filtering and redirection can apply equally usefully to PPP-based L2 connections. If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim compliance to this potential RFC unless I support all the VLAN oriented attributes because the compliance language in section 1.2 requires an all or nothing approach to compliance. Can the authors clarify why the NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802 specific attributes?
I would think these should be addressed via separate documents. 2) Compliance vs. Optional Functionality I did not understand how the "options" in section 3.5 relate to the compliance language in section 1.2. If I do not support the "Cnt" option for counting rule hits, can I still claim compliance with this document? Are these optionally specified or optionally supported?
[Paul Congdon]
Greg has made the following comment on the 802 attributes draft: >1) Compliance vs. Functional Coherence >Most of the RADIUS RFCs tend to address a single functional area, e.g. >IPv6 attributes, EAP, tunneling, etc. This is good because RFCs tend >to become checkmarks on RFPs or customer requirements. This documents >seems to combine functionality that is only related to IEEE 802 (VLANs) >and things that are independent of access type. For example, filtering >and redirection can apply equally usefully to PPP-based L2 connections. >If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim >compliance to this potential RFC unless I support all the VLAN oriented >attributes because the compliance language in section 1.2 requires an >all or nothing approach to compliance. Can the authors clarify why the >NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802 >specific attributes? > >I would think these should be addressed via separate documents. Throughout the history of this document we have included, excluded, added and removed various attributes to get the scope of the document just right. We have been balancing the tradeoff of getting a reasonable focused set of attributes in a single document without creating a slew of attribute documents to run through the process. Also, we are addressing the needs and requests of other SDOs for completing the work on this set of attributes in a timely manner. I believe we can (and perhaps have) address the issue of compliance to the spec by indicating in the front matter how NAS devices that do not support media that provides the functionality controlled by the attributes in the spec are supposed to behave. We already have statements in the spec (section 2.2) that say if you can't support the functionality requested by the attributes you MUST treat an Access-Accept as an Reject. This should be sufficient to allow non VLAN devices to use this spec and still create an environment with predictable behavior.
Proposed Resolution: Discuss
Issue 111: Accounting Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: A.3 Rationale/Explanation of issue:
The accounting requirements do not seem to be fully treated by the draft. Section A.3 has a MUST requirement related to accounting. I would think that MUST requirements should be treated by the text, not in an appendix. Why does redirection require a STOP/START pair? Can't this information be conveyed via an INTERIM record for the same session? If the Service- Type is not changing, I'd think that an INTERIM would suffice.
[Paul Congdon]
At IETF-64 we reviewed this issue. There did not seem to be any objection to having compliance statements in the Annex given that this Annex is where the context for the statements is developed. Also, since a new session is created, as stated in the draft, there is no need to use INTERM messages.
Proposed Resolution: Discuss
Issue 112: NAS-Filter-Rule Confusion Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 3.5 Rationale/Explanation of issue:
I could not understand some parts of the specification; I guess Pasi has already commented on this. In particular, the proto spec: proto <l2:<ether2[:val]|rmon_str>> type[:val]|ipprot|ip|http> there are not an equal number of "<" and ">" and the "type[:val]" part is not described. The "ipprot" does not provide for a value part.
Proposed Resolution: Discuss
Issue 113: Attribute Concatenation Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: August 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html Document: IEEE802-00 Comment type: T Priority: S Section: 3.6 Rationale/Explanation of issue:
I didn't understand how the language in section 3.6 about concatenating QoS-Filter-Rule(s) works. If these are simply concatenated, how does an implementation distinguish between multiple 'small' QoS-Filter-Rules and a single larger attribute? What if I want to send one QoS-Filter-Rule which spans 253, followed by one which does not?
[Paul Congdon]
Responding to Greg's issue 113... >I didn't understand how the language in section 3.6 about concatenating >QoS-Filter-Rule(s) works. If these are simply concatenated, how does >an implementation distinguish between multiple 'small' QoS-Filter-Rules >and a single larger attribute? What if I want to send one >QoS-Filter-Rule which spans 253, followed by one which does not? Actually I believe the editorial note needs to be removed since there is text just after the note that explains the problem. As you know, Diameter attributes may be larger than what will fit in the Radius attribute so we need to support fragmentation and reassembly in the general sense. The assumption with concatenation is that you are building a 'list' of QoS-Filter-Rules, just like you are building a 'list' of NAS-Filter-Rules. So, as the text states, if there are multiple QoS-Filter-Rules, you simply concatenate them together (whether they are multiple little rules or one large split rule) and treat them as a 'list' The proposed resolution to this comment is to remove the editorial note. If this is not acceptable, please propose some new text in this section which helps clarify things for you - provided I've made that clear.
[Glen Zorn] Actually, Diameter AVPs can be larger than a RADIUS _message_. If you really want to support fragmentation and reassembly in the general sense, then you need to deal with that, too.
[Paul Congdon]
I probably should have been more clear about using the words 'general sense'. All we are talking about is the string in the Qos-Filter-Rule that might be too large to fit in the current Radius version of the attribute. I am under the assumption that handling this type of scenario is common practice in Radius/Diameter proxies and that is has been documented in a previous RFC, but perhaps I'm wrong on this.
[Glen Zorn]
OK, I'm a bit confused here: is this Qos-Filter-Rule generated by a RADIUS server, a Diameter peer or either?
[Paul Congdon]
It is generated by a RADIUS server and is a RADIUS attribute. We are simply leveraging the format and syntax of the rule string.
[Paul Congdon]
I still think the existing text explains the issue and solution fairly
clearly:
The Text field contains a QoS filter, utilizing the syntax
defined for the QoSFilterRule derived data type defined in
[RFC3588], Section 4.3. Note that this definition contained an
error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
The RADIUS server can return multiple QoS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one QoS-Filter-Rule Rule attribute is included, it is
assumed that the attributes are to be concatenated to form a
single QOS filter.
Whereas the maximum allowable message size in [NASREQ] is
greater than RADIUS' maximum allowable message size, it is
assumed that QOS filters that exceed RADIUS' allowable message
size will be broken into multiple QoS-Filter-Rule attributes by
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes. [Glen Zorn]
But this makes no sense to me at all. Do you mean "Whereas the maximum allowable AVP size in [NASREQ] is greater than RADIUS' maximum allowable attribute size, it is assumed that QOS filters that exceed RADIUS' allowable attribute size will be broken into multiple QoS-Filter-Rule attributes by the RADIUS server and concatenated back into a single QOS filter by the NAS"?
[Paul Congdon]
Yes. We can use this text as a replacement if you agree with this.
Taking Glen's suggested text, I'd like to close this issue out with the
following proposed text for the Text field in section 3.6. Please let
me know if this will work.
Text
The Text field contains a QoS filter, utilizing the syntax
defined for the QoSFilterRule derived data type defined in
[RFC3588], Section 4.3. Note that this definition contained
an error, so that the complete syntax is described in the
definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
The RADIUS server can return multiple QoS-Filter-Rule
attributes in an Access-Accept or CoA-Request packet. Where
more than one QoS-Filter-Rule Rule attribute is included, it
is assumed that the attributes are to be concatenated to form
a single QOS filter.
Whereas the maximum allowable AVP size in [NASREQ] is greater
than RADIUS' maximum allowable attribute size, it is assumed
that QOS filters that exceed RADIUS' allowable attribute size
will be broken into multiple QoS-Filter-Rule attributes by
the RADIUS server and concatenated back into a single QOS
filter by the NAS.
As per the requirements of RFC 2865, Section 2.3, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. The attributes MUST be consecutive attributes in the
packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes. [Emile Bergen]
I think the relevant section of RFC 2865 is Section 5, and it states: If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. The order of Attributes of different Types is not required to be preserved. A RADIUS server or client MUST NOT have any dependencies on the order of attributes of different types. A RADIUS server or client MUST NOT require attributes of the same type to be contiguous. So I see two issues. 1: the conflict between the "consecutive attributes" requirement and the last sentence of the text quoted above, and 2. it would probably be clearer if the reference pointed to Section 5 (Attributes) instead of section 2.3 (Proxy behaviour).
[Glen Zorn]
Are you _sure_ that you want to use this {QoS-Filter-Rule} syntax? It's awfully verbose.
Even if you really do want to use it, I would suggest that you reproduce it
(or rather, adapt it to use w/RADIUS) in this document, rather than incorporating
it by reference. There are several problems with the Diameter definitions,
not least of which is that the definition of the QoS-Filter-Rule AVP depends
upon the definition of IPFilterRule which is derived from OctetString which
doesn't exist in RADIUS.
I still am puzzled by the reference to Diameter. As I mentioned earlier, it
is not possible to fit a maximum sized QOS-Filter-Rule AVP into a single
RADIUS message, never mind a set of RADIUS attributes. So why even talk
about it? I also think that it would be a very good idea to specify a maximum
length for QOS filter rules themselves. Also, if a filter is made up of filter
rules, it makes sense that rules can be concatenated to form a filter; however,
the paragraph above offers no guidance the case where a rule doesn't fit into a
QoS-Filter-Rule attribute.[Paul Congdon]
Yes, what is important is that the order is maintained, not that the
attributes are consecutive. Since this sentence is in direct conflict
with 2865, we need to remove it. Also I agree that Section 5 appears to
be the better reference. The last paragraph should read:
As per the requirements of RFC 2865, Section 5, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes.
I'm still working on a response to the rest of Glen's comments...[Bernard Aboba] Since QoS-Filter-Rule has been removed, this issue is closed.
Proposed Resolution: Accept
Issue 114: WGLC Review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 10, 2005 Reference: Document: IEEE802-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
Accounting I do not understand the purpose of the accounting functionality in the draft. The focus of this document is VLAN attribute, priority and filtering. How does Acct-EAP-Auth-Method fit into that? I think this is a leftover WLAN attribute which should be removed. Acct-NAS-Filter-Rule attribute. The purpose of this attribute is to keep count of hits on filter rules. This duplicates functionality under development in other WGs such as IPFIX, and so I'd question whether this is appropriate functionality for RADIUS accounting. Overview I do not understand the purpose of Section 2, Overview. Most of it seems like it could be deleted without losing anything. " As described in the Introduction section, it may be desirable to a control user's access to network resources (e.g. the Internet) with greater standardized explicitness than what current RADIUS attributes provide. In this section we will examine these requirements in more detail. " What is "standardized explicitness?" The filtering functionality defined in this document is no more granular than what is already supported in the Filter-ID attribute. So this sentence seems inaccurate. " Besides IEEE 802.1X networks, there is a corollary need within Internet Service Provider (ISP) environments for standardized authorization attributes." What is an IEEE 802.1X network? Do you mean an IEEE 802 network? RADIUS has supported authorization attributes for a long time, this sentence makes it seem like this is the first time that authorization attributes have been defined in RADIUS. Also, mixing ISPs and IEEE 802 functionality in the same document is a symptom of a deeper problem which Greg Weber has brought up -- it is not clear what devices need to do in order to comply with the document, if compliance is even possible. " From time to time, an ISP requires to restrict a user's access to the Internet and redirect their traffic to an alternate location. For example, the user maybe on a prepaid plan and all the resources have been used up." Since this implies that the document is actually aimed at prepaid, I think you need a reference here. The ability to block user's traffic is required at service initiation and once service has been established. These capabilities must also be available across access technologies and various business scenarios. For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. As well, this capability must work whether the user is in their home network or roaming in a visited network which may or may not have a direct roaming relationship with the user's home network. This seems like a list of requirements that this document was supposed to satisfy. However, I would question whether in fact these requirements are legitimate. This documented started out focussed on IEEE 802 functionality -- how did it somehow morph into a document relating to prepaid, portals, etc.? " Blocking access refers to setting up access control rules at the NAS such that when the user initiates IP traffic, the NAS examines the set of rules associated with the service granted to the user. These rules determine what traffic is allowed to proceed through the NAS and what traffic will be blocked. Today this capability is supported in RADIUS and is configurable during service establishment and mid-service via the Filter-Id(11) attribute. To use Filter-Id to control access to network resources the rules need to be configured apriori at each NAS. Filter-Id(11) is used in an Access-Accept to specify the name of the filter rule(s) to apply to this session. To effect a change mid-service (dynamically), the Filter-Id(11) is included in a Change-of- Authorization (COA) packet as described in [RFC3676]. Upon receiving the Filter-Id(11) the NAS starts to apply the rules specified by the Filter-Id(11)." I'm not sure why this document needs to discuss Filter-ID, which is not defined here. "As pointed out by [NASREQ] the use Filter-Id is not roaming friendly and it is recommended that instead one should use NAS- Filter-Rule(TBD) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS." What does "roaming friendly" mean? Filter-ID has been used in roaming for many years by cooperating parties. Perhaps the issue is requiring pre-established filters to be set on the NAS? This paragraph appears to be deprecating an existing RADIUS attribute without a clear justification.
[Mauricio]
I see this accounting attribute as adding basic audit capability to the authorization policy expressed through the NAS-Filter-Rule attribute. Surely you would agree that performing accounting/audit functions is well within scope of RADIUS. Accounting records already have data counts for session use, so why not have filter hit counts along with them? A straightforward use case is an administrator that has a (strict) filter policy for which he/she wishes to be notified anytime a user tries to pass unauthorized traffic through the NAS. Errant users could then be sanctioned in the future.
Proposed Resolution: Discuss
Issue 115: WG Last Call Comments Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00640.html Document: IEEE802-00 Comment type: T Priority: 1 Section: 1, 1.1, 2, 2.1, 3.5, 4.1 Rationale/Explanation of issue:
Section 1: Better phrasing. Requested changes: (1) Within the confines of RADIUS authentication, authorization, and accounting (AAA) environments, there is a general dearth of standardized RADIUS attributes to limit user access using dynamic VLANs, filters or redirection. Could we change "a general dearth of" to "a requirement for"? It sounds more positive. (2) IEEE 802.1X-2004 [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i]. Remove this sentence as it appears in the second paragraph as well. Section 1.1: The following definitions are not used in the draft: Access Point Association Station Requested change: Please delete them. Section 2: Better phrasing. Requested changes: (1) The first paragraph is awkwardly worded. Perhaps the following would be an improvement. In this section we provide an elaboration of the requirements briefly described in the Introduction. (2) For example, the user maybe on a prepaid plan and all the resources have been used up. Change "maybe" to "may be" and "resources have" to "credit balance has". (3) For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. Change "TCP users" to "IP users". (4) Change: As pointed out by [NASREQ] the use Filter-Id is not roaming friendly and it is recommended that instead one should use NAS- Filter-Rule(TBD) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS. To: As pointed out by [NASREQ] the use Filter-Id is not roaming friendly and it is recommended that instead one should adapt the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD) attribute. Section 2.1: This section seems out of place. 2.1 Capability Advertisement RADIUS does not currently define a method by which a NAS can advertise its capabilities and in many instances, it would be desirable for the home network to know what capabilities are supported by the NAS to ensure proper operational behavior. The attributes defined in this document are intended to be used to enforce policy by the NAS. If a NAS does not recognize these attributes it will most likely ignore them and the desired policy will not be enforced. A method for the NAS advertising the capability to support these attributes would help the RADIUS server understand if the intended policies can be enforced. As a result, the attributes in this document, in particular NAS-Filter- Rule(TBD), can benefit from capability advertisement, if available. Requested changes: Should this entire section perhaps be part of the Security Considerations? Section 3.5: Clarification of the text. Requested changes: Furthermore, the concatenated filter list must abide to the following rules of precedence and ordering: 1) A flush rule MUST appear before all other rule types. Change "A flush rule" to "A flush rule, when present,". 2) Base encapsulation filter rules MUST appear after a flush rule and before IP tunnel, HTTP redirect, IP filter, and/or HTTP filter rules. Change "a flush rule" to "any flush rule". dir "in" is from the terminal, "out" is to the terminal, "inout" is from and to the terminal. The term "terminal" is not defined in the draft. I suspect it identifies the network entity which contains the IEEE 802.1X Supplicant function, but this should perhaps be clarified. General comment: I'd much rather that we use ABNF to define the NAS-Filter-Rule formal syntax, however I'm not prepared to submit that text just now. :-) Section 4.1 4.1. Acct-NAS-Filter-Rule The first eight octets of this string are used for a 64-bit value of the rule counter. The remaining octets are used to specify which filter rule the counter value is for. The rule specification MUST conform to the syntax rules specified for NAS-Filter-Rule[TODO]. [TODO] indicates an open action item. Requested changes: Provide the [TODO].
[David Nelson]
All the items included in RADEXT Issues 115 and 116 have been resolved
in the draft-ietf-radext-ieee802-01.txt revision, with the exception of:
The term "terminal" is not defined in the draft. I suspect
it identifies the network entity which contains the IEEE
802.1X Supplicant function, but this should perhaps be
clarified.
This issue still exists in the -01 draft, in Section 2.5.[Mauricio Sanchez]
Yes, this is known. On 1/10/06 I wrote in response to your issue: "[ms] This sentence comes by way of the IPFilterRule description found in Diameter [RFC3588]. What would you suggest we do for RADIUS? Is terminal not a globally known term in RADIUS, if not, is there any? Perhaps can you suggest a definition to add to the terminology section. " I await your response.
[David Nelson]
Ah. Brain fade... Terminal may have been a well understood term in the days when RADIUS was just for Terminal Servers. I would recommend either substituting another term in the text, or creating a definition in the Terminology section. Perhaps "network device attached to the NAS port". You might also mention (in a definition) that "terminal" often means the "IEEE 802.1X Supplicant". Proposed Resolution: Discuss
Issue 116: Technical Comments Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00643.html Document: IEEE802-00 Comment type: T Priority: 0 Section: 2.2, 3.1 Rationale/Explanation of issue:
Section 2.2
Text appears to create retroactive normative requirements on existing
implementations.
Requested changes:
Change:
Similarly, if a NAS conforming to this specification receives a
CoA message that contains an attribute from this document that it
does not recognize or cannot apply, it MUST NOT terminate the
session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)
set to "Unsupported Attribute"(401).
To:
Similarly, if a NAS conforming to this specification and also
conforming to RFC 3576 [RFC3576] receives a CoA message that
contains an attribute from this document that it does not
recognize or cannot apply, it MUST NOT terminate the session and
MUST generate a CoA-NAK packet with Error-Cause (101) set to
"Unsupported Attribute"(401). Section 3.1
Integer
The Integer field is four octets in length. The format of the
Integer field consists of two parts, the first consuming high-
order octet and the second consuming the remaining three lower-
order octets. The high-order octet field indicates if the
VLANID is allowed for tagged or untagged packets. The second
part is the 12-bit 802.1Q VLAN VID value that has been padded
out to consume the remaining three lower-order octets. A
sample encoding follows:
This is not an Integer data type. It is a multi-field Octet String
(complex data type).
Requested changes:
Express a String data type (with sub-fields).[Emile van Bergen]
Disagree. Integers are not monotonic counters only. If two integers need to be tied together, are of fixed length and together fit in 4 octets, I see no reason not to use RADIUS integers. What's next, sending IPv4 addresses as a complex type consisting of 4 decimal variable length strings? I know we've always used a dedicated label for IP addresses in RADIUS dicationaries, but they are encoded and can be handled exactly the same as integers everywhere in the server, up to the point where you reach the very end of the chain, in modules that deal with ASCII representations.
[Paul Congdon]
We discussed the use of the Integer type for VLAN-ID field at IETF-64 and agreed to not change this to a string of octects as suggested by the issue resolution. It was also pointed out that the MIB uses an Integer to represent a VLAN-ID.
[David Nelson]
As long as we are only using the 12-bit VID part and not the other bit fields, using an integer is fine with me.
[Paul Congdon]
Yes, we are only using the 12-bit VID field.
Proposed Resolution: Accept
Issue 117: Transport Behavior 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: 2.1, 2.2 Rationale/Explanation of issue:
In at least two places, this document changes the basic transport behavior of RADIUS. If a RADIUS client does not receive a response from a RADIUS server, it retransmits the Request or fails over to another RADIUS server. A RADIUS client that automatically rejects user access without retransmission or failover is badly behaved. In general, a RADIUS server only silently discards a packet if it is invalid, such as a packet containing a Request Authenticator (Accounting) or Message-Authenticator attribute that does not verify. Unless there is a loading problem, silently discarding packets is a bad idea since the client will just retransmit or failover to another RADIUS server. If the Access-Request is valid but is requesting an unauthorized service, the correct response is an Access-Reject, not silent discard. In Section 2.1, Change: " The RADIUS server MAY have added a Digest-Nextnonce attribute into an Access-Accept message. If the RADIUS client discovers this, it puts the contents of this attribute into a 'nextnonce' directive. Now it can send an HTTP-style response. If the RADIUS client did receive an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header. If the RADIUS client receives an Access-Reject or no response from the RADIUS server, it sends an error response to the HTTP-style request it has received. The RADIUS client has three ways to obtain nonces: it generates them locally, it has received one in a Digest-Nextnonce attribute of a previously received Access-Accept message, or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. It adds a Message-Authenticator (see [RFC3579]) attribute to the Access-Request message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- Realm, Digest-Domain and Digest-Opaque attributes in the Access- Challenge carrying the nonce. If these attributes are present, the client MUST use them. If the RADIUS client receives an Access-Challenge message in response to an Access-Request containing a Digest-Nonce attribute, the RADIUS server did not accept the nonce. If a Digest-Stale attribute is present in the Access-Challenge and has a value of 'true' (without quotes), the RADIUS client sends an error (401 or 407) response containing WWW-/Proxy-Authenticate header with the directive 'stale' and the digest directives derived from the Digest-* attributes." To: " The RADIUS server MAY include a Digest-Nextnonce attribute within an Access-Accept message. A RADIUS client receiving a Digest-Nextnonce attribute places the contents of this attribute into a 'nextnonce' directive within a response sent to the HTTP-style client. If the RADIUS client receives an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header. If the RADIUS client receives an Access-Reject it sends an error response to the HTTP-style request it has received. If the RADIUS client does not receive a response, it retransmits or fails over to another RADIUS server as described in [RFC2865]. The RADIUS client has three ways to obtain nonces: it can generate them locally, it may receive a Digest-Nextnonce attribute within an Access-Accept message, or it may ask the RADIUS server to generate one. To do the latter, it sends an Access-Request containing Digest-Method and Digest-URI attributes, but without a Digest-Nonce attribute. The RADIUS client then adds a Message-Authenticator attribute to the Access-Request message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- Realm, Digest-Domain and Digest-Opaque attributes in the Access-Challenge carrying the nonce. If these attributes are present, the RADIUS client MUST use them. If the RADIUS client sends an Access-Request containing a Digest-Nonce attribute and receives an Access-Challenge message in response, the RADIUS server did not accept the nonce. If a Digest-Stale attribute is present in the Access-Challenge and has a value of 'true' (without quotes), the RADIUS client sends an error (401 or 407) response containing WWW-/Proxy-Authenticate header with the directive 'stale' and the digest directives derived from the Digest-* attributes." In Section 2.2, Change: " If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge message to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message- Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge message. If the server cannot choose a nonce, it replies with an Access-Reject message. If the RADIUS server receives an Access-Request message containing a Digest-Response attribute, it looks for the following attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque attribute. If mandatory attributes are missing, it MUST respond with an Access- Reject message. If the attributes are present, the RADIUS server calculates the digest response as described in [RFC2617]. To look up the password, the RADIUS server uses the RADIUS User-Name attribute. The RADIUS server MUST check if the user identified by the User-Name attribute o is authorized to access the protection space defined by the Digest-URI and Digest-Realm attributes, o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present. If any of those checks fails, the RADIUS server MUST send an Access- Reject. Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register or misuse a SIP-AOR allocated to another user. A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server silently discards the Access-Request message. Other actions taken by the RADIUS server are out of scope of this document. However, the RADIUS server should notify the operator and may take additional action such as discarding all future requests from this client, until some management action tells it to do so again. All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response attribute, the authentication was successful. If not, the RADIUS server responds with an Access-Reject." to: " If the RADIUS server receives an Access-Request message with Digest-Method and Digest-URI attributes, but without a Digest-Nonce attribute, sends an Access-Challenge message to the RADIUS client containing a nonce within a Digest-Nonce atribute. The RADIUS server MUST include Digest-Realm and Message-Authenticator attributes within the Access-Challenge and SHOULD include Digest-Algorithm and one or more Digest-Qop attributes. The RADIUS server MAY include Digest-Domain and Digest-Opaque attributes in the Access-Challenge message. If the server cannot choose a nonce, it replies with an Access-Reject message. If the RADIUS server receives an Access-Request message containing a Digest-Response attribute, it looks for the following attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- Hash, Digest-CNonce and Digest-AKA-Auts attributes; see [RFC2617] and [RFC3310] for details. If the Digest-Algorithm attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque attribute. If mandatory attributes are missing, the RADIUS server MUST respond with an Access-Reject. If the required attributes are present, the RADIUS server calculates the digest response as described in [RFC2617]. The RADIUS server determines the required credentials based on the contents of the User-Name attribute sent in the Access-Request. The RADIUS server MUST check if the user identified by the User-Name attribute: o is authorized to access the protection space defined by the Digest-URI and Digest-Realm attributes, o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present. If any of these checks fail, the RADIUS server MUST send an Access-Reject. Correlation between User-Name and SIP-AOR AVP values is required to prevent a user from registering or misusing a SIP-AOR allocated to another user. A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm provided in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server MUST send an Access-Reject. The RADIUS server SHOULD log the event so as to notify the operator, and MAY take additional action such as sending an Access-Reject in response to all future requests from this client, until this behavior is reset by management action. All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response attribute, the authentication was successful. If not, the RADIUS server responds with an Access-Reject."
Proposed Resolution: Accept
Issue 118: Editorial NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Section 1.1 HTTP-style protocol a protocol using HTTP digest, like HTTP, SIP. Change "a protocol" to "A protocol" The combination of realm and digest URI the use of which is authorized by the RADIUS server. Change "URI the" to "URI, the" Please include definitions of NAS, UA and UAS in the terminology section. Section 1.3 "digest into the message" -> "digest within the message" Change: " Instead of maintaining a local user database, the server could use RADIUS. However, RADIUS does not support HTTP digest without an extension like the one described in this document. The RADIUS client can not send a User-Password attribute as it does not receive a password from the HTTP-style client. The RADIUS mechanism for CHAP resembles HTTP digest, but the digest algorithms are not compatible. This document extends RADIUS to support Digest Authentication, via addition as a native authentication mechanism. An implementation supporting this extension MUST include a Digest-Response attribute within an Access-Request packet where Digest authentication is desired. An Access-Request MUST NOT contain both a Digest-Response attribute and another authentication attribute, such as User- Password, CHAP-Password, or EAP-Message. This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617]." To: " Instead of maintaining a local user database, the server could use RADIUS. However, RADIUS [RFC2865] does not include support for HTTP digest authentication. The RADIUS client can not use the User-Password attribute, since it does not receive a password from the HTTP-style client. The CHAP-Challenge and CHAP-Password attributes are also not suitable since the CHAP algorithm is not compatible with HTTP digest. This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617], providing support for Digest Authentication as a native authentication mechanism within RADIUS. An implementation supporting this extension MUST include a Digest-Response attribute within an Access-Request packet where Digest authentication is desired. An Access-Request MUST NOT contain both a Digest-Response attribute and another authentication attribute, such as User- Password, CHAP-Password, or EAP-Message." Change: " The nonces required by the digest algorithm are either generated by the RADIUS client or by the RADIUS server. A mix of nonce generation modes is not supported. RADIUS clients and servers can support one, or both nonce generation modes. If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. The nonce generation mode is a configurable parameter" To: " The nonces required by the digest algorithm are either generated by the RADIUS client or by the RADIUS server. A mix of nonce generation modes is not supported. RADIUS clients and servers can support one, or both nonce generation modes. If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. The nonce generation mode is a configurable parameter." Section 1.3.1 change "without authorization header" to "without an authorization header" in this section. "If credentials were accepted B" -> "If credentials were accepted, B" Section 1.3.2 change: " In most cases, the operation outlined in Section 1.3.1 is sufficient. It reduces the load on the RADIUS server to a minimum. However, when using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector. These authentication vectors are often stored centrally. Figure 3 depicts a scenario, where the RADIUS server chooses nonces. It shows a generic case where entities A and B communicate in the front-end using protocols such as HTTP/SIP, while entities B and C communicate in the back-end using RADIUS." To: " While the usage scenario described in Section 1.3.1 minimizes the load on the RADIUS server, alternatives are required in some situations. When using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector, which is often stored centrally. Figure 3 depicts a scenario in which the RADIUS server chooses nonces. In this case entities A and B communicate in the using HTTP or SIP, while entities B and C communicate using RADIUS." Change: " The relevant order of messages sent in this scenario is as follows:" to: " The following messages are sent in this scenario:" Section 2.1 The first paragraph seems a bit awkard. Does this really belong in Section 2.1, or might it belong in the Security Considerations Section? Change: " If the messages between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients (or else the HTTP-style clients would have a false sense of security)." To: " The attributes described in this document are sent in cleartext. Therefore were a RADIUS client to accept secured connections (https or sips) from HTTP-style clients, this could result in information intentionally protected by HTTP-style clients being sent in the clear during the RADIUS exchange. If the messages between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients, so that HTTP-style clients are not provided with a false sense of security." Change: " On reception of an HTTP-style request message, the RADIUS client checks whether it is responsible to authenticate the request. There are situation where an HTTP-style request traverses several proxies, and each of the proxies request to authenticate the HTTP-style client. In this situation, it is a valid scenario that a HTTP-style request received at a HTTP-style server contains several sets of credentials. The 'realm' directive in HTTP is the key that the RADIUS client can use to determine which credential is applicable. It may happen also that none of the realms are of interest to the RADIUS client, in which case the RADIUS client MUST consider that no credentials (of interest) were sent. In any case, a RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header where the realm directive matches its locally configured realm value. If such a header is present and contains HTTP digest information, the RADIUS client checks the 'nonce' parameter. If the RADIUS client generates nonces but did not issue the received nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to the HTTP-style client. In this error response, the RADIUS client sends a new nonce. If the RADIUS client recognizes the nonce or does not generate nonces, it takes the header directives and puts them into a RADIUS Access-Request message. It puts the 'response' directive into a Digest-Response attribute and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc / username / opaque directives into the respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- Username / Digest-Opaque attributes. The request method is put into the Digest-Method attribute. The RADIUS clients adds a Message- Authenticator (see [RFC3579]) attribute. Now, the RADIUS client sends the Access-Request message to the RADIUS server. The RADIUS server processes the message and responds with an Access- Accept or an Access-Reject message." To: "On reception of an HTTP-style request message, the RADIUS client checks whether it is authorized to authenticate the request. Where an HTTP-style request traverses several proxies and each of the proxies request to authenticate the HTTP-style client the request at the HTTP-style server may contain multiple credential sets. The RADIUS client can use the 'realm' directive in HTTP to determine which credentials are applicable. Where none of the realms are of interest, the RADIUS client MUST behave as though no relevant credentials were sent. In all situations the RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its locally configured realm. If such a (Proxy-)Authorization header is present and contains HTTP digest information, the RADIUS client checks the 'nonce' parameter. If the RADIUS client generates nonces but did not issue the received nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to the HTTP-style client. In this error response, the RADIUS client sends a new nonce. If the RADIUS client recognizes the nonce or does not generate nonces, it takes the header directives and puts them into a RADIUS Access-Request message. It puts the 'response' directive into a Digest-Response attribute and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc / username / opaque directives into the respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- Username / Digest-Opaque attributes. The request method is put into the Digest-Method attribute. The RADIUS client adds a Message- Authenticator attribute, defined in [RFC3579] and sends the Access-Request message to the RADIUS server. The RADIUS server processes the message and responds with an Access- Accept or an Access-Reject."
Proposed Resolution: Accept
Issue 119: More NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
General: RADIUS RFCs use the term "packet" to refer to RADIUS Access-Request, Challenge, Accept and Reject messages, not "message". Please change "message" to "packet" throughout the document. Section 3 The term 'HTTP-style' denotes any protocol that uses HTTP-like headers and uses HTTP digest authentication as described in [RFC2617]. Examples are HTTP and SIP. Why is this here? Shouldn't this be moved to the terminology section? Section 3.1 Change: " If this attribute is present in an Access-Request message, the RADIUS server MUST view the Access-Request as a Digest one." to: " If this attribute is present in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication." Change: "The attribute proves the user knows the password and MUST only be used in Access-Requests." To: "This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Requests" Change: " When using HTTP digest, the text field is 32 octets long and contains hexadecimal representation of 16 octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without quotes." To: " When using HTTP digest, the text field is 32 octets long and contains a hexadecimal representation of the 16 octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without quotes." Section 3.3 Change: " This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access-Challenge message. This attribute MUST only be used in Access-Request and Access-Challenge messages." to: " This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access-Challenge message. This attribute MUST only be used in Access-Request and Access-Challenge messages." Section 3.4 Change: " This text proves the RADIUS server knows the password. If the previously received Digest-Qop attribute was 'auth-int' (without quotes), the RADIUS server MUST send a Digest-HA1 attribute instead of Digest-Response-Auth. The Digest- Response-Auth attribute MUST only be used in Access-Accept messages. The RADIUS client puts the attribute value without quotes into the rspauth directive of the Authentication-Info header." To: " This attribute enables the RADIUS server to prove possession of the password. If the previously received Digest-Qop attribute was 'auth-int' (without quotes), the RADIUS server MUST send a Digest-HA1 attribute instead of a Digest-Response-Auth attribute. The Digest-Response-Auth attribute MUST only be used in Access-Accept messages. The RADIUS client puts the attribute value without quotes into the rspauth directive of the Authentication-Info header." Section 3.11 Change: " This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access- Request messages.u" To: " This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access- Request messages." Section 3.13 Change: " This attribute holds the user name parameter that is used in the HTTP digest calculation. The RADIUS server MUST NOT use this value for password finding, but only for digest calculation purpose. In order to find the user record containing the password, the RADIUS server MUST use the value of the ([RFC2865] -)User-Name attribute. This attribute MUST only be used in Access-Request packets." To: " This attribute holds the user name used in the HTTP digest calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS server MUST use the User-Name (1) attribute, and MUST NOT use the Digest-Username attribute. This attribute MUST only be used in Access-Request packets." Section 3.15 Change: " If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute and each instance MUST contain one different unknown Digest parameter/ value combination. This attribute MUST ONLY be used in Access-Request, Access- Challenge, or Access-Accept messages." To: " If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute and each instance MUST contain one different unknown Digest parameter/ value combination. This attribute MUST ONLY be used in Access-Request, Access-Challenge, or Access-Accept messages." In Section 3.20, change: "However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request messages." To: "However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used in Access-Request messages, when the RADIUS client wants to authorize SIP users." Section 4 Please remove Section 4 (Migration Path to Diameter) as was discussed at IETF 63. Section 5 Please reformat the attribute table in the format used in other RADIUS RFCs, such as RFC 2865 Section 5.44: The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name 0-1 0 0 0 2 User-Password [Note 1]
[Wolfgang Beck]
Bernard wrote: > Section 2.1 > > .. Change .. To: > Where an HTTP-style request traverses several proxies and each of the > proxies requests to authenticate the HTTP-style client the request at > the HTTP-style server may contain multiple credential sets. I've added a comma after "HTTP-style client": "Where an HTTP-style request traverses several proxies and each of the proxies requests to authenticate the HTTP-style client, the request at the HTTP-style server may contain multiple credential sets." > Section 5 > > Please reformat the attribute table in the format used in > other RADIUS RFCs, such as RFC 2865 Section 5.44: > > The following table provides a guide to which attributes may > be found in which kinds of packets, and in what quantity. > > Request Accept Reject Challenge # Attribute > 0-1 0-1 0 0 1 User-Name > 0-1 0 0 0 2 User-Password [Note 1] > Two remarks: - Placing the attribute name in the last column seems a bit strange to me - The xml2rfc tool adds borders to the table and I haven't found a way to disable this. Replacing the table with ASCII art is an option, but it wouldn't look good in xml2rfc's html output (and I don't know how the tool handles page breaks with large ascii art).
I'm a reasonably new user of xlm2rfc, but I have chosen to use the artwork solution to preserve traditional ASCII RFC text formatting. I suspect that I have done this that the expense of the HTML version of the document. I haven't found another solution, however.
Proposed Resolution: Accept
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 is 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."
Proposed Resolution: Accept
Issue 121: Data Representation 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: 3.5 Rationale/Explanation of issue:
In Section 3.5, it says: " Text It is recommended that this text be base64 or hexadecimal data." For interoperability, you need to choose the representation or at least specify how it can be determined which representation is to be used.
[Wolfgang Beck]
I've used the description in RfC 2617, Section 3.2.1 "nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this string be base64 or hexadecimal data. " As the nonce is only interpreted by the nonce generator, interoperability is not required.
[David Nelson] The proposed resolution is as follows:
Perhaps adding that last sentence, of some variant, to the text of the draft would clarify that this is an opaque (to RADIUS) nonce, in which case its encoding is not required to be specified to obtain interoperability. In that case the attribute value should perhaps be String, with the advisory that robust implementations shout treat it as undistinguished octets.
Proposed Resolution: Accept
Issue 122: Editorial Comments Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 16, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00666.html Document: DIGEST-03 Comment type: 'E' Editorial Priority: '1' Should fix Section: 1.1, 1.3, 2.1, 4.1, 4.2. 4.3 (1) Rationale/Explanation of issue: 1.1 Terminology This document includes many instances of the normative keywords. It does not clarify that the usage applies only to RADIUS Clients and Server that implement the digest authentication feature described in the document. While this may be obvious to some, certain text would appear to be creating retroactive normative requirements on existing implementations. Requested changes: Add the following text at the end of Section 1.1: "The use of normative requirement key words in this document shall apply only to RADIUS Client and RADIUS Server implementations that include the features described in this document. This document creates no normative requirements for existing implementations." (2) Rationale/Explanation of issue: Typographical errors. Requested Changes: 1.3 Overview In the fourth paragraph: s/where Digest authentication is/where Digest Authentication is/ In the eighth paragraph: s/a configurable parameter/a configurable parameter./ 2.1 RADIUS Client Behavior In the second paragraph: s/are situation where/are situations where/ s/MUST send zero or exactly one/MUST send exactly zero or one/ (3) Rationale/Explanation of issue: Confusing text. The third paragraph contains the phrase "If the RADIUS client recognizes the nonce...". This could use some clarification. The definition of "nonce" in Section 1.1 is "An unpredictable value...". How is it possible for the RADIUS client to recognize an unpredictable value? Does this simply that the RADIUS client maintains a history of recently used nonce values? Or is there another meaning? Requested changes: Please add clarification. (4) Rationale/Explanation of issue: Move Diameter gateway considerations to the Diameter SIP Application draft. 4.1 RADIUS Client Diameter Server 4.1 Diameter Client, RADIUS Server 4.3 Limitations Requested Changes: Delete these sections and add a general reference to the Diameter SIP draft. This presumes, of course, that consensus is concurrently obtained in the AAA WG to make this change.
[David Nelson]
All aspects of RADEXT Issue 122 have been resolved in the -04 draft, except for the following: (1) > The third paragraph contains the phrase "If the RADIUS client recognizes > the nonce...". This could use some clarification. The definition of > "nonce" in Section 1.1 is "An unpredictable value...". How is it > possible for the RADIUS client to recognize an unpredictable value? > Does this simply that the RADIUS client maintains a history of recently > used nonce values? Or is there another meaning? > > Requested changes: > > Please add clarification. I think what this text is trying to say is that: "If the RADIUS client recognizes the presence of an HTTP Digest nonce data element..." What is being recognized is the data element, not the content of the data element. (2) > Move Diameter gateway considerations to the Diameter SIP Application > draft. > > 4.1 RADIUS Client Diameter Server > 4.1 Diameter Client, RADIUS Server > 4.3 Limitations > > Requested Changes: > > Delete these sections and add a general reference to the Diameter SIP > draft. This presumes, of course, that consensus is concurrently > obtained in the AAA WG to make this change. The delete part was accomplished, but the reference to the compatibility description to appear in the Diameter SIP Application draft was not added. RADEXT WG work items must have *some* form of Diameter Compatibility section, so at least a reference is required.
Proposed Resolution: Accept
Issue 123: Mandatory Modes of Operation Submitter name: Miguel Garcia Submitter email address: Miguel.An.Garcia@nokia.com Date first submitted: August 18, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00670.html Document: DIGEST-03 Comment type: T Priority: 1 Section: 1.2 Rationale/Explanation of issue:
The draft contains two modes of operation, in one the nonces are generated in
the RADIUS client,
in the other, nonces are generated in the RADIUS
server.
The text reads:
"RADIUS clients and servers can support one,
or both nonce generation modes."
So how is interoperability going to be
granted if a RADIUS client implements only one mode and
the RADIUS server
implements the other?
In my opinion what has been pursued here is to not
add additional complexity to the implementation.
But the generation of a
nonce does not add almost any complexity, so I would say that both modes
have to be supported in the sake of interoperability.
In addition to
that, the text does not have a normative statement (only speaks about "can").
The text should be normative, and should be placed outside the Overview
section, which is
informative by nature.
Requested change:
Add
the following text elsewhere (Section 2?):
"RADIUS clients and servers
MUST implement support for the two modes of operation: when nonces
are
generated in the RADIUS server and when nonces are generated in the RADIUS
client."
And delete the existing text in Section 1.3
"RADIUS
clients and servers can support one, or both nonce generation modes."
Proposed Resolution: Discuss
Issue 124: Digest Requirements for RADIUS Clients Submitter name: Miguel Garcia Submitter email address: Miguel.An.Garcia@nokia.com Date first submitted: August 18, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00671.html Document: DIGEST-03 Comment type: T Priority: 1 Section: 1.2 Rationale/Explanation of issue:
The text imposes a requirement for RADIUS client that is both unimplementable and untestable. The text reads: "If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. " The text seems to suggest that if a RADIUS server is generating a nonce then the RADIUS client must make sure that it does not generate a nonce. These seems to imply a sequence where first the RADIUS server does an action (generate or not a nonce), and then the RADIUS client does a consequent action (not generate or generate a nonce). However, the sequence of events (see the scenarios in Sections 1.3.1 and 1.3.2) is that it is the RADIUS client the first entity that has to decide whether to generate a nonce or not (I assume that based on configuration), and then the RADIUS server can operate consequently. Requested change: I see two possibilities here, please choose one. Possibility 1: ============== To describe that the RADIUS servers and clients do not verify whether a nonce has been previously generated by the correspondent node. However, this must be pre-agreed and pre-configured before operation. In this case, I suggest to delete the text above mentioned and add the following: "This specification assumes that both the RADIUS client and server are appropriately configured to generate the nonces in either the RADIUS client or the RADIUS server, but not in both at the same time. Implementations, though, do not have the means to verify this behaviour." Possibility 2: ============== To enforce that nonces are generated appropriately. I have my doubts whether this is achievable or not, espcially considering the case of HTTP Digest authentication using AKA (RFC 3310), because it requires to generate nonces always in the RADIUS server. In addition to this, we would need to consider the error cases and the recovery from them. If someone wants to pursue this track, please provide text for discussion.
Proposed Resolution: Discuss
Issue 125: Request Authenticator Validation in RFC 2866
Submitter name: Alan DeKok
Submitter email address: aland@ox.org
Date first submitted: August 12, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00663.html
Document: FIXES-00
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:
The text defining the Response Authenticator for Accounting-Response
packets says that "invalid packets are silently discarded", but no
such text exists for the Request Authenticator in Accounting-Request
packets.
Suggested fix: Add following text to "issues & fixes draft"
RFC 2866, Section 4.1 says:
Request Authenticator
The Request Authenticator of an Accounting-Request contains a 16-octet
MD5 hash value calculated according to the method described in
"Request Authenticator" above.
The text is incomplete, as it does not indicate any action to take
when an Accounting-Request packet contains an invalid Request
Authenticator. The following text should be considered to be part of
the above description:
The Request Authenticator field MUST contain the correct data,
as given by the above calculation. Invalid packets are silently
discarded. Note that some early implementations always set the
Request Authenticator to all zeros. New implementations of RADIUS
clients MUST use the above algorithm to calculate the
Request Authenticator field. New implementations of RADIUS servers
MUST silently discard invalid packets.
We may also want to add a note to the Security Considerations
section of the "Issues and fixes" draft. RADIUS server
implementations which accept a Request Authenticator of all zeros are
subject to various attack scenarios.Proposed Resolution: Discuss
Issue 126: Unresolved NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 29, 2005 Reference: Document: DIGEST-04 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Section 4.4:
possesion -> possession
Section 4.14:
ie -> i.e.
Section 5:
Change:
Req Accept Reject Challenge # Attribute 1 0 0 0 TBD User-Name 1 1 1 1 TBD Message-Authenticator
To:
Req Accept Reject Challenge # Attribute 1 0 0 0 1 User-Name 1 1 1 1 80 Message-Authenticator
Section 9
"/or" -> "for"
References
[RFC2616] is not referenced.
[RFC1750] is not referenced.
Proposed Resolution: Discuss
Issue 127: Diameter Compatibility Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 29, 2005 Reference: Document: DIGEST-04 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
The Diameter Compatibility section has vanished completely. Yet the WG charter requires that every RADEXT WG document include *some* discussion of this issue. My recommendation is that a short Section be added along the following lines: "5. Diameter Compatibility This document defines support for Digest Authentication in RADIUS. A companion document "Diameter Session Initiation Protocol (SIP) Application" [I-D.ietf-aaa-diameter-sip-app] defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter."
Proposed Resolution: Discuss
Issue 128: RFC 3576 MIB Comments Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 29, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00756.html Document: RFC3576-MIBs-01 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Some comments on draft-ietf-radext-dynauth-client-mib-01.txt. Most of these comments also apply to the dynauth-server-mib document. The initial sections could use some re-organization. My suggestion is to start the document with Section 2 - Introduction. Section 1 (Requirements) would become Section 1.1, and Terminology would become Section 1.2. Section 2 (Introduction) refers to RFC 2619 and 2621. It should also probably refer to the RFC 2619bis and RFC 2621bis documents. To address some of the terminology confusion, my suggestion is that the Terminology section be rewritten as follows: "1.2 Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS which processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component which sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. While often residing on the RADIUS server, it is also possible for this component to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client." Section 5 Rewrite the first paragraph: "5. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-Request, CoA-ACK and CoA-NAK packets. [DYNSERV] defines the Dynamic Authorization Server MIB and the relationship with other MIB modules. This MIB module for the Dynamic Authorization Client contains the following:" Capitalization The term "authenticator" is inconsistently capitalized.
[Murtaza Chiba] Thanks Bernard, we will take care of these comments.
[Inderpreet Singh] 2. Page 6 - Section Terminology, para 2 there is a small typo. On line 3 of para 2, change "itand" to "it and"
Proposed Resolution: Discuss
Issue 129: Editorial NITs Submitter name: Paul Congdon Submitter email address: paul_congdon@hp.com Date first submitted: August 10, 2005 Reference: Document: IEEE802-00 Comment type: E Priority: 1 Section: Various Rationale/Explanation of issue:
1. Pg 3, end of second paragraph. Seems like a reference to RFC3580 would be appropriate 2. Pg 3, middle of sixth paragraph. We aren't providing the 'full set' of VLAN functionality either. Suggest replacing "...the full set of VLAN functionality" with "...a more complete set of VLAN functionality as defined by IEEE 802.1Q-2003" 3. Pg 3, end of sixth paragraph. Reference to IEEE-802.1Q should probably be the Bridge-MIB or RFC 2674 4. Pg 4. The following terms aren't really used and should be removed; Access Point (AP), Association, Port Access Entity (PAE), Stations (STA). 5. Pg 10, 3.4 User-Priority-Table. The reference to 802.1D should probably be 802.1D-2004. 6. Pg 10, 3.4 User-Priority-Table, 1st paragraph of String. There are 8 regenerated priorities, not 7. 7. Pg 12, First item 2). The way this item is worded it makes it sound like you must have a flush rule present and as the first item. Suggest rewording as follows: Base encapsulation filter rules MUST appear after a flush rule (if present) and before IP tunnel,... 8. Pg 12, first paragraph after list. If you only wanted to filter specific traffic, but allow other stuff you would want the list to end with an 'accept all' rule. The behavior we have defined is more of a firewall type behavior rather than a router behavior. We should document a syntax for the 'accept all' rule and make a note to the implementer of how to do this. Suggest adding a note that describes how to terminate the list with a rule that allows all traffic. I believe the rule is: permit both ip from any to any. We may need an L2 rule as well.
9. Pg 12, last paragraph on Filter-ID and NAS-Filter-Rule. The paragraph is clumsy. Suggest replacing the start of the second sentence with, "These attributes are not intended to be used..." 10. Pg 15, Note: at top of page. Seems like a missing word or something in the second sentence. Suggest, "Also, [ports] optional argument is not valid for ..." 11. Pg 17, Editorial note in Text section. I think you can just delete this now. Isn't the text about fragmenting these below? 12. Pg 23, end of page. RFC 2866 and RFC 2867 are normative, but never referenced. Perhaps we should be referencing them somewhere or move them to informative references. Also, IEEE802.11i reference should be IEEE80211i (all one word - no dot). 13. Pg 28, Acknowledgments. Since all the wireless stuff has been removed, we can remove Dorothy Stanley of Agere from this list of names. Requested change: 1. Change ending of last sentence to "...based on tunnel attributes in [RFC2868] and usage of these in [RFC3580]." 2. Replace "...the full set of VLAN functionality" with "...a more complete set of VLAN functionality as defined by IEEE 802.1Q-2003" 3. Replace "...to the MIB variables supported in [IEEE 802.1Q]." with "...to the management variables supported in IEEE 802.1Q-2003 and MIB objects defined by RFC 2674. 4. Remove Access Point (AP), Association, Port Access Entity (PAE), Stations (STA). 5. Change 802.1D to IEEE 802.1D-2004 6. Change 'seven' to 'eight' in the first sentence of the Text description 7. Change the start of item 2) to, "Base encapsulation filter rules MUST appear after a flush rule (if present) and before IP tunnel,..." 8. Add a note to the text that describes how to terminate the list with a rule that accepts everything else. Perhaps the rule is: "permit both ip from any to any" 9. Replace the start of the second sentence with, "These attributes are not intended to be used..."
10. Replace start of second sentence with, "Also, [ports] optional argument is not valid for ..." 11. Remove editorial note 12. Move RFC 2866 and RFC 2867 to informative section or reference them somewhere normatively. Also fix the typo in the 802.11i reference. 13. Remove Dorothy Stanley of Agere from this list of names.
Proposed Resolution: Discuss
Issue 130: Diameter Compatibility Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 29, 2005 Reference: Document: IEEE802-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
The document does not contain a Diameter Compatibility section, as required by the RADEXT WG charter. In reviewing the document, there appears to a major compatibility problem between this document and Diameter NASREQ (RFC 4005). The NAS-Filter-Rule attribute defined in the document is not compatible with the NAS-Filter-Rule attribute defined in RFC 4005, which is based on the IPFilterRule type defined in RFC 3588. This incompatibility will break RADIUS/Diameter gateways.
[Jari Arkko] This is a problem. My suggestion is to define the restrict the NAS-Filter-Rule attribute to the RFC 3588 syntax, and define additional attributes for other purposes, such as Layer 2 filtering and HTTP redirect. It is ok if the same general syntax is used for these other filters, but they need to be defined as separate attributes to enable translation of NAS-Filter-Rule AVP from RADIUS to Diameter and back.
[Jari Arkko] Sounds like a good suggestion to me.
[John Loughney] I agree. Bernard's proposal seems reasonable.
[Mauricio Sanchez]
Say we did break out NAS-Filter-Rule into multiple attributes, each with its own type value. How would I be able to guarantee strict ordering, given that RADIUS proxies do not have to preserve order for attributes of different types? Maintenance of order is vital.
Proposed Resolution: Discuss
Issue 131: Capability Attribute Rationale and Scenarios Unclear Submitter name: Emile van Bergen Submitter email address: openradius-radextwg@e-advies.nl Date first submitted: September 10, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00824.html Document: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt Comment type: T Priority: S Section: 8 Rationale/Explanation of issue: From the text: "8. Capability Attribute The capability attribute allows the RADIUS client to indicate whether civic and/or geospatial location information can be provided to the RADIUS server. This is useful to avoid sending location information with every request if no further out-of-band arrangements are made with regard to the transport of location information. The AAA server uses the capability attribute to indicate that the AAA client has to provide civic and/or geospatial location information as part of this particular protocol exchange. If the AAA server does not send a capability attribute then the AAA client MUST NOT return location information. The user's authorization policies MUST be consulted by the AAA server before requesting location information delivery from the AAA client. If the AAA server encounters that the AAA client does not support the desired location information it might respond with an Access-Reject with the corresponding error cause attribute (with the Location-Info-Required error code)." The reason to avoid sending location information is not clear. From the rest of the document, it would appear that the sending of location information is entirely conditional on the user's policy, not on any other consideration. In RADIUS, the RADIUS client can only learn about the user's policy from RADIUS responses to an access request. So I would suggest to put the following text somewhere: "Without prior knowledge of the user's policy, the RADIUS client MUST NOT send Location attributes in an Access Request. If the home RADIUS server requires location information for authentication and has permission from the user, it sends an Access- Challenge containing Location-Info-Required to request the information, upon which the RADIUS client will reissue its Access Request, including the Location attributes (and echoing the State attribute as per RFC 2865). If the home RADIUS server does not require location information to perform its authentication, but the user's policy allows location information to be transmitted by the RADIUS client, the RADIUS server informs the RADIUS client of that policy in the Access Accept packet." It seems there's no capability negotiation needed, and as RADIUS servers are currently not required to keep any dynamic per-client data, leave alone per-NAS data, that should only be added when absolutely required.
Proposed Resolution: Discuss
Issue 132: Must Proxy-State be Copied by the NAS? Submitter name: Jim Martin Submitter email address: jim@daedelus.com Date first submitted: September 12, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00841.html Document: RFC3576bis Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
I have a question regarding RFC3576, specifically the behavior of the Proxy-State attribute when contained in a Disconnect Message. Fundamentally, the question is, if a Disconnect-Request is received by a NAS which contains a Proxy-State, MUST the NAS copy this Proxy- State into the associated Disconnect-Response? While there is no /explicit/ statement that says "Proxy-state must be preserved by the client receiving the Disconnect-Request", there are a couple of places where it is clearly implied. First in section 2.3, in discussing the behavior of forwarding proxies with respect to these messages, it says:
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy- State, State, or Class Attributes present in the packet. To me, this seems a clear implication that the NAS would include the proxy-state in the response, and hence the need for text to specify that it must be removed by the proxy. This is further supported by the following excerpt from the table in Section 3.2: Disconnect Messages Request ACK NAK # Attribute [text deleted] 0+ 0+ 0+ 33 Proxy-State Do you (jointly or severally) agree with my assessment? Clarification would be very helpful.
[Emile Bergen]
I completely agree -- the NAS has server role in this exchange, and just like Proxy-State MUST be echoed by the server for Access-Request and Accounting-Request packets, it MUST be echoed by the NAS for Disconnect-Request (and other RFC3576 messages where the NAS functions as the server), for exactly the same reasons. The situation seems quite symmetrical to me.
[Bernard Aboba] The proposed resolution is to add the following text to Section 2.3:
" If there are any Proxy-State Attributes in a Disconnect-Request or
CoA-Request received from the server, the forwarding proxy MUST
include those Proxy-State Attributes in its response to the
server.
A forwarding proxy MUST NOT modify existing Proxy-State, State, or
Class Attributes present in the packet. The forwarding proxy MUST
treat any Proxy-State attributes already in the packet as opaque
data. Its operation MUST NOT depend on the content of Proxy-State
attributes added by previous proxies. The forwarding proxy MUST
NOT modify any other Proxy-State Attributes that were in the
packet; it may choose not to forward them, but it MUST NOT change
their contents. If the forwarding proxy omits the Proxy-State
Attributes in the request, it MUST attach them to the response
before sending it.
When the proxy forwards a Disconnect or CoA-Request, it MAY add a
Proxy-State Attribute, but it MUST NOT add more than one. If a
Proxy-State Attribute is added to a packet when forwarding the
packet, the Proxy-State Attribute MUST be added after any existing
Proxy-State attributes. The forwarding proxy MUST NOT change the
order of any attributes of the same type, including Proxy-State.
Other Attributes can be placed before, after or even between the
Proxy-State Attributes.
When the proxy receives a response to a CoA-Request or Disconnect-
Request, it MUST remove its own Proxy-State (the last Proxy- State
in the packet) before forwarding the response. Since Disconnect
and CoA responses are authenticated on the entire packet contents,
the stripping of the Proxy-State Attribute invalidates the
integrity check - so the proxy needs to recompute it."
Proposed Resolution: Accept
Issue 133: State Attribute in "Authorize-Only" Requests Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 12, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00842.html Document: RFC3576bis Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
RFC 2865 Section 4.1 says: "An Access-Request MUST contain either a User-Password or a CHAP-Password or a State." This statement is subsequently updated in other RADIUS RFCs to also include additional authentication attributes (e.g. EAP-Message or Digest attributes). So it appears that an an Access-Request without authentication attributes or State attribute is illegal. Since an Access-Request with Service-Type "Authorization-Only" does not include authentication attributes, under RFC 2865, this message needs to include a State attribute. RFC 3576 indicates that 0-1 State attributes may be included in CoA or Disconnect Request, ACK or NAK messages, and RFC 3576 Section 3.2, Note 7 describes the use of the State attribute:
[Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA- Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect- Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject.
However, RFC 3576 does not state that a State attribute is REQUIRED in a Disconnect or CoA-Request with Service-Type = "Authorize Only", nor does it state that an Access-Request with Service-Type = "Authorize Only" MUST include a State attribute.
[Avi Lior] I might be missing something. A NAS would only have State attribute to send in an Access-Request Authorize-Only if it received the State attribute in the COA or DM. [Note 1] in section 5.44 Table of Attributes in 2865 may also be wrong since a NAS can only include the State attribute in an Access-Request if it received one in the Challenge that it is replying to. So shouldn't it be that: The NAS MUST include the State attribute in an DM ACK, DM NAK, COA ACK, COA NAK and Access-Request Authorize-Only message if it received the State attribute in the COA or DM message.
[Bernard Aboba]
Yes, a NAS can only have a State attribute to send in an Access-Request with Service-Type = "Authorize-Only" if one was included in the CoA or Disconnect-Request. It is also true that the NAS MUST include the State Attribute in the CoA/Disconnect ACK, NAK as well as Authorize-Only Access-Request if it received the State attribute in a Coa or Disconnect-Request. However, since an Access-Request without either an authentication attribute or State attribute appears to be illegal under RFC 2865, if the a CoA/Disconnect-Request with Service-Type="Authorize-Only" doesn't include a State attribute, then the ensuing Access-Request could be rejected by the RADIUS server.
[Bernard Aboba] The proposed resolution is as follows:
Add the following text to Section 2.1:
" A NAS supporting the "Authorize Only" Service-Type within a Disconnect-Request responds with a Disconnect-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". The NAS will then send an Access-Request containing a Service-Type Attribute with a value of "Authorize Only", along with a State Attribute. The RADIUS server MUST reply to this Access-Request with an Access-Reject."
Add Section 3.1:
"3.1. State
[RFC2865] Section 5.44 states:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
In order to satisfy the requirements of [RFC2865] Section 5.44, an
Access-Request with Service-Type="Authorize-Only" MUST contain a
State attribute.
In order to provide a State attribute to the NAS, a server sending a
CoA-Request or Disconnect-Request with a Service-Type value of
"Authorize-Only" MUST include a State Attribute, and the NAS MUST
include the State Attribute unchanged in the Access-Request. A NAS
receiving a Disconnect or CoA-Request containing a Service-Type value
of "Authorize-Only" but lacking a State attribute MUST send a
Disconnect or CoA-NAK and SHOULD include an Error-Cause attribute
with value 402 (Missing Attribute)."
Change Note 7 in Section 3.5 to the following:
" [Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA- Request then a State Attribute MUST be present, and MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access- Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA- Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client performs the Termination- Action by sending a new Access-Request upon termination of the current session, it MUST include the State Attribute unchanged in that Access-Request. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect- Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject."
Proposed Resolution: Accept
Issue 134: Comments
Submitter name: Bert Wijnen
Submitter email address: bwijnen@lucent.com
Date first submitted: September 15, 2005
Reference: https://psg.com/lists/radiusext/2005/msg00866.html
Document: RFC2618bis-2621bis
Comment type: T
Priority: S
Section: 7
Rationale/Explanation of issue:
radiusMIB OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The OID assigned to RADIUS MIB work by the IANA."
::= { mib-2 67 }
radiusAuthClientExtMIB OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The OID assigned to RADIUS Extensions MIB work by
the IANA."
::= { mib-2 TBA }
-- RFC Editor: replace TBA with IANA assigned OID value, and
-- remove this note.
Why do we need/want 2 OID branches underneath mib-2?
Why can the extensions not be made just within the radiusAuthClientMIB
branch itself?
Requested change:
Delete the new "TBA" roots under MIB-2 (for example
radiusAuthClientExtMIB) and locate the extended (new) MIB objects as the
next available OIDs under the existing IANA assignment for the
respective MIB.> C:\bwijnen\smicng\work>smicng radiusAuthClient.inc > W: f(radiusAuthClient.mi2), (29,20) Revision date not in > proper order - most recent comes first > W: f(radiusAuthClient.mi2), (27,20) The first revision > should match the last update for MODULE-IDENTITY > radiusAuthClientMIB Requested change: Locate the latest revision at the top of the revision history list.
[Bert Wijnen]
By the way, the DESCRIPTION clause of a REVISION should contain a description of the (major) changes to the MIB module.
Did anyone do MIB SYNTAX checking ... [David Nelson] I used this tool to check the MIB syntax: http://wwwsnmp.cs.utwente.nl/ietf/mibs/validate/
Proposed Resolution: Discuss
Issue 135: Must Obsolete old MIBs Submitter name: Jari Arkko Submitter email address: Jari.Arkko@piuha.net Date first submitted: September 15th, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00853.html Document: 2618-2621bis Comment type: E Priority: S Section: header Rationale/Explanation of issue:
The document "Updates RFC 2618" but as far as I can determine, it contains all the objects from 2618 and then adds some. If so, why isn't the designation "Obsoletes RFC 2618"?
Requested change:
Change this (or these) documents to obsolete their previous versions, rather just update them. s/Updates 26/Obsoletes 26/
Proposed Resolution: Discuss
Issue 136: Typos Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 4, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00929.html Document: RFC2486bis-06 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
Here are some typos in RFC 2486bis that should be fixed in AUTH48:
Section 2.3:
Change:
"In some situations NAIs are are used together with a separate"
To:
"In some situations NAIs are used together with a separate"
Section 2.4
Change:
" The realm part internationalization is
based on International Domain Name (IDN) [RFC3490].
To:
"Internationalization of the realm portion of the NAI is based on
'Internationalizing Domain Names in Applications (IDNA) [RFC3490]."
Change:
"Similarly, we expect domain name comparisons,
matching, resolution, and AAA routing to be performed on the ASCII
versions of the international domain names. "
To:
"Similarly, we expect domain name comparisons,
matching, resolution, and AAA routing to be performed on the ASCII
versions of the internationalized domain names. "
Section 2.8
Change:
" alice@xn--tmonesimerkki-bfbb.example.net
\(user\)@example.net
The last example uses an IDN converted into an ASCII representation."
To:
"
\(user\)@example.net
alice@xn--tmonesimerkki-bfbb.example.net
The last example uses an IDN converted to an ASCII representation."Proposed Resolution: Accept
Issue 137: Session Counters Submitter name: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: September 28, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00920.html Document: RFC3576MIBs Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
Glen Z., has suggested the addition of counters in the event where the Session Context is not found for the RFC3576 MIBS. This requires the addition of 4 objects, one each for DM and CoA messages for both the client and server MIBs. There is a good need for this as NAKs could be sent for Diameter RAR capabilities, in which case the NAK is not an error condition. Other Error Cause codes will not have corresponding counters. There is a security concern that the counter may provide information valuable for attacks. The authors would like to get the general feel for this. Alternative, is to maintain a counter for requests that are for Diameter RAR capabilities.
[Bernard Aboba]
I think this makes sense. > Other Error Cause codes will not have corresponding counters. There is a security concern that > the counter may provide information valuable for attacks. The authors > would like to get the general feel for this. Presumably access is only being provided to the SNMP manager, correct? I would focus on whether the information is useful rather than whether it is security-sensitive. There is probably some value in tracking error messages by DAC and DAS, so as to see if there is a problem with a client or server. For example, if an error 501 is being returned by a DAC (Administratively Prohibited), this could represent a security problem that needs to be addressed (e.g. someone is trying to send unauthorized Disconnect-Requests). I'm note sure whether the way to do this is via counters or potentially an error message table. > Alternative, is to maintain a counter for requests that are for Diameter RAR capabilities. I do think it may make sense to count "Authorization Only" CoA and Disconnect-Requests.
[Murtaza Chiba]
So, basically we want a table of Error counters? Or do we want something just for "Unknown Session Identifier"? Plus we need an object to count NAKs for Diameter RAR.
Proposed Resolution: Discuss
Issue 138: HTTPS/SIPS Security Submitter name: Miguel Garcia Submitter email address: miguel.an.garcia@nokia.com Date first submitted: September 21, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg00893.html Document: DIGEST-05 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
I was revising the RADIUS Digest authentication draft, to find out missing features that should be transposed to the Diameter SIP app. On doing this exercise I came to a paragraph on the RADIUS Client section that reads: If the packets between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients, so that HTTP-style clients are not provided with a false sense of security. I think this paragraph is not totally correct, and deserves a bit more of discussion. Here are my thoughts: First, I don't like the idea that a RADIUS draft (soon to be RFC) puts a normative statement to non-RADIUS protocols, namely HTTP(RFC 2616/17) and SIP (RFC 3261). I am referring to the sentence that reads "... the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients ...". At least in the Diameter SIP application we have put a lot of effort to just define the behaviour of the Diameter client, not the SIP server or SIP User Agent that is co-located with the Diameter client. In your document, even when the text says "the RADIUS client" it is not correct, because it refers to refusing an HTTP or SIP session, which takes place outside the RADIUS client, presumably in an HTTP/SIP server. The second thing is that you are (IMHO) wrongly overloading the semantics of at least the SIPS URI, which is clearly defined in RFC 3261: "A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. " Notice that a SIPS URI has nothing to do with the mechanism whereby a SIP proxy authenticates a user who has created some SIP request, and has nothing to do with the security of protocols beyond SIP. Notice even that the semantics of the SIPS URI does not mean that TLS is in every two hops from the caller to the callee, but rather that TLS is used from the caller to ***the domain of the callee*** (from them onwards, there could be anything). Similar things apply to HTTP, where I don't expect that the TLS security between the client and the server is mixed up with the security in the network to authorize the client's requests. So do people have an opinion on this topic? In my opinion the above paragraph should be deleted from the current section. I think you can add some discussion of the threats and provide recommendations in the Security Consideration sections, but the current text is not acceptable (it is not even implementable, since it does not affect RADIUS). [Bernard Aboba]
I think I agree with Miguel that the security of the RADIUS exchange is a somewhat orthogonal issue from the security of the HTTP/SIP Digest exchange. For example, the RADIUS exchange may occur over a different network than the HTTP/SIP exchange, which may be more or less vulnerable. Just because the SIP UA doesn't request TLS, or sends a registration request over a wireless network, does that mean there is no need to secure the RADIUS exchange? Or because the SIP UA does request TLS, does that mean that it is also attempting to negotiate RADIUS security at the same time? My recommendation would be to unlink the HTTP/SIP and RADIUS exchanges. If you want to recommend encryption to protect Digest attributes that is ok, but I wouldn't mention HTTPS/SIPS exchanges in the same paragraphs and link them together. Proposed Resolution: Accept
Issue 139: Nonce Attribute Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 10, 2005 Reference: Document: RFC3576bis-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
It has been pointed out that the replay protection mechanisms recommended in RFC 3576 may be difficult to deploy. For example, the Event-Timestamp attribute requires time synchronization between the RADIUS server and NAS. In roaming situations this would require all networks between the RADIUS server and NAS to be running NTP, synchronized to the same clock. Similarly, IPsec with replay protection may not be deployable on all hops in the path. To provide more deployable replay protection it has been suggested that a Nonce attribute be introduced. This attribute would be sent by the DAC in a CoA/Disconnect-Request. If the DAS understands the attribute it would be copied into the CoA/Disconnect ACK/NAK (possibly along with another Nonce-attribute inserted by the DAS). The Nonce attribute could also be used to enhance replay protection in Accounting-Request packets. Since the receiver of the packet with a Nonce attribute doesn't need to understand it, this attribute is backward compatible with existing RFC 3576 implementations.
[Bernard Aboba]
The proposed resolution is as follows: Add the following text to Section 1.1: " Existing implementations lack replay protection. In order to support replay detection, it is recommended that a Nonce or Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. See Section 6.4 for details." Change the last two paragraphs of Section 3 to the following: " Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request, attributes representing an authorization change MUST NOT be included; only NAS or session identification attributes are permitted, as well as Service-Type, Nonce and State attributes. If other attributes are included in such a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. A Disconnect-Request MUST contain only NAS and session identification attributes (see Section 3), as well as Service-Type, Nonce and State attributes. If other attributes are included in a Disconnect- Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included." Add Section 3.2: "3.3. Nonce Description Since the Request Authenticator field within CoA-Request Disconnect-Request packets does not contain a nonce, these packets are vulnerable to replay attack without the countermeasures described in Section 6.4. As noted in Section 6.4, replay attacks can be addressed by using IPsec to protect RADIUS or by adding an Event-Timestamp attribute to CoA and Disconnect-Request packets. Since use of the Event-Timestamp Attribute requires time synchronization, where this is not possible an alternative replay protection mechanism is required. For this purpose, a Nonce Attribute MAY be included within CoA-Request, Disconnect-Request, and Accounting-Request packets. A summary of the Nonce Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for Nonce Length 6 Value The Value field is four octets, containing a randomly chosen value [RFC4086]." Add the following entries to the Attribute Table (Section 3.5) for both Disconnect and CoA messages: " 0-1 0-1 0-1 TBD Nonce [Note 8] [Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or Disconnect-Request packet that is not protected by IPsec or does not contain an Event-Timestamp Attribute, so as to prevent replay attacks. A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK, Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets."
Proposed Resolution: Accept
Issue 140: Review of RADIUS MIBs Submitter name: Alan DeKok Submitter email address: aland@ox.org Date first submitted: November 11, 2005 Reference: Document: RFC2618bis-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
There's a typo on Page 12, radiusAuthServerInetAddress ... the version neutral IP adddess format." ^ The same typo exists in rfc2619bis page 14, rfc2620bis page 11, and rfc2621bis page 13. rfc2619bis, radiusAuthServConfigReset has MAX-ACCESS of read-write. Yet the "Security Considerations" section says: There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. This text should be updated to reflect the MAX-ACCESS clause in radiusAuthServConfigReset. rfc2621bis has the same issue. I suggest re-using the text from the first paragraph of RFC 2619, section 6. Other than that, the documents look OK.
Proposed Resolution: Accept
Issue 141: State Attribute Submitter name: David Mitton Submitter email address: david@mitton.com Date first submitted: November 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html Document: Fixes-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:wrt State attribute; there was a case in the past where a vendor decided that their client would sent a State attribute with Null data to start a certain proprietary sequence. Non-Vendor's clients would fail on this server due to this expectation.
You should make it clear that a new Access-Request should not contain a State attribute. State should always come from a server, and prior context. Not manufactured by the client.
[Bernard Aboba] How about this:
"Since a State attribute is always initially provided by the server in
an
Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request, a
RADIUS
client MUST NOT insert a State attribute that it has not previously
received
from the server."
Proposed Resolution: Accept
Issue 142: Framed-IPv6-Prefix Attribute
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: November 4, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg01019.html
Document: Fixes-01
Comment type: T
Priority: S
Section: New
Rationale/Explanation of issue:
Section 2.3 of RFC 3162 states:
This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same
prefix.
This raises several issues:
a. What is the expected behavior of the NAS on receiving
Framed-IPv6-Prefix? Is the NAS expected to use the prefix only on the link
between itself and the CPE? b. Does the receipt of a Framed-IPv6-Prefix imply that the NAS is supposed to announce the prefix using RS? Or does this require allocation of a new value of Framed-Routing?
c. Since the prefix length can be between 0 and 128, can Framed-IPv6-Prefix be used to send a /128? What does the NAS do in that case? What if the NAS also receives a Framed-Interface-Id attribute?
Here are my (strawman) answers:a. The NAS plumbs a route for the prefix. It also advertises the prefix via RS/RA. The NAS does not do anything else unless it is explicitly told to do so (e.g. in Framed-Routing).
b. Yes. A new value of Framed-Routing is not required to cause the prefix to be announced via RS. Framed-Routing is intended to be used only with routing protocols (primarily RIPv2), rather than with RS/RA or Prefix Delegation.
c. Framed-IPv6-Prefix can be used to send a /128. If received, the NAS will plumb a route for the prefix. However, it will not announce the /128 via RS, only the /64. If the NAS also receives a Framed-Interface-ID attribute it will use it if the protocol involved requires an Interface-ID (e.g. PPP). Otherwise, it will ignore the attribute.
[Bernard Aboba]
To kick off the review of draft-salowey-radext-delegated-prefix-01.txt, I thought I would post my (admittedly imperfect) understanding of what the problem is, why this document is necessary, and what (if anything) is wrong with RFC 3162.RFC 3633 describes the basic scenario for use of prefix delegation: The model of operation for prefix delegation is as follows. A delegating router is provided IPv6 prefixes to be delegated to requesting routers. Examples of ways in which the delegating router may be provided these prefixes are given in Section 12.2. A requesting router requests prefix(es) from the delegating router, as described in Section 12.1. The delegating router chooses prefix(es) for delegation, and responds with prefix(es) to the requesting router. The requesting router is then responsible for the delegated prefix(es). For example, the requesting router might assign a subnet from a delegated prefix to one of its interfaces, and begin sending router advertisements for the prefix on that link. Each prefix has an associated valid and preferred lifetime, which constitutes an agreement about the length of time over which the requesting router is allowed to use the prefix. A requesting router can request an extension of the lifetimes on a delegated prefix and is required to terminate the use of a delegated prefix if the valid lifetime of the prefix expires. This prefix delegation mechanism would be appropriate for use by an ISP to delegate a prefix to a subscriber, where the delegated prefix would possibly be subnetted and assigned to the links within the subscriber's network. The use of RADIUS is described in Section 11.2: The mechanism through which the delegating router selects prefix(es) for delegation is not specified in this document. Examples of ways in which the delegating router might select prefix(es) for a requesting router include: static assignment based on subscription to an ISP; dynamic assignment from a pool of available prefixes; selection based on an external authority such as a RADIUS server using the Framed- IPv6-Prefix option as described in RFC 3162 [5]. Ralph's presentation from IETF 64 is located here: http://www.drizzle.com/~aboba/IETF64/radext/ietf64_radext_Delegation.pdfAs I understand it, the issue occurs when an ISP desires to support Prefix Delegation at the same time that it would like to assign a prefix for the link between the NAS and CPE. In this situation, the sematics of Framed-IPv6-Prefix are unclear: what prefixes are to be used for delegation, and which one is to be used for the link?
Here is what RFC 3162 says about Framed-IPv6-Prefix:
This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same
prefix.
In this case the user is the CPE. The intent of the paragraph was to
enable the NAS to advertise the prefix (such as via a Router Advertisement). If
the Framed-Routing attribute is used, it is also possible that the prefix would
be advertised in a routing protocol such as RIPNG. RFC 2865 Section 5.10
describes the purpose of Framed-Routing: This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept
packets.
The Value field is four octets.
0 None
1 Send routing packets
2 Listen for routing packets
3 Send and Listen
The description of the Prefix-Length field in RFC 3162 indicates
(excessively?) wide latitude: The length of the prefix, in bits. At least 0 and no larger than 128.In my opinion, this is somewhat too broad, because it is not clear to me what a NAS should do with a prefix of greater granularity than /64. For example, what if Framed-IPv6-Prefix contains a /128? Does this imply that the NAS should be assigning an IPv6 address to the CPE? I think the answer to that is no, because RFC 3162 already defines a Framed-IPv6-Identifier attribute to handle the Identifier portion.
In any case, it appears to me that the statement that "Framed-IPv6-Prefix is intended for assignment to the link between NAS and CPE" is only true if a /64 prefix is assigned. When a larger prefix is sent, the intent was to provide the entire prefix to the CPE, enabling the CPE to assign sub-prefixes if it wished to do so.
Proposed Resolution: Discuss
Issue 143: RFC 3576 MIB Review Submitter name: Alan DeKoK Submitter email address: aland@ox.org Date first submitted: November 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01043.html Document: RFC3576MIBs-02 Comment type: E Priority: S Section: Various Rationale/Explanation of issue:
draft-ietf-radext-dynauth-client-mib-02.txt
Nits: 1) There are references to "Disconnect messages" and "CoA messages" (radiusDynAuthClientDisconInvalidServerAddresses, radiusDynAuthClientCoAInvalidServerAddresses, and maybe others). While this terminology is used in RFC 3576, it would be good to be consistent with Section 3 of the document, the other MIB entries, and use "Disconnect-Request packet" and CoA-Request packet". See also radiusDynAuthServerDisconInvalidClientAddresses and radiusDynAuthServerCoAInvalidClientAddresses in the server MIB. The radiusDynAuthServDupDisconRequests refers to "Disconnect-Request packets", for example. 2) radiusDynAuthServerAddress has a description of "IP address value...", but it's missing a phrase used in the 26**bis documents: "..., using the version neutral IP adddess format." See also radiusDynAuthClientAddress in the server MIB. I suggest adding that to be consistent with other RADIUS MIBs. 3) Similarly, radiusDynAuthServerID talks about the NAS-Identifier, but is missing text that's in RFC 2619, and rfc2619bis: "This is not necessarily the same as sysName in MIB II." See also radiusDynAuthServerIdentifier in the server MIB. Question: Is this text relevant? 4) radiusDynAuthClientMalformedCoAResponses talks about "CoA-Response packets", but no such packets are defined in RFC 3576 (barring a diagram on page 6). I would suggest using explicit "CoA-ACK" and CoA-NAK", but rfc2618bis uses "Access-Response" in the same manner. And the text in radiusDynAuthClientCoAPendingRequests uses "CoA-Ack, CoA -NAK" explicitly. (And there's an extra space in CoA-NAK) I'm not sure what to suggest here. Either leave it as-is, or change both this and rfc2618bis. --- draft-ietf-radext-dynauth-server-mib-02.txt See comments above. Also, page 4, references to [RFC2618bis] and [DYNCLIENT] don't have RFC editor notes to replace the text with the final RFC numbers. I don't know if such a note is necessary.
Proposed Resolution: Accept
Issue 144: Minor Editorial NITs Submitter name: Greg Weber Submitter email address: http://by106fd.bay106.hotmail.msn.com/cgi-bin/compose?curmbox=00000000-0000-0000-0000-000000000005&a=e5cf394c12ca3d454cb958bf15cbafa3cd24fc3aeff36c1839a5f02594ce22bd&mailto=1&to=gdweber@cisco.com&msg=9EFCD6D0-FD1C-4EB2-AF2C-6B899575B728&start=0&len=3967&src=&type=x Date first submitted: November 9th, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01044.html Document: RFC2618bis-01 Comment type: 'E' Editorial Priority: '2' May fix Section: See below Rationale/Explanation of issue: Typos Length description of problem:
I reread the docs. They look fine to me with the exception of the typos mentioned below (some of which Alan has already mentioned).
Requested changes:
draft-ietf-radext-rfc2618bis-01.txt
p10, radiusAuthClientPendingRequests: Acess -> Access
p12, radiusAuthServerInetAddress: adddess -> address
p14, radiusAuthClientExtPendingRequests: Acess -> Access
p17, Section 9: MAX-\nACCESS -> MAX-ACCESS
(See Section 2.1, #3 of http://www.ietf.org/ID-Checklist.html)
p18, Section 9: IPSec -> IPsec
draft-ietf-radext-rfc2619bis-01.txt
p14, radiusAuthClientInetAddress: adddess -> address
p19, Section 9: MAX-\nACCESS -> MAX-ACCESS
p19, Section 9: IPSec -> IPsec
draft-ietf-radext-rfc2620bis-01.txt
p11, radiusAccServerInetAddress: adddess -> address
p16, Section 9: MAX-\nACCESS -> MAX-ACCESS
p17, Section 9: IPSec -> IPsec
draft-ietf-radext-rfc2621bis-01.txt
p13, radiusAccClientInetAddress: adddess -> address
p18, Section 9: MAX-\nACCESS -> MAX-ACCESS
p18, Section 9: IPSec -> IPsecProposed Resolution: Accept
Issue 145: Minor Editorial NITs Submitter name: Greg Weber Submitter email address: http://by106fd.bay106.hotmail.msn.com/cgi-bin/compose?curmbox=00000000-0000-0000-0000-000000000005&a=e5cf394c12ca3d454cb958bf15cbafa3cd24fc3aeff36c1839a5f02594ce22bd&mailto=1&to=gdweber@cisco.com&msg=3DB7858E-0C7D-4667-A806-44230478E04F&start=0&len=3974&src=&type=x Date first submitted: November 9th, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01045.html Document: RFC3576MIBs-02 Comment type: 'E' Editorial Priority: '2' May fix Section: See below Rationale/Explanation of issue:
I reread the docs. They look fine to me with the exception of the typos mentioned below.
Requested changes:
draft-ietf-radext-dynauth-server-mib-02.txt
p7, radiusDynAuthServerMIB:
Remote Access Dialin User Service ->
Remote Authentication Dial In User Service
p11, radiusDynAuthServDisconAuthOnlyRequests:
Autorize -> Authorize
p12, radiusDynAuthServDisconNakAuthOnlyRequests:
Autorize -> Authorize
p14, radiusDynAuthServCoAAuthOnlyRequests:
Autorize -> Authorize
p15, radiusDynAuthServCoANakAuthOnlyRequests:
Autorize -> Authorize
p19, radiusDynAuthServerAuthOnlyGroup:
Autorize -> Authorize
p21, Section 5: IPSec -> IPsec
draft-ietf-radext-dynauth-client-mib-02.txt
p1, Abstract: RFC3576 -> RFC 3576
p10, radiusDynAuthClientDisconAuthOnlyRequests:
Autorize -> Authorize
p11, radiusDynAuthClientDisconNakAuthOnlyRequest:
Autorize -> Authorize
p14, radiusDynAuthClientCoAAuthOnlyRequest:
Autorize -> Authorize
p15, radiusDynAuthClientCoANakAuthOnlyRequest:
Autorize -> Authorize
p19, radiusDynAuthClientAuthOnlyGroup:
Autorize -> Authorize
p21, Section 5: IPSec -> IPsecProposed Resolution: Accept
Issue 146: Statistics Errors Submitter names: Nagi R Jonnala, Stefaan De Cnodder Submitter email address: njonnala@cisco.com, stefaan.de_cnodder@alcatel.be Date first submitted: July 30th, 2004 Reference: https://psg.com/lists/radiusext/2004/msg00650.html
Document: RFC2618bis-2621bis Comment type: 'T'echnical | Priority: '1' Should fix Section: Various Rationale/Explanation of issue: I realized that the issue we raised long back as mentioned in the below thread is not resolved in the Radius IPv6 drafts and could be resolved. I would like to resolve these statistics misunderstandings once and for all. Could you please review if my understanding match with your interpretations.
Issue-1: Stefaan asked: > Some questions we have regarding the existing RFCs (since you are > updating these) we found while writing our draft: > > 1) Is the definition o TotalIncomingPackets in RFC2618 on page 6 > correct? I believe there is something wrong with it. Glen replied: I think that you are right. With the curent definition, it appears that "Successfully Received" could be negative, since we're subtracting counters from TotalIncomingPackets that were not include in the sum. Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts = Successfully Received" just below should read "AccessRequests + PendingRequests + ClientTimeouts = Successfully Transmitted". Nagi commented: My understanding is that RFC-2618 considers that an Access Response (Accept or Reject or Challenge) counter MUST be incremented before it is validated. i.e., either one of Malformed responses or bad authenticators or packets dropped counters will be incremented if the packet is invalid. Do you interpret the same from the RFC-2618. If yes, I would like to know what are the reasons for this. Isn't that an Access Response counter MUST be incremented only after the packet is found *valid*.
If you are convinced that the approach in RFC-2618 is OK, then I would say that the first two equations hold good. i.e., Your statement above (saying Successfully_Received could be negative) is incorrect. Am I right? or missing something? Issue-2: Stefaan asked: > 3) radiusAuthClientPendingRequests: upon retransmission this counter > is decremented. So a retransmitted packet is not considered as being > pending, although such restransmissions can still be considered as > being pending requests. Glen replied: Yup, it probably shouldn't be decremented on retransmissions, especially since it's already decremented on timeouts. Nagi commented: My understanding is that Pending requests should be decremented on receiving an Access response and on an expiry of timeout. It looks obvious to me that Pending requests should be incremented on a retransmission (to the same server). Please see the text "This variable is incremented when an Access-Request is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout or retransmission."
I suspect that the text is misleading. The text should be: "This variable is incremented when an Access-Request and retransmission is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout " Do you guys agree? Issue-3: See the equation: AccessRequests + PendingRequests + ClientTimeouts = Successfully Received I agree with you that left hand side value should be equal to "Successfully Transmitted". Also "AccessRequests + AccessRetransmissions = Successfully Transmitted" equation holds good. Right? Requested changes: Nagi and Stefaan raised the issue and suggested some text to resolve the issue in the above thread. Please note that a conclusion was not reached and can be discussed now.
[Alan DeKoK]
The following is proposed text to resolve ISSUE 146. If there are no
comments, the text will be included in the next revision of the document.
---
2.3.6. Counter values in the RADIUS MIBs
The RADIUS Authentication and Authorization Client MIB module
[RFC2618], [RFC4668] includes counters of packet statistics. In the
descriptive text of the MIB module, formulas are given to relative
the values of certain counter objects. Several commenters have noted
that there appear to be inconsistencies in the formulas, as under
certain circumstances negative values would seem to result.
Discussion of these issues in the RADIUS Extensions Working Group did
not bring about a consensus as to whether or not changes to the MIB
module were warranted, and thus the formulas were included unmodified
in the revised MIB module [RFC4668]. The original MIB module
[RFC2618] has been widely implemented.
The issues raised can be summarized as follows:
Issue (1):
-- TotalIncomingPackets = Accepts + Rejects + Challenges +
UnknownTypes
--
-- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
-- UnknownTypes - PacketsDropped = Successfully received
--
-- AccessRequests + PendingRequests + ClientTimeouts =
-- Successfully Received
It appears that the value of "Successfully Received" could be
negative, since various counters are subtracted from
TotalIncomingPackets that are not included in the calculation of
TotalIncomingPackets.
It also appears that "AccessRequests + PendingRequests +
ClientTimeouts = Successfully Received" should read "AccessRequests +
PendingRequests + ClientTimeouts = Successfully Transmitted".
"TotalIncomingPackets" and "Successfully Received" are temporary
variables, i.e. not objects within the MIB module. The comment text
in the MIB modules is intended, therefore, to aid in understanding.
What's of consequence is the consistency of values of the objects in
the MIB module, and that does not appear to be impacted by the
inconsistencies noted above. It does appear, however, that the
"Successfully Received" variable should be labeled "Successfully
Transmitted".
In addition, the definition of Accept, Reject or Challenge counters
indicates that they MUST be incremented before the message is
validated. If the message is invalid, one of MalformedResponses,
BadAuthenticators or PacketsDropped counters will be additionally
incremented. In that case the first two equations are consistent,
i.e. "Successfully Received" could not be negative.
Issue (2):
It appears that the radiusAuthClientPendingRequests counter is
decremented upon retransmission. That would mean a retransmitted
packet is not considered as being as pending, although such
retransmissions can still be considered as being pending requests.
The definition of this MIB object in [RFC2618] is as follows:
The number of RADIUS Access-Request packets destined for this
server that have not yet timed out or received a response. This
variable is incremented when an Access-Request is sent and
decremented due to receipt of an Access-Accept, Access-Reject or
Access-Challenge, a timeout or retransmission.
This object purports to count the number of pending request packets.
It is open to interpretation whether or not retransmissions of a
request are to be counted as additional pending packets. In either
event, it seems appropriate to treat retransmissions consistently
with respect to incrementing and decrementing this counter.
In summary, this document provides guidance for implementers,
regarding the interpretation of the textual descriptions and comments
for certain MIB objects, but does not recommend revisions to the MIB
modules.
[Bernard Aboba]
Generally, this looks OK. Some suggestions: Change: " The RADIUS Authentication and Authorization Client MIB module [RFC2618], [RFC4668] includes counters of packet statistics. In the descriptive text of the MIB module, formulas are given to relative the values of certain counter objects. Several commenters have noted that there appear to be inconsistencies in the formulas, as under certain circumstances negative values would seem to result. Discussion of these issues in the RADIUS Extensions Working Group did not bring about a consensus as to whether or not changes to the MIB module were warranted, and thus the formulas were included unmodified in the revised MIB module [RFC4668]. The original MIB module [RFC2618] has been widely implemented." To: " The RADIUS Authentication and Authorization Client MIB module [RFC2618], [RFC4668] includes counters of packet statistics. In the descriptive text of the MIB module, formulas are provided for certain counter objects. Implementers have noted apparent inconsistencies in the formulas, which could result in negative values. Since the original MIB module specified in [RFC2168] had been widely implemented, the RADEXT WG chose not to change the object definitions or create new ones within the revised MIB module [RFC4668]. However, this section explains the issues and provides guidance for implementers regarding the interpretation of the textual descriptions and comments for certain MIB objects." You can delete the following paragraph: " In summary, this document provides guidance for implementers, regarding the interpretation of the textual descriptions and comments for certain MIB objects, but does not recommend revisions to the MIB modules."
[Alan DeKok]
> Some suggestions: OK. I have no objection.
Proposed Resolution: Accept
Issue 147: Add RFC 3411 Reference for SnmpAdminString Submitter names: Nagi R Jonnala Submitter email address: njonnala@cisco.com Date first submitted: November 13, 2005 Reference: Document: RFC2618bis - 26821bis Comment type: 'T'echnical | Priority: '1' Should fix Section: References Rationale/Explanation of issue:
SNMP-FRAMEWORK-MIB (for SnmpAdminString) is defined in RFC 3411 and should be added as a normative reference for all four RADIUS IPv6 drafts.
Proposed Resolution: Accept
Issue 148: MIB Review Submitter names: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: November 13, 2005 Reference: Document: RFC2618bis - 26821bis Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
At the request of the Operations and Management Area Director I read
again the documents. Here are my findings:
General
1. It is bad to have the following defined in multiple documents:
radiusMIB OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The OID assigned to RADIUS MIB work by the IANA."
::= { mib-2 67 }
radiusAuthentication OBJECT IDENTIFIER ::= {radiusMIB 1}
These should be defined in the MIB module in one document only, say
draft-ietf-radext-rfc2618bis-01.txt and imported in the other MIB
modules.
I remember having made this comment previously ... Or maybe I am
confusing?
2. All MIB modules include deprecated IPv4 tables and new IPv4/IPv6
tables. In the case when both the older deprecated IPv4 tables and the
new IPv4 / IPv6 tables are supported in agents for backwards
compatibility reasons, is there any relationship between the indexation
of the two tables?
3. What does the following text present in all documents mean?
Managed entities SHOULD NOT instantiate the deprecated table
containing IPv4-only address objects when the RADIUS server address
represented in the table row is not an IPv4 address. Managed
entities SHOULD NOT return inaccurate values of IP address or SNMP
object access errors for IPv4-only address objects in otherwise
populated tables.
Does this mean that if there is at least one address that is not an IPv4
address the whole deprecated table will not be implemented, or does this
mean that only instances that do not correspond to IPv4 addresses are
not implemented, but the table exists and includes rows only for IPv4
instances?
4. It would be helpful if UNITS clauses would be added where applicable
to objects with a SYNTAX of Counter32
5. It would be helpful if REFERENCE clauses would be added to the
definition of objects that have a direct mapping on RFC 2865. For
example the definition of the radiusAuthClientExtAccessRequests object
in draft-ietf-radext-rfc2618bis-01.txt should include a REFERENCE clause
that points to RFC 2865, Section 4.1.
6. All MIB modules include objects that refer to malformed requests and
malformed responses (radiusAuthClientExtMalformedAccessResponses,
radiusAuthServTotalMalformedAccessRequests,
radiusAuthServExtMalformedAccessRequests,
radiusAccClientExtMalformedResponses, etc.). I could not find a
definition of 'malformed' in RFC 2865.Some definitions refer to length,
but the definitions need to be clear and consistent.
7. As the documents define MIB modules referring to various aspects of
the instrumentation of RFC 2865, and RFC 2866, I believe that one
cannot implement these documents without understanding and implementing
relevant portions of RFC 2865 or RFC 2866. In consequence, [RFC2865]
should be Normative Reference for RFC 2618-bis and RFC 2619-bis and
[RFC2866] should be Normative Reference for RFC 2620-bis and RFC
2621-bis, rather than Informative.
8. RFC 3411 needs to be added to the Normative References because
SnmpAdminString is imported from SNMP-FRAMEWORK-MIB
9. The Security Considerations sections in the documents are not aligned
with the latest boilerplate described in
http://www.ops.ietf.org/mib-security.html.
Specifically the last paragraph in each Section needs to be replaced
with the following:
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. I believe that the DESCRIPTION clauses of the MODULE-COMPLIANCE
modules need to be harmonized with the content of the sections
describing the Deprecated objects. The DESCRIPTION of the deprecated
module should mention that these modules are for IPv4 entities only,
while the current modules support both IPv4 and IPv6.
draft-ietf-radext-rfc2618bis-01.txt
1. idnits has no problem with this I-D.
2. smilint complains about:
smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2618bis.txt
rfc2618bis.txt:15: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration
This is because of the root registration issue that was discussed on the
radext mailing list, and the WG decided to keep the root of the MIB
modules under the administration of the WG, and not of IANA.
I do not like this, but I can live with it.
3. The acronym NAS shows up for the first time in Section 5 of the
document without being expanded.
4. Section 5 includes the following text:
Each entry in the RADIUS Authentication Server Table includes sixteen
columns presenting a view of the activity of the RADIUS
authentication client.
Actually the first column is not-accessible, representing the index of
the table. There are only fifteen accessible columns for each entry.
draft-ietf-radext-rfc2619bis-01.txt
1. idnits has no problem with this I-D.
2. smilint complies about:
smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2619bis.txt
rfc2619bis.txt:11: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration
This is because of the root registration issue that was discussed on the
radext mailing list, and the WG decided to keep the root of the MIB
modules under the administration of the WG, and not of IANA.
I do not like this, but I can live with it.
3. The Abstract section should shortly define the scope of the MIB, and
not only mentions that it updates RFC 2619.
4. Section 5 includes the following text:
Each entry in the RADIUS Authentication Client Table
includes thirteen columns presenting a view of the activity of the
RADIUS authentication server.
One of the columns is actually an un-accessible index, so only twelve of
the columns present a view of the activity of the clients.
5. The statement made in the Security Consideration section that the MIB
does not include any object with a read-write MAX-ACCESS is not
accurate. The radiusAuthServConfigReset has a MAX-ACCESS of read-write,
and the Security Consideration sections needs to include the description
of the security hazards related to the intentional or non-intentional
incorrect manipulation of this object, as well as the boilerplate text
related to writeable objects.
6. radiusAuthServConfigReset - is reset(2) the only writeable value for
this object? If so, this needs to be mentioned in the DESCRIPTION
clause, and the desired behavior of the agent if a different value is
entered must be described.
draft-ietf-radext-rfc2620bis-01.txt
1. idnits has no problem with this I-D.
2. smilint complies about:
smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2620bis.txt
rfc2620bis.txt:16: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration
I do not like this, but I can live with it.
3. The Abstract section should shortly define the scope of the MIB, and
not only mentions that it updates RFC 2619.
4. The acronym NAS shows up for the first time in Section 5 of the
document without being expanded.
5. Section 5 includes the following text:
Each entry in
the RADIUS Accounting Server Table includes fifteen columns
presenting a view of the activity of the RADIUS client.
One of the columns is actually an un-accessible index, so only fourteen
of the columns present a view of the activity of the clients.
draft-ietf-radext-rfc2621bis-01.txt
1. idnits complains about:
tmp/draft-ietf-radext-rfc2621bis-01.txt(595): Line has weird spacing:
'...invalid authe...'
tmp/draft-ietf-radext-rfc2621bis-01.txt(789): Line has weird spacing:
'...invalid authe...'
2. smilint complies about:
smilint -m -s -e -m -s -l 6 -i namelength-32 rfc2621bis.txt
rfc2621bis.txt:13: [4] {module-identity-registration} warning:
uncontrolled MODULE-IDENTITY registration
I do not like this, but I can live with it.
3. Section 5 includes the following text:
Each entry in the RADIUS Accounting Client Table includes twelve columns
presenting a view of the activity of the RADIUS accounting server
.One of the columns is actually an un-accessible index, so only eleven
of the columns present a view of the activity of the clients.
4. The statement made in the Security Consideration section that the MIB
does not include any object with a read-write MAX-ACCESS is not
accurate. The radiusAccServConfigReset has a MAX-ACCESS of read-write,
and the Security Consideration sections needs to include the description
of the security hazards related to the intentional or non-intentional
incorrect manipulation of this object, as well as the boilerplate text
related to writeable objects.
Overall I believe that the documents are in a reasonable shape. They
can be forwarded to the IESG for consideration as Proposed or
Informational, either with a list of known problems, or (better) after a
short editing round to fix the problems detected during the WGLC.Proposed Resolution: Discuss
Issue 149: MIB Review Submitter names: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: November 13, 2005 Reference: Document: RFC3576MIBs Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
Here are my comments:
draft-ietf-radext-dynauth-client-mib-02.txt 1. It would help to expand RADIUS in the Abstract and to add an appropriate Informative Reference 2. The first paragraph in Section 3 includes a repeated sentence 3. As 2619bis and 2621bis will be supersets and will obsolete 2619 and 2621, I do not believe that there is any need for the older documents to be referenced. 4. No need to list in the Security Consideration section the MIB objects that are considered as non-vulnerable. These are by default all objects, but the ones listed as potentially vulnerable. draft-ietf-radext-dynauth-server-mib-02.txt 1. It would help to expand RADIUS in the Abstract and to add an appropriate Informative Reference 2. As 2618bis and 2620bis will be supersets and will obsolete 2618 and 2620, I do not believe that there is any need for the older documents to be mentioned in section 3 and referenced. 3. No need to list in the Security Consideration section the MIB objects that are considered as non-vulnerable. These are by default all objects, but the ones listed as potentially vulnerable. The documents are in god shape. In my opinion, they may be forwarded to the IESG for consideration as Informational, with a note including the known editorial problems. Proposed Resolution: Discuss
Issue 150: IANA Considerations Submitter names: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: December 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01140.html Document: DIGEST-06 Comment type: Editorial Priority: S Section: Various Rationale/Explanation of issue:
I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Summary: This document is ready for publication - however, I did notice
that in many sections text like:
[IANA: use 102 if possible] for Digest-Response.
I am sure IANA will raise this issue, but it would be best if this was
covered in the IANA Considerations section.[Bernard Aboba] Agreed. Attribute 102 has already been allocated to EAP-Key-Name.
See: http://www.iana.org/assignments/radius-types
Proposed Resolution: Discuss
Issue 151: Review Submitter names: Kurt Zeilenga Submitter email address: kurt@openldap.org Date first submitted: December 14, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01150.html Document: DIGEST-06 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
Overall, I believe the document with some changes is generally suitable for publication on the Standards Track. I believe some changes are necessary to clarify handling of digest-uri and fixing the first example in section 7. In this example, the "Proxy Server" modifies the URI. This would cause a different and incorrect A2 to be produced by the RADIUS server, and hence cause the authentication to fail. I suspect a typo in the example. I do note that RFC 2617 does allow proxies to provide a different URI than the HTTP client's request URI, but the assumption here is that its modifying the HTTP request URI and not the value of the digest-uri parameter. Aside from fixing the example, I suggest the document be more clear as to which Digest values, including but not limited to digest-uri, can be modified by the proxy and which must be preserved as presented by the client/server. Aside from this, I found a number of editorial and other relatively minor issues, such as inconsistent use of the term "protection space", which should be address prior to the document's progression. Attached are my raw review notes.
There is no digest-uri discussion. RFC 2617 allows proxies to modify the digest-uri. Is the RADIUS client allowed to modify the digest-uri? I would assume not as the digest-uri is used in computing A2. However, in the first example, the RADIUS client changes the URI.
>Abstract > > This document defines an extension to the RADIUS protocol to enable > support of Digest Authentication, for use with HTTP-style protocols > like SIP and HTTP. Acronyms, especially RADIUS and SIP, should be spelled out on first use in the abstract.
>1.1. Terminology
> protection space > The combination of realm and digest URI, the use of which is > authorized by the RADIUS server. This definition seems only consistent with RFC2617 if the digest URI holds a canonical root URL. See Section 1.1 of RFC 2617. > SIP UA > SIP User Agent, an Internet endpoint that uses the Session > Initiation Protocol. > SIP UAS > SIP User Agent Server, a logical entity that generates a > response to a SIP (Session Initiation Protocol) request. Note that while SIP is spelled out in the last use above, this is not the first use in the body. Other acyronyms should also be spelled out on first use in body. >1.3. Overview > Instead of maintaining a local user database, the server could use > RADIUS to access a centralized user database. However, RADIUS > [RFC2865] does not include support for HTTP digest authentication. > The RADIUS client can not use the User-Password attribute, since it > does not receive a password from the HTTP-style client. The CHAP- > Challenge and CHAP-Password attributes are also not suitable since > the CHAP algorithm is not compatible with HTTP digest. Informative reference for CHAP? >1.3.2. Scenario 2, RADIUS server chooses nonces > > While the usage scenario described in Section 1.3.1 minimizes the > load on the RADIUS server, alternatives are required in some > situations. When using AKA [RFC3310] the nonce is partially derived > from a precomputed authentication vector, which is often stored > centrally. > > Figure 3 depicts a scenario in which the RADIUS server chooses > nonces. In this case entities A and B communicate using HTTP or SIP, > while entities B and C communicate using RADIUS." Extraneous " ? >2. Interoperability > > An implementation supporting this extension MUST include a Digest- > Response attribute within an Access-Request packet where Digest > Authentication is desired. An Access-Request MUST NOT contain both a > Digest-Response attribute and another authentication attribute, such > as User-Password, CHAP-Password, or EAP-Message. > > RADIUS clients and servers MUST support both nonce generation modes. > As there is no automatic capability exchange, the operator MUST make > sure that the RADIUS client software uses the correct nonce > generation mode when accessing a specific RADIUS server: The above MUST does not apply to an implementation, but to a user, which seems counter to proper RFC 2119 usage. > o If the RADIUS server generates nonces, its RADIUS clients MUST NOT > try to generate nonces. > o If the RADIUS server does not generate nonces, its RADIUS clients > MUST generate nonces locally. > o If at least one HTTP-style client requires AKA authentication > [RFC3310], the RADIUS server MUST generate nonces and its RADIUS > clients MUST NOT generate nonces locally. > RADIUS implementations MUST offer respective configuration options. > > >3. Detailed Description > >3.1. RADIUS Client Behavior > > The attributes described in this document are sent in cleartext. > Therefore were a RADIUS client to accept secured connections (https > or sips) from HTTP-style clients, this could result in information > intentionally protected by HTTP-style clients being sent in the clear > during the RADIUS exchange. > > On reception of an HTTP-style request message, the RADIUS client > checks whether it is authorized to authenticate the request. Where > an HTTP-style request traverses several proxies and each of the > proxies requests to authenticate the HTTP-style client, the request > at the HTTP-style server may contain multiple credential sets. > > The RADIUS client can use the 'realm' directive in HTTP to determine > which credentials are applicable. Where none of the realms are of > interest, the RADIUS client MUST behave as though no relevant > credentials were sent. In all situations the RADIUS client MUST send > zero or exactly one credential to the RADIUS server. The RADIUS > client MUST choose the credential of the (Proxy-)Authorization header > if the realm directive matches its locally configured realm. > > If such a (Proxy-)Authorization header is present and contains HTTP > digest information, the RADIUS client checks the 'nonce' parameter. > If the RADIUS client generates nonces but did not issue the received > nonce, it responds with a 401 (Unauthorized) or 407 (Proxy > Authentication Required) to the HTTP-style client. In this error > response, the RADIUS client sends a new nonce. > > If the RADIUS client recognizes the nonce or does not generate > nonces, it takes the header directives and puts them into a RADIUS > Access-Request packet. It puts the 'response' directive into a > Digest-Response attribute and the realm / nonce / digest-uri / qop / > algorithm / cnonce / nc / username / opaque directives into the What is '/' above used to signify? In ABNF, / character separates choices. I assume each of these directives are actually required, seems using a comma as a separator would be more appropriate for this prose. Likewise below. > respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / > Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- > Username / Digest-Opaque attributes. The request method is put into > the Digest-Method attribute. The RADIUS client adds a Message- > Authenticator attribute, defined in [RFC3579] and sends the Access- > Request packet to the RADIUS server. > > The RADIUS server processes the packet and responds with an Access- > Accept or an Access-Reject. > > The RADIUS client constructs an Authentication-Info header: > o If the Access-Accept packet contains a Digest-Response-Auth > attribute, the RADIUS client checks the Digest-Qop attribute: > * If the Digest-Qop attribute's value is 'auth' or not specified, > the RADIUS client puts the Digest-Response-Auth attribute's > content into the Authentication-Info header's 'rspauth' > directive of the HTTP-style response. > * If the Digest-Qop attribute's value is 'auth-int', the RADIUS > client ignores the Access-Accept packet and behaves like it had > received an Access-Reject packet (Digest-Response-Auth can't be > correct as the RADIUS server does not know the contents of the > HTTP-style response's body). > o If the Access-Accept packet contains a Digest-HA1 attribute, the > RADIUS client checks the 'qop' and 'algorithm' directives in the > Authorization header of the HTTP-style request it wants to > authorize: > * If the 'qop' directive is missing or its value is 'auth', the > RADIUS client ignores the Digest-HA1 attribute. It does not > include an Authentication-Info header into its HTTP-style > response. > * If the 'qop' directive's value is 'auth-int' and at least one > of the following conditions is true, the RADIUS client > calculates the contents of the HTTP-style response's 'rspauth' > directive: > + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5- > sess'. > + The packets between RADIUS client and RADIUS server are > protected with IPsec (see Section 9). > It creates the HTTP-style response message and calculates the > hash of this message's body. It uses the result and the > Digest-URI attribute's value of the corresponding Access- > Request packet to perform the H(A2) calculation. It takes the > Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop > values of the corresponding Access-Request and the Digest-HA1 > attribute's value to finish the computation of the 'rspauth' > value. > o If the Access-Accept packet contains neither a Digest-Response- > Auth nor a Digest-HA1 attribute, the RADIUS client will not create > an Authentication-Info header for its HTTP-style response. > > The RADIUS server MAY have added a Digest-Nextnonce attribute into an > Access-Accept packet. If the RADIUS client discovers this, it puts > the contents of this attribute into a 'nextnonce' directive. Now it > can send an HTTP-style response. The use of MAY here seems odd. The actual OPTIONAL behavior of the RADIUS server is discussed elsewhere. This could more simply be worded: When the RADIUS server provides a Digest-Nextnonce attribute in the Access-Accept packet, the RADIUS client puts the contexts of this attributes into a 'nextnonce' directive. Now it can send an HTTP-style response. >4.2. Digest-Realm attribute > > Description > This attribute describes a protection space of the RADIUS > server. See [RFC2617] 1.2 for details. It MUST only be used > in Access-Request and Access-Challenge packets. Per the definion in section 1, The combination of realm and digest URI, the use of which is authorized by the RADIUS server. But this says this attribute, just a Realm, describes a protection space. >4.7. Digest-URI attribute > > Description > This attribute is used to transport the contents of the digest- > uri directive or the URI of the HTTP-style request. It MUST > only be used in Access-Request packets. > Type > [IANA: use 108 if possible] for Digest-URI > Length > >=3 > Text > If the HTTP-style request has an Authorization header, the > RADIUS client puts the value of the "uri" directive in the > (known as "digest-uri-value" in section 3.2.2 of [RFC2617]) > without quotes into this attribute. This text implies the client is to remove any quote characters appearing in the URI. Suggest: s/without quotes/without quoting/ >4.9. Digest-Algorithm attribute > > Type s/Type/Description/ >4.20. SIP-AOR > > Type s/Type/Description/ >7. Example s/Example/Examples/ > This is an example sniffed from the traffic between a softphone (A), > a Proxy Server (B) and example.com RADIUS server (C). The > communication between the Proxy Server and a SIP PSTN gateway is > omitted for brevity. The SIP messages are not shown completely. > > > A->B > > INVITE sip:97226491335@example.com SIP/2.0 > From: <sip:12345678@example.com> > To: <sip:97226491335@example.com> > > > B->A > > SIP/2.0 100 Trying > > > B->A > > SIP/2.0 407 Proxy Authentication Required > Proxy-Authenticate: Digest realm="example.com" > ,nonce="3bada1a0", algorithm="md5" > Content-Length: 0 > > > A->B > > ACK sip:97226491335@example.com SIP/2.0 > > > A->B > > INVITE sip:97226491335@example.com SIP/2.0 > Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" > ,opaque="",realm="example.com" > ,response="f3ce87e6984557cd0fecc26f3c5e97a4" > ,uri="sip:97226491335@10.0.69.38",username="12345678" > From: <sip:12345678@example.com> > To: <sip:97226491335@example.com> > > > B->C > > Code = 1 (Access-Request) > Attributes: > NAS-IP-Address = a 0 45 26 (10.0.69.38) > NAS-Port-Type = 5 (Virtual) > User-Name = "12345678" > Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" > Digest-Realm = "example.com" > Digest-Nonce = "3bada1a0" > Digest-Method = "INVITE" > Digest-URI = "sip:97226491335@example.com" Why is the value of Digest-URI not the same URI provided by A?
Proposed Resolution: Discuss
Issue 152: Review Submitter names: Alexey Melnikov Submitter email address: alekey.melnikov@isode.com Date first submitted: December 12, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01103.html Document: DIGEST-06 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
I think for the most part the document is ready, but I would recommend at least one more revision to address some issues outlined below. General comments on the document: 1). sections 3.1 and 3.2 are too complex to follow, because they allow for so many different modes of operations: nonce generated on the RADIUS client or the RADIUS server, hash is calculated on the RADIUS client or the RADIUS server, etc. I understand why the document is trying to be so flexible, but the text suffers as the result. I would suggest to separately talk about scenarios described in sections 1.3.1 and 1.3.2.
[Wolfgang]
This would introduce some redundancy. A developer implementing the draft for both modes would have to join those sections anyway. [Alexey] See also my comment about examples for both scenarios.
2). everywhere in section 4: all references to "without quotes" has to be replaced with "unquoted" or similar. "Without quotes" can be interpreted as just blindly removing the surrounding quote characters, however many attribute values are allowed to contain quoted (escaped) "\" and <">, so just removing the quotes will not produce proper result.
[Wolfgang]
Blindly removing the surrounding quotes is exactly what was meant. quoted-string is used to allow characters that would break the HTTP syntax. This is not relevant for RADIUS, as we have TLV. (Un-)Escaping the actual value would not save very much space (I'd guess that escapes are rare) but complicate the implementation. [Alexey] I think you are missing the point. Unescaping is not an optional HTTP feature. An HTTP Digest username can contain "\" or <"> characters. They must be escaped as per HTTP quoted string syntax. For example if you have a username 'domain\user' it will be represented in HTTP Digest as "domain\\user". If a naive implementation just strips the quotes it will end up with 2 slashes and not 1, which will lead to digest verification failure. This comment applies to at least to username, realm, nonce and cnonce. 3). It would be nice to see examples of both scenario 1 and 2 in the document. I think it will clean up a lot of confusion.
[Wolfgang]
What's wrong with message flow given in 1.3.1 figure 2? [Alexey] The message flow is fine, but there are so many optional RADIUS options that a regular reader will be easily lost. An additional example can also help verify that your description is actually correct. I had to reread section 3.1 multiple times to understand how it relates to the two scenarios. Specific comments on the document (please let me know if I got anything wrong): >3.1. RADIUS Client Behavior > > The attributes described in this document are sent in cleartext. > Therefore were a RADIUS client to accept secured connections (https > or sips) from HTTP-style clients, this could result in information > intentionally protected by HTTP-style clients being sent in the clear > during the RADIUS exchange. This paragraph is an important security consideration, so I think it should be moved to section 9 (Security Considerations section), otherwise it is too easy to overlook. [...] > If the RADIUS client recognizes the nonce or does not generate > nonces, Regarding "does not generate nonces" case - does this paragraph talk about scenario 2 step 2, or scenario 2 step 6? I think the latter, but the text is not clear.
[Wolfgang]
The paragraph talks about the handling of an HTTP-style request containing an Authorization header. Scenario 2 Step 2 follows an HTTP-style request without an Authorization header. Is this really that unclear? [Alexey] IMHO, if somebody is reading the document for the first time, it might be confusing a bit. One way to address that is to move the discussion of nonce generation (which is later in the same section) to the front of the section.
> it takes the header directives and puts them into a RADIUS > Access-Request packet. It puts the 'response' directive into a > Digest-Response attribute and the realm / nonce / digest-uri / qop / > algorithm / cnonce / nc / username / opaque directives into the > respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / > Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- > Username / Digest-Opaque attributes. The request method is put into > the Digest-Method attribute. The RADIUS client adds a Message- > Authenticator attribute, defined in [RFC3579] and sends the Access- > Request packet to the RADIUS server. [...] > If the RADIUS client did receive an HTTP-style request without a > (Proxy-)Authorization header matching its locally configured realm > value, it obtains a new nonce and sends an error response (401 or > 407) containing a (Proxy-)Authenticate header. > > If the RADIUS client receives an Access-Reject from the RADIUS > server, it sends an error response to the HTTP-style request it has > received. If the RADIUS client does not receive a response, it > retransmits or fails over to another RADIUS server as described in > [RFC2865]. > > The RADIUS client has three ways to obtain nonces: it generates them > locally, it has received one in a Digest-Nextnonce attribute of a > previously received Access-Accept packet, or it asks the RADIUS > server for one. To do the latter, it sends an Access-Request > containing a Digest-Method and a Digest-URI attribute but without a > Digest-Nonce attribute. It adds a Message-Authenticator (see > [RFC3579]) attribute to the Access-Request packet. The RADIUS server > chooses a nonce and responds with an Access-Challenge containing a > Digest-Nonce attribute. I suggest to move the second quoted above paragraph before the first, so that the two paragraphs talking about nonces are sequential. > The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- > Realm, Digest-Domain and Digest-Opaque attributes in the Access- > Challenge carrying the nonce. If these attributes are present, the > client MUST use them. The Digest-Realm attribute is required as per section 3.2. The use of "can" is confusing in this case, as all other attributes are optional. >3.2. RADIUS Server Behavior [...] > A RADIUS server MUST check if the RADIUS client is authorized to > serve users of the realm mentioned in the Digest-Realm attribute. If > the RADIUS client is not authorized, the RADIUS server MUST send an > Access-Reject. The RADIUS server SHOULD log the event so as to > notify the operator, and MAY take additional action such as sending > an Access-Reject in response to all future requests from this client, > until this behavior is reset by management action. If the server follow the last MAY, this can be used by DOS attacks, so I think this should be pointed out.
[Wolfgang]
In this paragraph or in the Security Considerations section? [Alexey] In this section. > If the RADIUS server does not accept the nonce received in an Access- > Request packet but authentication was successful, Does the server always have to check that the authentication was successful before reporting nonce mismatch? Are there any security implications?
[Wolgang] This is defined in RFC 2617.
[Alexey] OK.
[Wolfgang] If the HTTP-style client receives a 'stale' directive, it does not need to prompt the user for the password again. [Alexey] My question was if nonce verification should be done before or after client response verification. (I don't know the answer.)
> the RADIUS server > MUST send an Access-Challenge packet containing a Digest-Stale > attribute set to 'true' (without quotes). The RADIUS server MUST add > Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, > SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add > Digest-Domain, Digest-Opaque attributes to the Access-Challenge > packet. >4.4. Digest-Response-Auth attribute > > Description > This attribute enables the RADIUS server to prove possession of > the password. If the previously received Digest-Qop attribute > was 'auth-int' (without quotes), the RADIUS server MUST send a > Digest-HA1 attribute instead of a Digest-Response-Auth > attribute. This MUST is confusing, as other sections say that both Digest-Response-Auth and Digest-HA1 are optional.
[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if Digest-Qop was
auth-int.
[Alexey]
The following text from section 3.1 suggests that Digest-HA1 is truly
optional:
o If the Access-Accept packet contains neither a Digest-Response-
Auth nor a Digest-HA1 attribute, the RADIUS client will not create
an Authentication-Info header for its HTTP-style response.
> The Digest-Response-Auth attribute MUST only be
> used in Access-Accept packets. The RADIUS client puts the
> attribute value without quotes into the rspauth directive of
> the Authentication-Info header.
>4.8. Digest-Qop attribute
>
> Description
> This attribute holds the Quality of Protection parameter that
> influences the HTTP Digest calculation. This attribute MUST
> only be used in Access-Request and Access-Challenge packets. A
> RADIUS client SHOULD insert one of the Digest-Qop attributes it
> has received in a previous Access-Challenge packet.
I was under impression that the HTTP[-like] client is the one choosing
Qop from the list of Qops specified by the RADIUS server.[Wolfgang] I don't understand the problem. [Alexey] The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet." implies that the RADIUS client (== HTTP server) is the one picking the Qop. I think the last sentence can say:"A RADIUS client sends the Qop value received from the HTTP client in the Digest-Qop attribute."
[Wolfgang] This is one possibility. I've chosen a different one:
"If the RADIUS server supports more than one "quality of protection"
value, it puts each qop-value into a separate Digest-Qop attribute."
Do
you object to splitting up the qop directive into various
TLVs?
[Alexey]
I think this will break existing HTTP Digest and/or
DIGEST-MD5 (which is
backward compatible with HTTP Digest)
implementations.
The problem is that the behavior you propose was never
explicitly allowed or disallowed in the HTTP Digest document.
>4.13. Digest-Username attribute
>
>
Description
> This
attribute holds the user name used in the HTTP
digest
>
calculation. The RADIUS server MUST use this attribute
only
> for the purposes of
calculating the digest. In order
to
> determine the
appropriate user credentials, the RADIUS
server
> MUST use the
User-Name (1) attribute, and MUST NOT use
the
> Digest-Username
attribute. This attribute MUST only be used
in
> Access-Request
packets.
I am still not convinced that the Digest-Username is ever
different from
the User-Name attribute. I would like to see an example when
they would
be different.
[Wolfgang]
What if your current policy was to assign HTTP user names containing '@' signs? A RADIUS infrastructure would interpret those User-Names as NAIs which may lead to undesired effects. [Alexey] I think giving this example in the document would explain why they may be different.
You also need to add some text explaining how User-Name can be derived from the Digest-Username. >4.17. Digest-Domain attribute > > Description > When a RADIUS client has asked for a nonce, the RADIUS server > MAY send one or more Digest-Domain attributes in its Access- > Challenge packet. The RADIUS client puts them into the quoted, > space-separated list of URIs of the 'domain' directive of a > WWW-Authenticate header. The URIs in the list define the > protection space (see [RFC2617], section 3.2.1). RADIUS > servers MAY send one or more attributes of this type in Access- > Challenge packets. The last sentence is just repeating the first sentence in the same paragraph. > This attribute MUST only be used in Access- > Challenge packets. >9. Security Considerations [...] > 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 specification. I couldn't see this required attribute in the examples.
Proposed Resolution: Discuss
Issue 153: Treatment of Null Identity Response Submitter names: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 13, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01104.html Document: FIXES-01 Comment type: 'T'echnical | Priority: S Section: New Rationale/Explanation of issue:RFC 3748 and RFC 2865 appear to disagree on the subject of whether a response to an EAP-Request/Identity can be an EAP-Response/Identity packet with no data. RFC 3748 Section 5.1 says:
So according to RFC 3748, it is possible to have an Identity Response field that is zero bytes in length, if the identity is not known.
However, RFC 2865 Section 5.1 says:
5.1. User-Name
Description
This Attribute indicates the name of the user to be authenticated.
It MUST be sent in Access-Request packets if available.
It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function.
A summary of the User-Name Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
1 for User-Name.
Length
>= 3
String
The String field is one or more octets. The NAS may limit the
maximum length of the User-Name but the ability to handle at least
63 octets is recommended.
The format of the username MAY be one of several forms:
text Consisting only of UTF-8 encoded 10646 [7] characters.
network access identifierSince the User-Name must be at least 3 bytes
in length, a zero-length String field is not acceptable. Question: What does a RADIUS client do if it receives an EAP-Identity/Response with no data?
[Jari Arkko]
Interesting question. One possible answer is that the NAS should fail the login attempt. This seems reasonable, because without a NAI it will be hard to route the authentication request anyway. But is there use of EAP where the user identity is not known but some other identity (e.g. calling line identification) is used on the NAS side to decide which customer this is?
[Pasi Eronen]
I don't think there's any contradiction here...
Both specs say that there are valid cases where no user name is
available or known. In EAP, the whole EAP-Response/Identity packet
cannot be omitted, so the client sends one with an empty data
field. In RADIUS, an unavailable/unknown username is indicated by
omitting the User-Name attribute from the Access-Request ("It MUST
be sent in Access-Request packets _if_available_.").
So it seems the issue is only whether NAS implementations have really
remembered to handle this special case correctly. I'd guess there are
probably some implementations that send an empty User-Name attribute
instead (thus violating RFC2865), but this is just a hunch and not
based on actual experiences...[Jari Arkko]
I like what you suggest above. But admittedly the specs could be clearer about this. We also have RFC 3579, which says ... the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute... Which we can perhaps interpret so that if the contents is missing then we omit the attribute. But its not very clear. RFC 3579 also says ... If the NAS initially sends an EAP-Request for an authentication method, and the peer identity cannot be determined from the EAP-Response, then the User-Name attribute SHOULD be determined by another means. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute. which talks about a similar but not exactly the same case. And recommends something different from what you were saying above. Anyway, it seems like we have the options of (a) failing the connection, (b) omitting User-Name, and (c) filling it with Called-Station-Id or some predetermined value. The other issue is what, if anything, we should clarify in the specs about this.
What we are seeing in implementations in the field is a mix of a) and c), with the behavior in case c) ranging all over the map. In particular, some implementations are treating a null EAP-Response/Identity as a privacy NAI (no userid or realm).
Oh boy. Hmm... lets think about this some further. RFC 4282 has another approach to privacy NAI, and one which works better with roaming and other AAA routing arrangements. So I think we should discourage that the use of empty EAP-Response/Identity for privacy purposes. What I think remains is two real cases. The first case is simply failure, and all we are debating is whether the failure occurs in the client who never responds, the NAS who dislikes the response, or in AAA that can't route or authenticate the user. Here my preference would be to fail as late as possible. That is, have clients respond with empty identity, have NASes forward the request to AAA etc. I think it is clear that empty User-Name should not be used, but here we still have the question of whether to omit it altogether or or to use Calling-Station-Id as User-Name. I'd be in favor of the latter, given the RFC 3579 text. The second case is a legitimate attempt to use provide no User-Name, complemented with, e.g., some MAC-address based directory of users. This appears to not work in roaming, which to me says that we should discourage such behaviour. But we can still allow it... the proposed approach would be same as for the above case, i.e., use Calling-Station-Id as the User-Name and let the AAA handle it. Documenting this: this seems mostly a RFC 3579/4005 problem. Unless we are developing a bis for them, we could talk about the issue in the issues & fixes draft. The text should indicate rules for EAP client and NAS behaviour, and explain the implications of particular usage (e.g. limitations in roaming).
RFC 4282 allows use of a userid without a realm ("fred"). It also allows use of a realm without a userid ("@example.com"). Is an NAI without either a userid or realm is allowed as well?
I think not -- here's the ABNF: nai = username nai =/ "@" realm nai =/ username "@" realm which seems to imply that its either username, realm, or both. And neither the "username" or "realm" can be an empty string.
One interpretation is that it represents the anonymous NAI of the local realm, and so is equivalent to "@localrealm". Since RFC 4282 discourages use of pseudonyms such as "anonymous" it is not clear what the preferred representation is for "the anonymous user of the local realm". Under this line of thought, the null userid might not only be legal, it might actually be the *preferred* representation!
Anyway, even if such a NAI would be legal, I think we should discourage itat the client side for obvious roaming problems -- of course the NAS side could
still use that. But if I can read (or write) ABNF, then its not a legal NAI...
I think we should (1) discourage use of empty string in the client for privacy purposes and (2) document the different current usage in the NAS side and recommend X for new implementations. I'm leaning on X being no User-Name but use of CSID instead.
[Bernard Aboba]
Here is where I think we are:1. In RFC 4282 a null NAI is not legal. So no data in the EAP-Response/Identity should not be treated as a request for privacy (e.g. the anonymous user within the local realm). If the desire is to indicate "the anonymous user in the local realm" then the NAI "@localrealm" should be used instead.
2. Since there is no identity in the EAP-Response/Identity field, the RADIUS client should include the Calling-Station-ID (MAC Address) in the User-Name field, as it would for Service Type = Call Check. However, the Service-Type should not actually be set to Call-Check since the call has already been accepted.
[David Nelson]
To clarify, we use the value of Calling-Station-ID in the User-Name attribute, and the Service-Type is Framed (or whatever). Do we additionally include an instance of the Calling-Station-ID in the Access-Request? Is there an explicit signal or hint to the RADIUS Server that the user name is the MAC address, or does it figure that out by inspection (parsing)? Or doesn't it matter?
[Alan DeKok]
Yes. The Calling-Station-Id should still be the value of the calling station id. > Is there an explicit signal or hint to the RADIUS Server that the > user name is the MAC address, or does it figure that out by > inspection (parsing)? Or doesn't it matter? It's up to local policy. So it doesn't matter.
[David Nelson]
Uh, yes, but... If the behavior of the RADIUS server is a matter of local policy, doesn't that raise interoperability issues? Asked another way, is there any actual authentication or authorization decision that a RADIUS server makes based on the content of the User-Name in this specific scenario? As I recall, RADIUS Clients and Servers had to implement specific code paths to deal with the "anonymous" user cases.
[Alan DeKok]
Yes, but I don't think it's related to the NULL identity response
problem. A follow-up question is:
Q1: If a server receives Calling-Station-Id, and sees that the value
of the identity is the same as the Calling-Station-Id, what does it
do?
A1: I don't recall any currently mandated behavior. It's up to local policy.
Q2: How does a server distinguish this situation (which may occur
today) from the proposed mandated behavior for NULL identity
response?
A2: I have no idea. I don't know that it can distinguish them.
If the situations can be distinguished, then we can mandate server
behavior here. If the situations can't be distinguished, then
mandating server behavior will change existing deployments and
practices.[Bernard Aboba] The proposed resolution is to insert Section 2.10 as follows:
"2.10. Unknown Identity [RFC3748] Section 5.1 states: If the Identity is unknown, the Identity Response field should be zero bytes in length. However, [RFC2865] Section 5.1 describes the User-Name attribute as follows: The String field is one or more octets. How should the RADIUS client behave if it receives an EAP- Response/Identity that is zero octets in length?
[RFC2865] Section 5.1 states: This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available. This suggests that the User-Name attribute may be ommitted if it is unavailable. However, [RFC3579] Section 2.1 states: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. This seems to suggest that the User-Name attribute should contain the contents of the Type-Data field of the EAP-Response/Identity, even if it is zero octets in length. Note that [RFC4282] does not permit an NAI of zero octets, so that an EAP-Response/Identity with a Type-Data field of zero octets MUST NOT be construed as a request for privacy (e.g. anonymous NAI). When a NAS receives an EAP-Response/Identity with a Type-Data field that is zero octets in length, it is RECOMMENDED that it either omit a User-Name attribute in the Access-Request or include the Calling- Station-Id in the User-Name attribute, along with a Calling-Station- Id attribute."
Proposed Resolution: Accept
Issue 154: Null Attribute Submitter names: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: December 13, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01121.html Document: CUI Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
For text and string types, RFC 2865 indicates that zero-length binary or text strings MUST NOT be sent in attributes. So it would seem to be a conflict with RFC 2865 to require NULL strings. To follow up on my thoughts, it seems we've already [additionally] violated this RFC 2865 requirement in the CUI document, wherein we suggest a NULL value of CUI as a hint to the RADIUS Server. :-( So I suppose, this is an "issue" to be resolved.
[Barney Wolff]
I believe the CUI was to be a single byte of 0-bits, thus NUL rather than NULL and not a violation. I must say, in passing, that I never understood why zero-length strings were forbidden. Can anyone point to a logical, or historical, reason?
[David Nelson]
I don't believe so. The intent of the "hint" flavor of CUI was not to
change the underlying base type from printable-string to binary-string.
Sending a single byte of value zero would only be permissible for a
binary-string and not a UTF-8 printable-string.
The CUI type is defined as: "The string identifies the CUI of the
end-user and is of type UTF8String." Of course, type UTF8String is not
a recognized data type in RFC 2865. Can anyone point me to a formal
definition of this, within a RADIUS RFC?
This leads me to believe that the CUI attribute value field ought to
have been defined as a text type, rather than a string type. See the
RFC 2865 definitions of the basic types:
text 1-253 octets containing UTF-8 encoded 10646 [7]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
string 1-253 octets containing binary data (values 0 through
255 decimal, inclusive). Strings of length zero (0)
MUST NOT be sent; omit the entire attribute instead.
Having noted that types discrepancy (a bit too late, alas), I don't
think there has ever been a substantive difference between the NULL
string and the NUL string. Both are a string containing a binary-zero
as the first element of the array. NUL is the abbreviation you'll find
in the US-ASCII character set definition for the character with hex
value zero. The three character abbreviations for ASCII characters are
a historical artifact. AFAIK, NULL means the same thing.
RADIUS specifically indicates that strings (text and binary) are not
NULL-terminated strings, but are counted strings. In converting a
C-language NULL (or NUL) string to a RADIUS attribute, it would become a
RADIUS string type of zero length.
See the relevant text from RFC 2865:
Note that none of the types in RADIUS terminate with a NUL (hex
00). In particular, types "text" and "string" in RADIUS do not
terminate with a NUL (hex 00). The Attribute has a length field
and does not use a terminator. Text contains UTF-8 encoded 10646
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
RADIUS implementers using C are cautioned not to use strcpy() when
handling strings.
> I must say, in passing, that I never understood why zero-length strings
> were forbidden. Can anyone point to a logical, or historical, reason?
I believe that the historical reason was that zero-length attributes
contained no data, and were presumed to have no semantics, and for
reasons of bits-on-the-wire efficiency and protocol clarity it was
deemed preferable to omit the attribute rather than send an "empty
container".[Ignacio Goyret]
Long ago, in the previous instance of a RADIUS WG, a similar question was posted and the WG decision was that attributes with empty value fields must not be sent (hence, the 1-253 octets limit for text and string). Back then, some people tried (unsuccessfully) to argue that the presence of a null valued attribute is different from the absence of such attribute. In my mind (and apparently, in a few others as well), an absent attribute should mean "I don't know anything about that attribute" whereas an empty attribute should mean "the attribute is known and its value is empty" but that's not what the RFC says. Appended are some related messages from the old WG mailing list that may help shed some light on this issue. I don't know if the old mailing list is archived somewhere (livingston.com went offline a long time ago) but if there is, google doesn't seem to know about it.
[Jouni Korhonen]
The text in the CUI draft indicates that the NUL CUI includes a single 'NUL' character. "... For the initial authentication, the CUI attribute will include a single NUL character (referred to as a nul CUI). And, during re- authentication, the CUI attribute will include a previously received ..." > The CUI type is defined as: "The string identifies the CUI of the > end-user and is of type UTF8String." Of course, type > UTF8String is not > a recognized data type in RFC 2865. Can anyone point me to a formal > definition of this, within a RADIUS RFC? I recall that representation originates from Diameter specs. As at some early phases of the CUI there was direct linkage to Diameter CC Subscription-Id-data, which is defined as UTF8String. A definition for UTF8String is in RFC3588 (using UTF-8 transformation format as described in RFC2279) -- not in RADIUS RFCs though.
[Jari Arkko]
I would prefer fixing the type to a RADIUS type (string).
[David Nelson]
I agree, although if the type is intended to be a UTF-8 printable string, the correct RADIUS type would be "text", not "string. If there is consensus on that, it could be fixed in AUTH48.
[Avi Lior]
he CUI should be of Type String.
And actually it is and it isn't and we need to fix the text.
Current text:
Type: TBD for Chargeable-User-Identity.
Length: >= 3
String:
The string identifies the CUI of the end-user and is of type
UTF8String.
It says its of type "String" but then it says it is a UTF8String. This
is because in the early days it was probably of type Text and not string
but then we added the opaque handle....
So Proposed text:
Type: TBD for Chargeable-User-Identity.
Length: >= 3
String:
The string identifies the CUI of the end-user.
We should get this in AUTH48. Proposed Resolution: Accept
Issue 155: Errata for RFC 4282 Submitter names: Alfred HÃnes Submitter email address: ah@tr-sys.de Date first submitted: December 18, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01160.html Document: RFC4282 Comment type: Editorial Priority: 3 Section: Various Rationale/Explanation of issue:
I just read the recently published RFC 4282 (revised NAI spec)
authored by you and would like to submit a few comments.
Unfortunately, the text of that RFC does not fully reflect the
established state of the IETF standards, by referring to obsolete
documents (e.g., ex STD 10, RFC 821) and ignoring effective updates,
e.g., STD 3, RFC 1123, and RFC 2821.
In particular, the text of RFC 4282 repeatedly (e.g. in Section
2.6.) emphasizes making a deviation from established standards
for host / domain names.
This is not true!
The pretended deviation in fact reflects the current standards.
The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:
"One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow
either a letter or a digit. Host software MUST support
this more liberal syntax."
and continues saying:
"Host software MUST handle host names of up to 63 characters
and SHOULD handle host names of up to 255 characters."
Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!
Note: IMHO, it is a fundamental design flaw of RADIUS and certain
other protocols using TLVs, AVPs, -- or however similar protocol
objects are named -- to specify that the 'length' information
(being stored in a single octet) is to comprise the cumulative
size of the Type, Length and Value fields, instead of just giving
the size of the Value (payload) field; the latter solution would
always allow to fully exhaust the total range of an 8-bit unsigned
Length and thereby allow payload octet strings of size 0..255 !
Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in
RFC 4282 that is on the IETF Standards Track.
o L2F [RFC2341] has been published for information only
as a Historic RFC 'ab initio'.
o PPTP [RFC2637] has purposely been rejected by the IETF --
because of its well known significant security flaws, among
other issues, and the Informational RFC 2637 has been
published with a very clear IESG Note to this end.
I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet. We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards![Jari Arkko]
Unfortunately, the text of that RFC does not fully reflect the established state of the IETF standards, by referring to obsolete documents (e.g., ex STD 10, RFC 821) and ignoring effective updates, e.g., STD 3, RFC 1123, and RFC 2821.
This is indeed an oversight. Too bad you did not tell us about it a few days earlier... and I'm kind of surprised this does not happen at the RFC editor side automatically. We could make an errate entry for this.
In particular, the text of RFC 4282 repeatedly (e.g. in Section 2.6.) emphasizes making a deviation from established standards for host / domain names. This is not true! The pretended deviation in fact reflects the current standards.
Right. Material for an errata.
The modification to RFC 952, RFC 821, et al. has already been
introduced into the IETF Standards by STD 3, RFC 1123 (Host
Requirements, Part II), published 16 years ago, in October 1989.
Section 2.1 of that RFC, on page 13, says:
"One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow
either a letter or a digit. Host software MUST support
this more liberal syntax."
and continues saying:
"Host software MUST handle host names of up to 63 characters
and SHOULD handle host names of up to 255 characters."
Therefore, it would have been strongly advisable to point out
on page 6 of RFC 4282, in Section 2.2, first bullet, that the
named rules in RFC 2865 **DO NOT CONFORM** with STD 3 !!!
This is true, but IMHO not the task of this RFC to complain. There is ongoing work in the RADEXT WG on documenting issues with the RADIUS protocol, and it might be good to take care of this issue in there.
Note: IMHO, it is a fundamental design flaw of RADIUS and certain other protocols using TLVs, AVPs, -- or however similar protocol objects are named -- to specify that the 'length' information (being stored in a single octet) is to comprise the cumulative size of the Type, Length and Value fields, instead of just giving the size of the Value (payload) field; the latter solution would always allow to fully exhaust the total range of an 8-bit unsigned Length and thereby allow payload octet strings of size 0..255 !
Yeah. But we have to live with it.
Similarly, RFC 4282 ignores the standardization state of the
proprietary historic tunnelling protocols that have served as
'precursors with major deficiencies to learn from' for the
development of L2TP, the only comparable protocol named in
RFC 4282 that is on the IETF Standards Track.
o L2F [RFC2341] has been published for information only
as a Historic RFC 'ab initio'.
o PPTP [RFC2637] has purposely been rejected by the IETF --
because of its well known significant security flaws, among
other issues, and the Informational RFC 2637 has been
published with a very clear IESG Note to this end.
I am surprised that a new Standards Track RFC is getting published
that repeatedly refers to obsolete protocols equally as to official
protocols, in a manner that does not make clear the distinction.
The continued unreflected use of PPTP, in particular, is seen by
major security consultants as 'one of the most widespread trojan
horses' in the current Internet. We should do everything to
communicate and emphasize the 1998/1999 decisions of the IETF and
IESG and the reasons behind it, and push the evolved standards!
This text was inherited from RFC 2486. But again, while I agree with some of the issues in these non-IETF protocols, I'm not sure the NAI RFC is the right place to discuss such issues. I agree that if the text had been written from scratch, it probably would have been better to keep the tunneling protocol text to a minimum. Still, I happen to believe in pointing to usage as opposed to not mentioning this. It would be good to be able to separate standards from non-standards in references, but I'm not sure how to do that easily. Its easy most of the time to separate the normative and informational references, as we do here too, but your issue is with the separation between standards-track and individual submission RFCs. Unfortunately, the current designations in the references section do not make a clear distinction here. For instance, since 2661 is only a Proposed Standard, the reference entry looks the same as 2637, which is an individual submission RFC. Thoughts? Anyway, as a conclusion I'm suggesting we send an errata entry to the RFC Editor that shows the 821 update and 2.6 new situation.
[Bernard Aboba]
This is indeed an oversight. Too bad you did not tell us about it a few days earlier... and I'm kind of surprised this does not happen at the RFC editor side automatically.
Part of the problem is that RFC 1123 does not state that it updates RFC 821, although RFC 2821 does state that it obsoletes 821, 974, 1869 and updates 1123.
Anyway, as a conclusion I'm suggesting we send an errata entry to the RFC Editor that shows the 821 update and 2.6 new situation.
I think we also need to check that the ABNF in RFC 4282 is compatible with RFC 2821 ABNF (Section 4.1.2).
[Pasi]
It's not -- as we found out when discussing what IKEv2 ID payload type should be used for NAIs. But this is not really a problem. It's not necessary that all valid SMTP email addresses are usable as NAIs or vice versa. (Couple of examples: "joe@[1.2.3.4]", "foo"@example.com, "joe", "@example.com", and everything containing UTF-8.)
Proposed Resolution: Accept
Issue 156: Review of Prefix Delegation Draft Submitter names: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: November 13, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01096.html Document: Delegation-01 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:Some comments on draft-salowey-radext-delegated-prefix-01, based my (possibly imperfect) understanding of the scenario. Overall, I think the document is ok, but it may need some tweaking with respect to its description of the functionality of the existing Framed-IPv6-Prefix attribute.
This is different from the usage of Framed-IPv6- Prefix attribute in which the prefix remains in control of the Network Access Server (NAS). The prefix in the Framed-IPv6-Prefix attribute can be assigned to a link to which the NAS is attached, and may subsequently be advertised through Router Advertisement messages [3].At the time RFC 3162 was written, I believe that intent was for the prefix described in Framed-IPv6-Prefix to be advertised by the NAS in Router Advertisement messages. However, I am not clear that this necessarily implies that the prefix is solely for use on the link to which the NAS is attached. For example, if a /48 is assigned, wouldn't it be possible for the NAS to advertise the /48 via Router Advertisement and for the CPE to parcel out /64s to its interfaces? Given that interpretation, I don't think it is necessarily true that "the prefix remains in control of the NAS".
Prefix-LengthThe length of the prefix, in bits. At least 0 and no larger than 128.
This sentence, echoing RFC 3162 may introduce some of the same issues. Is it really the intent to enable prefixes more granular than a /64? What is the implication for prefix delegation if a /128 is assigned?
Proposed Resolution: Discuss
Issue 157: Comments Submitter names: Lou Berger Submitter email address: lberger@movaz.com Date first submitted: November 16, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01069.html Document: DIGEST-05 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue: Bernard, (Wolfgang), Per our discussion in Vancouver, I've re-readdraft-ietf-radext-digest-auth-06.txt from the perspective of SIP authorization and also comparing it to draft-ietf-aaa-diameter-sip-app-10.txt. I think you were correct (and I wasn't) in the observation that the former does the job, but
I still have a small number of comments:1. It seems to me that both the SIP and Diameter drafts don't fully support the requirements laid out in RFC 3702. Also, neither draft references this RFC. I
found this really surprising. What is the relationship of the drafts to theRFC? Is there any intention/desire to have the drafts fully support it? I'm
sure I'm missing something, so what's the "big picture here"?2. Here are some specific mismatches between the draft and RFC3702, please let
me know if I missed something. Support for RFC 3702, section: a) 2.1.5. Updating SIP Server Entries (and missing reference to RFC 3576) b) 2.3.2. Information Transfer [I think this implies passing via & route information on the authorization request as well as handling the response.] c) 2.4.5. Support for Accounting on Different Media3. While not covered in the AAA requirements I think that authorization based on requested media is also needed. I think this is the complement of the (media
related) policy extensions being discussed within the SIPPING WG. Please let me know what you think.
[David Nelson]
Creating RADIUS features that exceed the comparable features in Diameter would be a problem. That's not the intent of RADEXT. Everything in RADEXT WG work items needs to be upwards compatible to a corresponding feature in Diameter, or contain that Diameter compatibility in the RADEXT document. If these are requirements that you see as not being addressed in the Diameter SIP Application, then I don't see how we could (or should) address them in RADIUS (alone).
[Bernard Aboba]
RFC 3072 Section 1.1 talks about the requirements for RADIUS Digest Authentication:
Nevertheless, a few limited RADIUS [5]
extensions may meet some of the requirements in this document (for
instance, some of the authentication requirements). We expect that
while RADIUS with these limited extensions will meet particular
functional requirements, it will not meet other important
requirements. The following are some requirements that are not
expected to be met by RADIUS:
1. Section 2.1.3: RADIUS does not support a discovery feature.
2. Section 2.1.7: RADIUS does not support reliable message
delivery.
The following list contains the requirements that can be met by
RADIUS or RADIUS extensions.
1. Section 2.1.2: Communication between domains does not scale
well in RADIUS. As a result, inter-domain communications are
typically handled using a proxy architecture [6].
2. Section 2.1.5: RADIUS clients would need to support Dynamic
Authorization [7].
3. Section 2.1.9: RADIUS clients would need to rely on a lower-
layer security protocol, such as IPSec, to perform mutual
authentication.
4. Section 2.3.3: RADIUS clients would need to support Dynamic
Authorization [7].
5. Section 2.3.4: RADIUS clients would need to support Dynamic
Authorization [7].Proposed Resolution: Reject
Issue 158: MD5-Sess Submitter names: Henrik Nordstrom Submitter email address: henrik@henriknordstrom.net Date first submitted: December 29, 2005 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00000.html Document: DIGEST-06 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:Has there been any thought of allowing RADIUS to be used for session based MD5-Sess authentication, where processing of further authentication within the same session is carried out by the radius client (i.e. HTTP server/proxy) rather than the RADIUS server?
This is quite interesting in HTTP applications, where quite many requests can be seen within the same session and at a relatively high rate. (i.e. thousands of requests/second, for a active end-user population of a few thousands). Having the bulk of the authentication verifications carried out in the RADIUS client (HTTP server/proxy) can significantly reduce the load on the RADIUS server and greatly improve the request latency (quality) of the service provided.
The principle behind this is that the MD5-sess hash A1 (Digest-HA1, aka 'session key' in RFC2617) attribute is given to the client (HTTP server/proxy) even if qop=auth (or perhaps even missing). This allows the HTTP server/proxy to internally process further requests in the same session (same server side nonce), considerably reducing the load on the RADIUS server.
Today the wordings in draft-ietf-radext-digest-auth06.txt forbids this mode of operation, and one has to loop via qop=auth-int to fool the RADIUS server into a mode allowing for this, even if . The following quite modest changes is needed to allow for RADIUS to be used in such conditions:
1.3. Overview 3.1. RADIUS Client Behaviorhere one may want to add a section describing this optional behavior of the client.
3.2. RADIUS Server Behavior
Add the following condition
o If the Digest-Qop attribute's value is 'auth' and the
Digest-Algorithm attribute's value is 'MD5-sess' the RADIUS
server MAY add a Digest-HA1 attribute into the Access-Accept
packet to allow the client to process further authentication
requests within the same session.
4.19. Digest-HA1 attribute
Here the qop related restriction on when this attribute may be sent
needs to be dropped. Having restrictions here is also in large redundant with
section 3.2 I think. For security reasons I would also add a recommendation to restrict the MD5-sess case (including qop=auth-int) to when the RADIUS server has generated the Digest-Nonce. Sending MD5-sess Digest-HA1 in the mode where the RADIUS client has generated the nonce allows for session theft if the attacker can listen to the external traffic and also query the RADIUS server, even if he can not see the traffic between the actual RADIUS client used and the RADIUS server.
[Alan DeKok]
> Has there been any thought of allowing RADIUS to be used for session based > MD5-Sess authentication, where processing of further authentication within > the same session is carried out by the radius client (i.e. HTTP > server/proxy) rather than the RADIUS server? Not really. The discussion surrounding the Digest-HA1 attribute was about solving a different problem. http://www.drizzle.com/~aboba/RADEXT/. See the discussion in "Issue 8: Rspauth generation...". > This is quite interesting in HTTP applications, where quite many requests > can be seen within the same session and at a relatively high rate. (i.e. > thousands of requests/second, for a active end-user population of a few > thousands). Having the bulk of the authentication verifications carried > out in the RADIUS client (HTTP server/proxy) can significantly reduce the > load on the RADIUS server and greatly improve the request latency > (quality) of the service provided. I don't think there's any objection to that point. The objection is elsewhere, to the change in the security model of RADIUS. RADIUS is intended to have the RADIUS server perform authentication. If the RADIUS client caches information and "short-circuits" subsequent authentication requests from the user, then I would say that such behavior is outside of the scope of the RADIUS standards. Implementations may choose to do what they want, but the standards should follow design goals and best practices.
Proposed Resolution: Reject
Issue 159: Negotiation Submitter names: Wolfgang Beck Submitter email address: beckw@t-systems.com Date first submitted: January 9, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00018.html Document: DIGEST-06 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
Following the contributions of Alexey Melnikov and Hendrik Nordstrom, I think we have also a negotiation problem. In scenario 1 -- RADIUS client chooses nonces -- the RADIUS client has to know what RfC2617 features the responsible RADIUS server supports. The trouble is, that an HTTP Digest server not only sends the nonce but also the supported protocol features in its initial response. The RADIUS client can invent a nonce but does not necessarily know the features of the RADIUS servers. The draft mentions only the AKA case and requests manual configuration. MD5, MD5-sess, auth, auth-int are not covered. Proposal 1: clarify by adding a new section: RADIUS client configuration A RADIUS client choosing nonces has to maintain some configuration data for each RADIUS server it may send requests to: - the algorithms (MD5, MD5-sess, etc) supported by the RADIUS server - the quality of protection (qop) levels supported by the RADIUS server This configuration may be done manually or by protocols not covered in this document. can we add this without starting a new round of Last Calls? Proposal 2: remove scenario 1 from the draft, go back to WGLC
[Henrik Nordstrom]
RADIUS client configurationA RADIUS client choosing nonces has to maintain some configuration data for each RADIUS server it may send requests to: - the algorithms (MD5, MD5-sess, etc) supported by the RADIUS server
Indeed. It isn't too unlikely there will be radius servers only supporting MD5-sess, and additionally only in scenario 2 mode of operations. This would be due to second level user directory integration requirements where the radius server itself can not get raw access to the MD5 H(A1) as it is rather security sensitive piece of information, only session hashes coupled with a unique sesson nonce generated by the user directory service.
- the quality of protection (qop) levels supported by the RADIUS server This configuration may be done manually or by protocols not covered in this document.
auth vs auth-int is mainly a property of the RADIUS client, not the RADIUS server. Having this decided by the RADIUS server in either mode would be a bit odd. But indeed possible in scenario 2 mode operations.
What is missing here is to clarify that in both cases the client should include a Digest-Qop attribute in the first message (or to be precise all messages) indicating which of auth or auth-int is desired. If not specified auth is assumed. The radius server MAY override the client wishes, but it can not be expected that all clients supports auth-int.
can we add this without starting a new round of Last Calls?
Hope so.
Proposal 2: remove scenario 1 from the draft, go back to WGLC
Hmm.. can't really make up my mind on this one. It is a quite useful optimization of the protocol, in lack of useable MD5-sess session support..
But at the same time it's a quite dangerous mode of operation if adding MD5-sess session support as it could allow theft of the session hash via another authorized RADIUS client.
Additionally scenario 1 mode of operations have a minor security issue in that it allows for probing to verify if the password is still the same by simply replaying the exact same digest message, provided one has gained authorization to talk to the RADIUS server directly.
Additionally the strength of the Digest hashing as such is also partly a property of the how well the RADIUS client chooses it's nonces in this mode of operation.. If the client is really poorly implemented and only selects between a small set of nonces it could make Digest open to replay attacks, no matter how good the RADIUS server implementation is. But the opposite is also true in that in scenario 2 the client can not choose stronger nonces if it is found the RADIUS server is poorly implemented...
[Alan DeKok]
> Additionally the strength of the Digest hashing as such is also partly a > property of the how well the RADIUS client chooses it's nonces in this > mode of operation.. If the client is really poorly implemented and only > selects between a small set of nonces it could make Digest open to replay > attacks, no matter how good the RADIUS server implementation is. But the > opposite is also true in that in scenario 2 the client can not choose > stronger nonces if it is found the RADIUS server is poorly implemented... There are an order of magnitude or two fewer RADIUS server implementations than clients. For that alone, I would worry more about poor client implementations than server implementations.
Proposed Resolution: Discuss
Issue 160: Multiple NAS address options Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: 1/9/06 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00019.html Document: draft-aboba-radext-fixes-01.txt Comment type: T/E Priority: 1 Section: 2.7.2 Rationale/Explanation of issue: Regarding this text: There are situations in which a RADIUS client or server may have multiple addresses. For example, a dual stack host can have both IPv4 and IPv6 addresses; a host that is a member of multiple VLANs could have IPv4 and/or IPv6 addresses on each VLAN; a host can have multiple IPv4 or IPv6 addresses on a single interface. However, [RFC2865] Section 5.44 only permits zero or one NAS-IPv4-Address attributes within an Access-Request and [RFC3162] Section 3 only permits zero or one NAS-IPv6-Address attributes within an Access- Request. Where a NAS has more than one global address, it is RECOMMENDED that the NAS include the NAS-Identifier attribute in an Access-Request in order to identify itself to the RADIUS server. More typically, this situation has been addressed by allowing the NAS RADIUS client implementation to specify which address should be used (either globally or perhaps based on additional information about the type of request). Requested change: Can we change the condition on the RECOMMENDATION to something like 'When a NAS has more than one global address and no ability to determine which is used for identification in a particular request, ...'. Also, can you change: "NAS-IPv4-Address" -> "NAS-IP-Address" and "Account-Session-ID" -> "Acct-Session-Id" in the doc.
Proposed Resolution: Accept
Issue 161: Authorize-Only Service-Type Submitter name: Joe Urbasik Submitter email address: joe.urbasik@siemens.com Date first submitted: January 12, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00030.html Document: FIXES-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue:
I am looking at implementing a server for the protocol in RFC 3576, and I have a few questions regarding the "Authorize-only" Service-type. I have looked through the archives for this list, and have also browsed RFC 2865 and 4005, in trying to find answers. RFC 3576 requires a conforming implementation to respond to a DM or CoA request with Service-type Authoize-only with a NAK to the Initial Request, followed by a RADIUS Access-request. I understand from the description in RFC 3576 that this Access-request is meant to trigger a "reauthorization". I am trying to understand this part of the protocol, in the case where the Initial request is generated from a Radius server, as opposed to a Radius/Diameter gateway. I have these two general questions: 1a. What is the usage scenario for this feature, from a network management perspective ? I know the RFC says that "This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols". but I am not so familiar with Diameter, and I do not understand what the need is for this feature - is this strictly for forward compatibility with Diameter ? 1b. What is the usage scenario, with radius servers ? (This may be the same question from another perspective, but in case it isn't) : From the point of view of someone wanting to enhance a radius server, what is the need or attraction for implementing/issuing the "Authorize-only" requests within this protocol ? 2. The RFC states that the Radius Access-request is to be sent by the RFC3576 Server. Implicit in this is that the RFC3576 server will get a response - is it expected to act on that response message ? Can the sending of the Access Request be performed by a different server process, or must the Request come from the same process (or port) that received the initial Authorize-only request, and that issued the NAK ? In other words, is the Radius Server maintaining some sort of state between the two messages ? I also have 2 specific technical questions 1. I have assumed that the values for the Attributes are to be taken from RFC 2865, yet in that RFC, "Service-type" has defined the value "Authenticate-only", not "Authorize-only" 2. Regarding permitted attributes, the paragraph at the top of page 13 says: Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA- Request, implementations MUST send a CoA-NAK; My interpretation of this statement is that only the (3) "NAS identification attributes" and (12) "Session identification attributes", as listed at the start of section 3, MAY be in the message. However that interpretation excludes Service-type (trivial) and State (less trivial - see [Note 7] ). Have I misinterpreted the paragraph, or are those actually the exceptions ?
[Bernard Aboba]
RFC 3576 Section 4 allocates the "Authorize-Only" Service-Type value.My take is that a State attribute is permited in a CoA/Disconnect-Request with Service-Type=Authorize-Only", and in fact RFC 2865 Section 4.1 suggests that it is required:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or a State.
The RFC 3576 "Authorize-Only" Service-Type was originally created for
the purpose of Diameter compatibility. However, Diameter compatibility issues
only arise with the CoA-Request, and never with the Disconnect-Request. This is
because a Disconnect-Request can always be handled as a single request/response
sequence either in Diameter or RADIUS so it should never be necessary to include
a Service-Type="Authorize-Only" within a Disconnect-Request. Since a Diameter disconnect request will always generate an immediate response, and never another access request, including Service-Type="Authorize-Only" in a RADIUS Disconnect-Request can cause problems with Diameter compatibility, rather than enhancing it.
There are situations in which include a Service-Type="Authorize-Only" attribute in a RADIUS CoA-Request makes sense. This can happen in situations where it is necessary to change an attribute which could potentially be interpretted as a session identification attribute. This is the "semantic ambiguity" problem described in RFC 3576. There are also situations in which this is needed for Diameter compatibility. For example, if there is a RADIUS client/NAS interacting with a Diameter Server, then it is possible that a Diameter change-of-authorization request will not be easily translatable to a standard RADIUS CoA-Request without use of Service-Type="Authorize-Only".
A number of issues can arise with respect to processing of an "Authorize-Only" Disconnect or CoA-Request:
a. Which RADIUS server to respond to. While the CoA-NAK needs to be sent to the entity that sent the CoA-Request, it is not entirely clear who the Access-Request is to be sent to. A RADIUS client is typically configured with one or more RADIUS servers, but the CoA-Request might have been sent by a different entity. As a result, it is possible that the Access-Request will go to a different server than the one that sent the CoA-Request.
b. Security problems. The RFC 2865 Section 4.1 text suggests that RADIUS requires Access-Request messages to contain either an authentication attribute or a state attribute. Since "Authorize-Only" messages do not contain an authentication attribute, the only alternative is to include a State attribute, which presumably needs to be obtained from the CoA or Disconnect-Request. This is why I believe that the State attribute needs to be allowed; there may even by RADIUS servers that will reject the Access-Request unless it is included.
However, since the State attribute typically can only be interpretted locally, it may not be interprettable by a server other than the one that originated the CoA or Disconnect-Request, so if the Access-Request goes to a different server interoperability problems can result.
Therefore while there is no RFC 3576 requirement that the same process generating the Disconnect or CoA-NAK also generate the Access-Request, this might in fact be a good idea, since it could help guarantee that the Access-Request goes back to the same entity that sent the CoA/Disconnect-Request.
[Bernard Aboba] The proposed resolution is as follows:
Add Section 3.1:
"3.1. State
[RFC2865] Section 5.44 states:
An Access-Request MUST contain either a
User-Password or a CHAP-
Password or State. An Access-Request MUST
NOT contain both a
User-Password and a CHAP-Password. If
future extensions allow
other kinds of authentication information to be
conveyed, the
attribute for that can be used in an
Access-Request instead of
User-Password or CHAP-Password.
In order to satisfy the requirements of [RFC2865] Section 5.44, an
Access-Request with Service-Type="Authorize-Only" MUST contain a
State attribute.
In order to provide a State attribute to the NAS, a server sending
a
CoA-Request or Disconnect-Request with a Service-Type value of
"Authorize-Only" MUST include a State Attribute, and the NAS MUST
include the State Attribute unchanged in the Access-Request.
A NAS
receiving a Disconnect or CoA-Request containing a Service-Type
value
of "Authorize-Only" but lacking a State attribute MUST send a
Disconnect or CoA-NAK and SHOULD include an Error-Cause attribute
with value 402 (Missing Attribute)."
In Section 3.5, change Note 6 to the following:
" [Note 6] When included within a Disconnect-Request or CoA-Request,
a
Service-Type Attribute with value "Authorize Only" indicates that
the
Request only contains NAS and session identification attributes,
and
that the NAS should attempt reauthorization by sending an Access-
Request with a Service-Type Attribute with value "Authorize Only".
This enables a usage model akin to that supported in Diameter, thus
easing translation between the two protocols. Support for the
Service-Type Attribute is optional within CoA-Request and
Disconnect-
Request messages; where it is not included, the Request message may
contain both identification and authorization attributes. A
NAS that
does not support the Service-Type Attribute with the value
"Authorize
Only" within a Disconnect-Request MUST respond with a Disconnect-NAK
including no Service-Type Attribute; an Error-Cause Attribute with
value "Unsupported Service" MAY be included. A NAS that does
not
support the Service-Type Attribute with the value "Authorize Only"
within a CoA-Request MUST respond with a CoA-NAK including no
Service-Type Attribute; an Error-Cause Attribute with value
"Unsupported Service" MAY be included.
A NAS supporting the "Authorize Only" Service-Type value within
Disconnect-Request or CoA-Request messages MUST respond with a
Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
Attribute with value "Authorize Only", and an Error-Cause Attribute
with value "Request Initiated". The NAS then sends an
Access-Request
to the RADIUS server with a Service-Type Attribute with value
"Authorize Only". This Access-Request SHOULD contain the NAS
attributes from the Disconnect or CoA-Request, as well as the
session
attributes from the Request legal for inclusion in an
Access-Request
as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].
As
noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
SHOULD be included in an Access-Request that does not contain a
User-
Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.
The
RADIUS server should send back an Access-Accept to (re-)authorize
the
session or an Access-Reject to refuse to (re-)authorize it."
Proposed Resolution: Accept
Issue 162: Nonce Replay Issue Submitter names: Wolfgang Beck Submitter email address: beckw@t-systems.com Date first submitted: January 20, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00036.html Document: DIGEST-06 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
During the IESG review Glen Zorn pointed out, that the draft allows a nonce replay attack as the RADIUS server can't tell how old a nonce is. So I've added some sentence like 'the nonce MUST contain some kind of timestamp'. Just before submitting -07, it dawned to me that this is not sufficient. In scenario 1, the RADIUS client communicates the nonce to the RADIUS server. As generator and consumer of the nonce are not the same system, we need to define a nonce format. RfC 2617 proposes time-stamp H(time-stamp ":" ETag ":" private-key) This is fine, but many HTTP-style messages don't have an ETag header. Even if there is one, the RADIUS server can't check it as there is no RADIUS attribute for ETag. We might structure the nonce mentally in two parts: nonce = concat(time-stamp, H(time-stamp ":" private-key), second-part) time-stamp = minutes since Epoch in hexadecimal, padded to 8 digits second-part = arbitrary data that might be interpreted by the nonce generator to check the authencity of the nonce. One could argue that private-key is useless as Glen's attack requires that the attacker has full access to the RADIUS client. Is the granularity of minutes sufficient?
Proposed Resolution: Discuss
Issue 163: Vendor-Specific Attribute with "Authorize-Only" Service-Type Submitter names: Steven Xu Submitter email address: steven.xu@motorola.com Date first submitted: January 20, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00034.html Document: FIXES-01 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
[Bernard Aboba]
The permitted attributes in a Disconnect-Request parallels the attributes
permitted in a RADIUS Access-Reject to some extent. The Disconnect-Request
only includes session identification attributes since the goal is not to change
the authorizations, but to terminate the user. Therefore the only
attributes needed are those that are used for user-identification.
RFC
2865 only enables Reply-Message and Proxy-State attributes in an
Access-Reject; Vendor-Specific attributes are prohibited. RFC 2869
enables inclusion of Password-Retry, EAP-Message and Message-Authenticator
attributes. RFC 3579 enables inclusion of an Error-Cause attribute within
an Access-Reject. RFC 2868 and 3162 do not enable use of the attributes
defined there within an Access-Reject.
So my take is that the omission
of vendor-specific attributes from a RFC 3576 Disconnect-Request is
intentional.
Of course, this begs the question of why a Service-Type
value of "Authorize Only" is being used with a Disconnect-Request in the first
place. RFC 3576 is in error in stating that this is useful for Diameter
interoperability; in fact, Diameter disconnect requests are handled via
request/response, not via generation of another Access-Request.
[Bernard Aboba] The proposed resolution is to change the last two paragraphs of Section 3 to the following:
" Where a Service-Type Attribute with value "Authorize Only"
is
included within a CoA-Request, attributes representing an
authorization change MUST NOT be included; only NAS or session
identification attributes are permitted, as well as Service-Type,
Nonce and State attributes. If other attributes are included
in such
a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included.
A Disconnect-Request MUST contain only NAS and session
identification
attributes (see Section 3), as well as Service-Type, Nonce and
State
attributes. If other attributes are included in a
Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included."
Proposed Resolution: Accept
Issue 164: Review Submitter names: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: January 29, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00056.html Document: IEEE802-01 Comment type: 'T'echnical | Priority: S Section: Various Rationale/Explanation of issue:
Overall, this draft is in good shape, but some minor mistakes and question marks are noted below. In addition, the document is silent on the use of these attributes in Diameter, which needs further work. The title should probably mention redirection, too. Is this for informational or standards track? In some sense the latter would make more sense, as this is an important functionality that many people will need. Technical:
org-url = http_URL ;Note: Syntax for http_URL defined in ;[RFC2616], section 3.2.2 redir-url = http_URL
s/_/-/g And please run ABNF checker from tools.ietf.org: l2-filter-body = ( l2-proto " from " l2-address " to " l2-address ) / l2-rmon-str *; HEXDIG UNDEFINED* l2-proto = "l2:ether2" [ ":0x" 1*4HEXDIG ] *; DIGIT UNDEFINED* l2-rmon-str = "l2:" 1*DIGIT *( "." 1*DIGIT ) *; DQUOTE UNDEFINED* tunnel-id = DQUOTE *( TEXTDATA / ( "%" 2HEXDIG ) / ( "\" 1*( "\" ) *1*"\"* ) / ( "\" DQUOTE ) ) DQUOTE log-rule = "cnt" *; LF UNDEFINED* rule-delim = LF**** ** I think it would be preferrable to employ a full BNF (with the exception of http-url), i.e., define these four items, too.
5. IANA Considerations
Do you want to say something about allocation policy on new enumerated values?
2.5. NAS-Filter-Rule
This is quite complicated. Do we have implementation experience that this works and is well defined?
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.
Or deleting, for that matter...
The filtering attributes specified in this document enable explicit description of layer 2 and layer 3 filters as well as redirection, and therefore extend the filter language described in [RFC3588].
This is OK, but the document is silent on what effect this has in Diameter. These effects are important because, for instance, 3GPP wireless LAN interworking is based on running Diameter on the 3GPP operator side and RADIUS in the access network side. Also, the RADEXT charter says: "All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification." Technically, we have two alternatives to get there. The first alternative is to make NAS-Filter-Rule(R) an extension of NAS-Filter-Rule(D). Given the same the same attribute name we appear to intend to do this already... The other approach would be to define NAS-Filter-Rule-Radius as a new Radius attribute and then allow its use in Diameter as well. I prefer the former approach. This is because I'd hate to see incremental improvements in various things such as filters always re-create new attributes upon every modification. But we still need language in this draft to explain the situation. And does that mean this document "updates RFC 3588 and 4005"? Editorial:
In this document when we refer to Blocking of IP traffic we mean Filtering of IP traffic.
Not sure if Capitalization is Needed.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag Option | Pad (12-bit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pad | VLANID (12-bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 6 Integer
The picture and text do not match. Show two pictures: one with "Integer" and then another one with the detailed substructure.
"l2:" Prefix on any base encapsulation rule to designate as rule as such.
"a rule as such"?
TODO / TBD
Two different placeholders are used. Just use TBD, or better yet, TBD-by-IANA so that they can better search for these.
[Jouni Korhonen]
I got few comments and additions to Jari's review. >> This is OK, but the document is silent on what effect this >> has in Diameter. These effects are important because, for >> instance, 3GPP wireless LAN interworking is based on running >> Diameter on the 3GPP operator side and RADIUS in the access network Actually, RADIUS is now allowed end to end. So all possible combinations exists (RADIUS or Diameter on AN, and RADIUS or Diameter on operator size). And then about the draft.. > A.2.3 HTTP Redirection Removal > > The RADIUS serve can turn HTTP redirection off mid-session in two > way. It can push new redirection rules within a NAS-Filter- > Rule(TBD) attribute using a CoA message or it can send the NAS a > CoA message requesting it to re-authorize. Aren't there three ways? The two as described above and the redir_cnt?
[Paul Congdon]
Good point. The redir-cnt approach is somewhat different because it is
set-up at the beginning of the session rather than removing the
redirection explicitly mid-stream. We should say something about
redir-cnt here though... How about the following text?
A.2.3 HTTP Redirection Removal
HTTP Redirection rules can be automatically removed when using the
redir-cnt parameter or explicitly removed from the RADIUS server.
The RADIUS server can explicitly turn HTTP redirection off
mid-session in two ways. It can push new redirection rules within a
NAS-Filter-Rule(TBD) attribute using a CoA message or it can send the
NAS a CoA message requesting it to re-authorize. [Jouni]
This is much better. How about mentioning the mid-session for redir-cnt
as well? Something like:
"HTTP Redirection rules can be automatically removed mid-session
from the NAS when using the redir-cnt parameter or explicitly
removed from the RADIUS server."
Editorials:
A.2.3 HTTP Redirection Removal
"The RADIUS serve can" -> "The RADIUS server can"[Paul Congdon]
> Technically, we have two alternatives to get there. The first > alternative is to make NAS-Filter-Rule(R) an extension of > NAS-Filter-Rule(D). Given the same the same attribute name we > appear to intend to do this already... The other approach > would be to define NAS-Filter-Rule-Radius as a new Radius > attribute and then allow its use in Diameter as well. > At IETF-64, I believe we agreed to do the latter. I think this draft was supposed to rename the attribute to make that clear. Looks like we forgot to do that.
[Mauricio Sanchez]
Yes, this one fell through the cracks. Are there any suggestions in terms of names? How about something like NAS-Traffic-Rule or perhaps to reduce confusion possibility drop the 'NAS-' prefix and just call it 'Traffic-Rule'?
[Jari Arkko]
Before we start inventing new names, do you guys remember why we decided in IETF-64 that the second approach, a different attribute, was the right one? I'm hoping it was not me who argued for that, but can't remember the discussion at all... The reason I dislike new attributes because if we do it on every extension, we'll end up with a messy attribute set. From a RADIUS point of view this is a new attribute now, but not from Diameter. What happens when you do the next filter extension -- which IMHO seems likely? Yet another attribute? I hope not.
[Paul Congdon]
No, it was not you that argued for the new attributed. Here is what I remember of the meeting at IETF-64... The changes we have made are not simply extensions and the attribute we are defining is not purely a superset. There is no RADIUS attribute for this functionality and it has proven very difficult to take Diameter AVPs and try to move them back into RADIUS (as was seen with QoS-Filter-Rule) because of issues with data types, field lengths and other subtle problems. Also, I remember someone (maybe Glenn?) saying that there were problems with the current definition of IP-Filter rule that NAS-Filter-Rule in Diameter is based upon. Finally, since Diameter can much more easily support a Radius attribute than the other way around, we agreed that we should create a new Radius attribute. I agree with you that we do not want to make this the default behavior and we should strive to make consistent extensions. I think the complexity of this attribute didn't allow us to follow that path.
[David Nelson]
Well, I think that's true in the face of the RADEXT milestones, and the desire to see this draft advance rapidly. Given the ongoing work on RADIUS Design Guidelines to encompass additional data types and foster greater compatibility with Diameter AVPs, and the charter of the DIME WG, it is not inconceivable to come up with a single "improved" filter rule that would make RADIUS-Diameter attribute translation much easier. It would, however, in all likelihood delay this work for many months. It seems to me we have to decide which we value more highly: a [more] unified data model between RADIUS and Diameter or timely delivery of the 802-related extensions in RADIUS.
[Bernard Aboba]
I'm not sure we have to choose. We can split the document, removing the filter attributes and progressing the rest. From what I can see, there are no open issues relating to the VLAN/Priority attributes, so doing that could enable the VLAN/Priority document to be sent to the IESG for review by IETF 65. Unless we think that we can resolve the Diameter and Design Guidelines issues by the submission deadline for IETF 65, I don't see what other paths are available to completing this milestone in a timely way.
Proposed Resolution: Discuss
Issue 165: Allowed Usage
Submitter names: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: January 29, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00071.html
Document: IEEE 802-01
Comment type: 'T'echnical |
Priority: S
Section: Various
Rationale/Explanation of issue:
In Section 4, the Table of Attributes states the following:
The following table provides a guide to which attributes may be
found in which kinds of packets, and in what quantity.
Access- Access- Access- Access- CoA-
Request Accept Reject Challenge Req # Attribute
0 0+ 0 0 0+ TBD Egress-VLANID
0 0-1 0 0 0-1 TBD Ingress-Filters
0 0-1 0 0 0-1 TBD User-Priority-Table
The Egress-VLAN-Name attribute is not included in this table, nor is
it included in the IANA considerations section.
Section 2.1:
Multiple Egress-VLANID attributes can be delivered in an
authentication response; each attribute adds the specified VLAN
to the list of allowed egress VLANs for the port.
This would appear to indicate that the Egress-VLAN-Name attribute is
allowed in Access-Challenge, Access-Reject and Access-Accept packets.
Yet, the attribute table in Section 4 does not seem to permit
inclusion in Reject or Challenge packets.
Section 2.3:
Multiple Egress-VLAN-Name attributes can be delivered in an
authentication response; each attribute adds the named VLAN to
the list of allowed egress VLANs for the port.
This would appear to indicate that the Egress-VLAN-Name attribute is
allowed in Access-Challenge, Access-Reject and Access-Accept packets.
There is no entry in the Attribute Table to confirm this.
Section 2.4:There is no material on permitted usage of the
User-Priority-Table attribute.Proposed Resolution: Discuss
Issue 166: References Submitter names: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 29, 2006 Reference: Document: IEEE 802-01 Comment type: Editorial Priority: S Section: Various Rationale/Explanation of issue:It is not clear to me why RFC 2868, 3162, 3576, 3579, 3580, 3748 are listed as Normative References. For example, an implementer would not be required to consult these documents in order to implement the specification.
On the other hand, it seems like RFC 2674 and 3629 are referenced in a normative way; for example, if UTF-8 is supported, then an implementer would need to consult RFC 3629, no? The reference to IEEE 802 also seems to be normative.
Some of the references do not appear to be referenced in the specification. For example, there is no reference to RFC 1321, RFC 2866, RFC 2867, RFC 3748.
Proposed Resolution: Discuss
Issue 167: Compatibility with RFC 2866 and RFC 3576
Submitter names: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: January 30, 2006
Reference:
Document: IEEE 802-01
Comment type: Technical
Priority: S
Section: 1.4
Rationale/Explanation of issue:
Section 1.4 states:
1.4 Attribute Interpretation
Unless otherwise noted in the individual description of an
attribute contained herein, a NAS that conforms to this
specification and receives an Access-Accept message that contains
an attribute from this document that it cannot apply MUST
interpret this though an Access-Reject had been sent and MUST
terminate the session. If accounting is enabled on the NAS, it
MUST generate an Accounting-Request(Stop) message upon session
termination.
Similarly, if a NAS conforming to this specification and also
conforming to RFC 3576 [RFC3576] receives a CoA message that
contains an attribute from this document that it cannot apply, it
MUST NOT terminate the session and MUST generate a CoA-NAK packet
with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If
accounting is enabled on the NAS, it MUST NOT generate an
Accounting-Request(Stop) message in such instances.RFC 2866 does
not specify the generation of Accounting Stop messages resulting from Access-Reject packets. This document is therefore requiring RADIUS accounting clients to generate accounting records in circumstances where they would not otherwise do so. This raises the question of why this particular set of attributes would cause a special case modification to RFC 2866. Here is what RFC 3576 has to say about receipt of attributes in a CoA-Request:
If one or more authorization changes specified in a CoA-Request
cannot be carried out, or if one or more attributes or attribute-
values is unsupported, a CoA-NAK MUST be sent.
On inclusion of Error-Cause attributes:
It is possible that the NAS cannot honor Disconnect-Request or
CoA-Request messages for some reason. The Error-Cause Attribute
provides more detail on the cause of the problem. It MAY be
included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
messages.
Since inclusion of an Error-Cause attribute is generally optional, the
second paragraph mandates behavior not required by RFC 3576.[Bernard Aboba] How about this?
Unless otherwise noted in the individual description of an
attribute contained herein, a NAS that conforms to this
specification and receives an Access-Accept message that contains
an attribute from this document that it cannot apply MUST
interpret this though an Access-Reject had been sent and MUST
terminate the session.
Similarly, if a NAS conforming to this specification and also
conforming to RFC 3576 [RFC3576] receives a CoA message that
contains an attribute from this document that it cannot apply, it
MUST NOT terminate the session and MUST generate a CoA-NAK packet.Proposed Resolution: Accept
Issue 168: Editorial Comments Submitter names: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 1, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00082.html Document: IEEE 802-01 Comment type: Editorial Priority: 1 Section: Various Rationale/Explanation of issue:
Section 1.1 "Authenticator" "an entity that require" -> "an entity that requires" Section 2.2 "Description" "IEEE 802.1Q" -> "[IEEE8021Q]" Section 2.3 "Description" Please use either "VLAN ID" or "VLAN-ID" consistently. Section 2.3 "String" Should "802.1Q-2003" be "[IEEE8021Q]" or is this a new reference? The latter reference is dated January 1998 in Section 7.1. Section 2.5 "Description" "NAS-Filter-Rule process packets" -> "NAS-Filter-Rule processes packets" Section 2.5 "Description" There is a reference for HTTP, but not HTTPS. Section 2.5 "Description" "...if multiple NAS-Filter-Rule attributes are contained within an Access-Request or Access-Accept..." -> "...if multiple NAS-Filter-Rule attributes are contained within an Access-Accept or CoA-Request..." Section 2.5 "Description" "flush rules" are mentioned a dozen paragraphs into the section, but they're not explained until way down in the Text section. Shouldn't they be added as a type of rule in the Table after the second paragraph? Section 2.5 "Text" "ipv6-address" "match the rule" -> "match the rule." Section 2.5 "Text" "tcp-port" The text says this field can be used with UDP and SCTP in addition to TCP, so is it supposed to be called "port"? Section 2.5 "Text" "tcpoptions" Do you want Informative references for RFCs 1323 & 1644? Section 2.5 "Text" "redir_cnt" "redir_cnt Specifies" -> "redir_cnt Specifies" Section 3.1 "String" "specify which filter rule the counter value is for." -> "specify for which filter rule the couter is a value." Section 5 "Allocation of seven updates..." -> "Allocation of five updates..." Section 6 "nabled networks" -> "enabled networks" "in message it sends." -> "in messages it sends." Section A.1.2 "(eg. Mobile-IP)" -> "(e.g. Mobile-IP)" Section A.1.4 "and in both directions" -> "Flow in a tunnel in two directions" Section A.1.4 "and an NAS-Filter-Rule" -> "and a NAS-Filter-Rule" "packet(as" -> "packet (as" Section A.2 "the users browser" -> "the user's browser" Section A.2.1 "the RADIUS MAY" -> "the RADIUS server MAY" Section A.2.2 "CoA message" -> "CoA-Request message" (several occurrences) Section A.2.3 "The RADIUS serve can" -> "The RADIUS server can" "in two way." -> "in two ways." Section A.4 "IEEE 8021X environment" -> "IEEE 802.1X environment" "their hotel room" -> "her hotel room" "WiFi is" -> "WiFi and is" Section B Examples #7 & #8 Replace "foo.org" and "goo.org" with domains from RFC 2606.
[Greg Weber]
I see that draft-ietf-radext-filter-rules-00.txt fixes most of the editorial comments I made as part of issue 168. I guess we can close this issue if the authors will just agree to fix this (at some point): - The IANA section says the draft is allocating six attributes, but it's only allocating two.
Proposed Resolution: Accept
Issue 169: Handling Unparsable NAS-Filter-Rule Submitter names: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00104.html Document: IEEE 802-01 Comment type: Technical Priority: S Section: 1.4, 6 Rationale/Explanation of issue:
The NAS-Filter-Rule represents a *lot* of functionality. I think we can expect lots of variability in NASes which support various parts, e.g. maybe all the filtering, but not HTTP redirection, etc. I think we maybe need to be clearer on what is supposed to happen when the NAS gets a CoA-Request or Access-Request containing directives that it cannot parse or apply. In particular, in Section 1.4 "Attribute Interpretation", I see text indicating that non-understood attributes result in Access-Rejects. But, in Section 6 "Security Considerations", I see text like: "...a NAS could be configured to ... not accept any redirection rules if it is known they are not used in this environment." These would seem to be contradictory. Requested change: Need clarification on the intent.
[Mauricio Sanchez]
>Requested change: >Need clarification on the intent. I hear you on this issue. How about the change of section 1.4 to read from: "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject." To "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject. A NAS may be incapable of applying an attribute due to functional limitations of the NAS or security reasons (as described in section 7 - Security Considerations)." Does this help?
Proposed Resolution: Discuss
Issue 170: Precedence and Order for NAS-Filter-Rule Submitter names: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00103.html Document: IEEE 802-01 Comment type: Technical Priority: S Section: 2.5 Rationale/Explanation of issue:
At the very end of Section 2.5 on NAS-Filter-Rule, it says that the NAS can apply rules of its own before rules supplied via the interface in this document. I didn't understand the ordering and precedence between filters originated from the different sources. Is that covered somewhere? If the server sends a flush-rule via CoA-Request, does that remove the NAS originated (configured) rules? The text is implying that the rules are applied in specific order based on type, e.g. HTTP filter rules are last. What if the NAS defines the HTTP filter rule, and other types come via CoA? What's the order then? This seems like an area of likely implementation confusion. Requested change: I think the precedence of locally configured rules relative to dynamic updates needs to be clarified. It might also be useful to treat this in the examples of Appendix B. This seems similar to Issue 107 related to Acct-Interim-Interval. The NAS owner needs to be able to protect his resources, and the server owner needs predictable results for dynamic updates.
[Mauricio Sanchez]
>At the very end of Section 2.5 on NAS-Filter-Rule, >it says that the NAS can apply rules of its own before >rules supplied via the interface in this document. >I didn't understand the ordering and precedence >between filters originated from the different sources. I see your point. The thought was not to give complete treatment to all possible active rules sets (i.e. those specified by RADIUS, those configured locally, those rule the PEP enforces because of security considerations), but at least acknowledge that other active rules do exist and that they may influence the ultimate forwarding decision. What if the statement in question were changed as follows? "A NAS MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure." To "A NAS MAY apply additional rules (deny, redirect, etc.) of its own before, in between, or after rules specified with NAS-Traffic-Rule. For example, these additional rules may protect the access device owner's infrastructure. Management of these additional rules is out of scope and are not subject to the semantics or behaviors described for NAS-Traffic-Rule." >Is that covered somewhere? If the server sends a >flush-rule via CoA-Request, does that remove the >NAS originated (configured) rules? The text is implying By NAS originated do you mean those rule sets not assigned via the RADIUS interface? If so, then the answer is no. The process of assignment, updates, and flushing only affect those rules controlled by RADIUS. >that the rules are applied in specific order based on >type, e.g. HTTP filter rules are last. What if the NAS >defines the HTTP filter rule, and other types come via >CoA? What's the order then? This seems like an area >of likely implementation confusion. If that HTTP filter was not assigned through the RADIUS interface, then flushes and CoA messages have no effect on it. The guidelines for rule ordering are only relevant for those controlled via this RADIUS specification. I see it as out of scope on mandating how non-RADIUS rules should behave. > >Requested change: >I think the precedence of locally configured rules >relative to dynamic updates needs to be clarified. >It might also be useful to treat this in the examples >of Appendix B. This seems similar to Issue 107 >related to Acct-Interim-Interval. The NAS owner needs >to be able to protect his resources, and the server >owner needs predictable results for dynamic updates.
[David Nelson]
> "A NAS MAY apply additional rules (deny, redirect, etc.) > of its own before, in between, or after rules specified > with NAS-Traffic-Rule. For example, these additional rules > may protect the access device owner's infrastructure. > Management of these additional rules is out of scope and are > not subject to the semantics or behaviors described for > NAS-Traffic-Rule." Wow. In other words, the entity that creates a NAS-Traffic-Rule attribute really has no idea what the aggregate traffic filtering behavior of a given NAS will be. So what makes this new attribute useful? > The guidelines for rule ordering are only relevant for those > controlled via this RADIUS specification. I see it as out of > scope on mandating how non-RADIUS rules should behave. Fair enough. I still wonder how useful this attribute will be if the administrator that sets it up has no idea which (if any) of the elements he has specified will be enforced by the NAS, and which (potentially all) of the elements are superseded by a local NAS filtering rule. I can see this mechanism working in a predictable fashion only in certain situations, based on assumptions of the locally configured NAS rules that take precedence.
[Bernard Aboba]The Filter-Id attribute refers to a particular set of filters provisioned on the NAS. This document says that NAS-Traffic-Rule is not to be sent along with Filter-Id. Yet somehow a filter set described by Filter-Id can be activated without any explicitly indications from the RADIUS server? This seems to be contradictory.
I can see this mechanism working in a predictable fashion only in certain situations, based on assumptions of the locally configured NAS rules that take precedence.
As I understood it, the whole point of this attribute was to enable the RADIUS server to explicitly specify the filters that would be in operation, even in situations where the server had no knowledge of what filters are provisioned on the NAS. So this new approach does not make sense to me.
Proposed Resolution: Discuss
Issue 171: Tag Option in VLAN attributes Submitter names: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00102.html Document: IEEE 802-01 Comment type: Technical Priority: S Section: 2.1, 2.3 Rationale/Explanation of issue:
The Egress-VLANID attribute proposed in Section 2.1
is defined as data type "Integer":
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag Option | Pad (12-bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pad | VLANID (12-bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I think this is going to be confusing because it similar
formatting to the 'tagging mechanism' defined in RFC 2868.
Also wondering if it's possible to not overload a single
integer with two values? Won't this make configuring the
value on the server more difficult. Can each VLAN have
an independent tagged/untagged value? Why are 0x31 & 0x32
used?
Requested change:
At least, I'd suggest changing "Tag Option" to "VLAN Tag"
or something like that. Guess I'd have to understand
this better to suggest if the Tag and ID can be separated.Proposed Resolution: Discuss
Issue 172: Authorize-Only Usage in HTTP Redirect Submitter names: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00101.html Document: IEEE 802-01 Comment type: Technical Priority: S Section: A2.2 Rationale/Explanation of issue:
Section A.2.2 Mid-session HTTP Redirection reads:
If HTTP redirection is required to be applied to a service that
has already been started then the RADIUS server can push the
redirection rules, and optionally the filter rules, to the NAS
within a NAS-Filter-Rule(TBD) attribute using a CoA message. The
NAS will then commence to apply the redirection rules and/or the
filter rules.
Alternatively, the RADIUS server can request that the NAS re-
authorize the session using the procedures defined in [RFC3576].
The RADIUS server responds with an Access-Accept message (with
Service-Type(6) set to "Authorize Only" that will contain the
redirection and optionally filtering rules within a NAS-Filter-
Rule(TBD) attribute.
I don't think "Authorize Only" is a valid Service-Type value in
Access-Accept messages. The server should be indicating the
assigned Service in the Access-Accept. Take a look at the last
paragraph of RFC 3576's Section 1.1. I think that describes the
process your referring to here.
Requested change:
I suggest replacing the above text with something like:
If HTTP redirection is required to be applied to a service that
has already been started, then the RADIUS server may use either
of the procedures defined in [RFC3576]:
- The server may send the NAS a CoA-Request message including
a NAS-Filter-Rule which contains redirection rules and
optionally filter rules. The NAS will then apply the new
rules to the existing services.
- The server may send the NAS a CoA-Request message including
a Service-Type attribute with the value of "Authorize Only".
This will trigger the NAS to reauthorize the existing service
by sending the server an Access-Request message containing a
Service-Type attribute with the value of "Authorize Only".
The server may then send the NAS new redirection and optionally
filter rules within a NAS-Filter-Rule as part of an Access-
Accept message.Proposed Resolution: Discuss
Issue 173: Client Nonce Generation Submitter names: Sam Hartman Submitter email address: hartmans-ietf@mit.edu Date first submitted: February 2, 2006 Reference: Document: DIGEST-05 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue:
I don't think the security considerations surrounding client nonce generation are correct. In particular, I believe the security of digest authentication depends on the server choosing a fresh nonce to prevent replays. Take a look at section 3 in draft-ietf-sasl-rfc2831bis. In the case where the RADIUS client chooses the nonce then the RADIUS client is being trusted to avoid these attacks. In many environments the load considerations which seem to be the primary motivation for client nonces in this spec would not justify that trust. Please either explain to me why these concerns do not exist or document them. If these concerns exist, then please add a recommendation for server nonces in cases where load is not an issue. If there are attacks that can be mounted when client nonces are used, servers need to offer a configuration in which client nonces are refused; this is not provided by the current server behavior. I don't believe a normative reference to RFC 3310 is appropriate. RFC 3310 is very clearly not a standards-track protocol.
Proposed Resolution: Discuss
Issue 174: Review Submitter names: Russ Housley Submitter email address: rhousley@vigilsec.com Date first submitted: February 2, 2006 Reference: Document: DIGEST-05 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue:
Please include an informative reference for CHAP in section 1.3. Section 3.1 says: > > The RADIUS server MAY have added a Digest-Nextnonce attribute into an > Access-Accept packet. If the RADIUS client discovers this, it puts > the contents of this attribute into a 'nextnonce' directive. Now it > can send an HTTP-style response. > Perhaps a better wording might be: > > When the RADIUS server provides a Digest-Nextnonce attribute in the > Access-Accept packet, the RADIUS client puts the contexts of this > attribute into a 'nextnonce' directive so that it can send an > HTTP-style response. Section 4.9 says: > >4.9. Digest-Algorithm attribute > > Type > s/Type/Description/ Section 4.20 says: > >4.20. SIP-AOR > > Type > s/Type/Description/ Section 7 says: > > A->B > > INVITE sip:97226491335@example.com SIP/2.0 > Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" > ,opaque="",realm="example.com" > ,response="f3ce87e6984557cd0fecc26f3c5e97a4" > ,uri="sip:97226491335@10.0.69.38",username="12345678" > From: <sip:12345678@example.com> > To: <sip:97226491335@example.com> > > B->C > > Code = 1 (Access-Request) > Attributes: > NAS-IP-Address = a 0 45 26 (10.0.69.38) > NAS-Port-Type = 5 (Virtual) > User-Name = "12345678" > Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" > Digest-Realm = "example.com"
> Digest-Nonce = "3bada1a0" > Digest-Method = "INVITE" > Digest-URI = "sip:97226491335@example.com" > Why is the value of Digest-URI not the same URI provided by A? [Russ Housley] Section 2 says: > > As there is no automatic capability exchange, the operator MUST > make sure that the RADIUS client software uses the correct nonce > generation mode when accessing a specific RADIUS server: > This use of "MUST" does not seem right to me. The "operator" is a human, so it does not seem like a situation covered by RFC 2119. Section 3.1 says: > > It puts the 'response' directive into a Digest-Response attribute > and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc / > username / opaque directives into the respective Digest-Realm / > Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm / > Digest-CNonce / Digest-Nonce-Count / Digest-Username / Digest-Opaque > attributes. > What does the slash character (/) signify? In ABNF, the slash character separates choices, but that does not seem to be the right context. I think that "respective" is key to understanding this sentence. Please reword. I find it very confusing. Section 4.2 says: > > This attribute describes a protection space of the RADIUS server. > See [RFC2617] 1.2 for details. It MUST only be used in Access-Request > and Access-Challenge packets. > Section 1 says that a protection space is the combination of realm and digest URI, but this says this text only includes a Realm. Is this attribute used in conjunction with something else to determine the protection space? Section 4.7 says: > > If the HTTP-style request has an Authorization header, the RADIUS > client puts the value of the "uri" directive in the (known as > "digest-uri-value" in section 3.2.2 of [RFC2617]) without quotes > into this attribute. > Are the quote characters removed? I do not think that is the intended meaning. Perhaps it should say: "without quoting."
Proposed Resolution: Discuss
Issue 175: Some Nits Submitter names: Bert Wijnen Submitter email address: bwijnen@lucent.com Date first submitted: February 2, 2006 Reference: Document: DIGEST-05 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue:
Page 26 NAS-IP-Address = a 0 45 26 (10.0.69.38) Probably IP address should be changed to be in accordance with IP addresses for examples (RFC3330), i.e. 192.0.2.0/24 range [Jon Peterson] The HTTP example in Section 7 shows a WWW-Authenticate header in a 407 response and an Authorization in the reissued GET. Shouldn't a 407 contain a Proxy-Authenticate, and the reissued get a Proxy-Authorization? Or perhaps the authors intended this to be a 401, as the sentence of explanatory text prior to the example does not suggest the presence of a proxy. [Jon Peterson] The authors might note, contrary to implications of the motivational text in 1.2, that RFC3261 did not intend to supplant Digest authentication with TLS and S/MIME. Digest is still mandatory and is the preferred way for a UA to authenticate itself to a proxy server. This just furthers the need for this mechanism, of course - the text in 1.2 makes it sound like Digest a legacy mechanism for SIP.
Proposed Resolution: Discuss
Issue 176: Diameter Compatibility
Submitter name: Greg Weber
Submitter email address: gdweber@cisco.com
Date first submitted: February 21, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00186.html
Document: VLAN-00
Comment type: Editorial
Priority: S
Section: Various
Rationale/Explanation of issue:
In the RADEXT charter, I see:
"...all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability
with Diameter will be maintained."
The VLAN draft does not contain a Diameter compatibility
section, but does mention (in the abstract) that these
attributes can be used with Diameter.
Requested change:
The table of attributes in section 3 shows which attributes
may be in which RADIUS messages. Maybe another similar
table is needed in a Diameter Compatibility section showing
which Diameter applications/messages may include these attributes.
Also, I see one typo that wasn't in the previous version :)
Section 1.3: 'Unsupported Attribute"' ->
'"Unsupported Attribute"' (missing double quote).[Bernard Aboba]
How about this? Fix the typo. Insert a section 4 that says the following: 4. Diameter Considerations Diameter needs to define identical attributes with the same Type values. The attributes should be available as part of the NASREQ application [RFC4005], as well as the Diameter EAP application [RFC4072]. Add Informative references to [RFC4005] and [RFC4072].
Proposed Resolution: Discuss
Issue 177: AD Review of RFC 3576 MIBs Submitter name: Bert Wijnen Submitter email address: bwijnen@lucent.com Date first submitted: March 3, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00215.html Document: RFC3576MIBs Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue:
1. In the MIB MODULE IDENTITY DESCRIPTION clause it says:
DESCRIPTION
"The MIB module for entities implementing the server
side of the Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS) protocol.
Copyright (C) The Internet Society (2005). Initial
version as published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available on
http://www.ietf.org/copyrights/ianamib.html.";
That last sentence is NOT applicable. There is nothing in this MIB
module that is mainatined by IANA, so their copy-right web page is
not relevant. Fix is to just remove last sentence.
2. The a whole serioes of Counter32 objects.
I wonder what the object is to indicate a counter-discontinuity?
Or can such only happen at system restart/reboot?
See RFC2578 that explains this in sect 7.1.6
RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it.
3. I see
radiusDynAuthClientAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of IP address of the RADIUS Dynamic
Authorization Client referred to in this table entry."
::= { radiusDynAuthClientEntry 2 }
radiusDynAuthClientAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address value of the RADIUS Dynamic
Authorization Client referred to in this table entry,
using the version neutral IP address format."
::= { radiusDynAuthClientEntry 3 }
So, the radiusDynAuthClientAddress needs to specify that the address is
formatted according to the value of radiusDynAuthClientAddressType.
Also, as far as I can tell, any addressType could be present here,
so formally, you would need to describe when a dns name has been
resolved (if it occurs).
Same for both MIB documents.
Point 1 I can do with an RFC-Editor note.
Point 2 I can also address with an RFC-Editor not if the intend (default)
is that a dsiscuntinuity can only occur at system re-initiatlization.
If so, I suggest to add an entry to the DESCRIPTION clause of the
table itself that states:
Discontinuities for all counter32 objects in this table can
only occur at system re-initialization.
So no specific discontinuity onjects have been defined.
Point 3 Mmm... I guess there will only be ipv4 or ipv6 addresses.
If so, I can live with it since this is a read-only MIB module
and the doc is Informational.> -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Friday, March 03, 2006 15:36 > To: 'Nagi Reddy Jonnala (njonnala)'; j.schoenwaelder@iu-bremen.de; > radiusext@ops.ietf.org > Subject: RE: radius dynauth client/server mibs structure > > > Are there implementations already? > If not, I would also recommend to make the change suggested > by Juergen. > If yes, even then the suggested change is still simple now. > > The disadvantage of not doing so is in the future when adding scalars > and thing not having grouped as nicely and so more complexity. > > This is not a blocking comment, just another MIB-type person believing > that the change would be real EASY now, and it will certainly make > things cleaner/easier in the future. > > Bert > > > -----Original Message----- > > From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] > > Sent: Tuesday, February 14, 2006 11:24 > > To: j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org > > Cc: Bert Wijnen > > Subject: RE: radius dynauth client/server mibs structure > > > > > > Juergen, > > > > Your comments may be correct. We authors have discussed about your > > comments and realized that the comments are not directly related to > > these MIBs but in general whether the scalars should be > > grouped together > > or not. The recommended way can best be addressed in the IETF MIB > > guidelines. Since there seem to be plenty of MIBs that don't > > follow your > > commented approach, no recommended way in the IETF MIB > guidelines and > > because it is a stylistic change, we leave the MIBs as they are. > > > > Thanks > > Nagi. > > > > > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] > > On Behalf Of Juergen Schoenwaelder > > Sent: Thursday, February 09, 2006 12:03 AM > > To: radiusext@ops.ietf.org > > Cc: Bert Wijnen > > Subject: radius dynauth client/server mibs structure > > > > Hi, > > > > I took a quick look at the radius dynauth client/server mibs today: > > > > draft-ietf-radext-dynauth-client-mib-03.txt > > draft-ietf-radext-dynauth-server-mib-03.txt > > > > While looking at the OID tree, I came up with the following > stylistic > > change. Currently, the OID tree of the two MIBs basically looks like > > this (details of the tables and conformance nodes deleted): > > > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > > | > > +--radiusDynAuthServerMIBObjects(1) > > | | > > | +--radiusDynAuthServer(1) > > | | > > | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > > | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > > | +--radiusDynAuthServerIdentifier(3) > > | | > > | +--radiusDynAuthClientTable(4) > > | > > +--radiusDynAuthServerMIBConformance(2) > > > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > > | > > +--radiusDynAuthClientMIBObjects(1) > > | | > > | +--radiusDynAuthClient(1) > > | | > > | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > > | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > > | | > > | +--radiusDynAuthServerTable(3) > > | > > +--radiusDynAuthClientMIBConformance(2) > > > > I was wondering what the value of having the radiusDynAuthServer and > > radiusDynAuthClient nodes is. I do understand if people > like to group > > related scalars together (so additions are numbered using > consecutive > > identifiers), but then the OID structure should more look like the > > following: > > > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > > | > > +--radiusDynAuthServerMIBObjects(1) > > | | > > | +--radiusDynAuthServerScalars(1) > > | | | > > | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > > | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > > | | +--radiusDynAuthServerIdentifier(3) > > | | > > | +--radiusDynAuthClientTable(2) > > | > > +--radiusDynAuthServerMIBConformance(2) > > > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > > | > > +--radiusDynAuthClientMIBObjects(1) > > | | > > | +--radiusDynAuthClientScalars(1) > > | | | > > | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > > | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > > | | > > | +--radiusDynAuthServerTable(2) > > | > > +--radiusDynAuthClientMIBConformance(2) > > > > The benefit of this change is that you can add scalars later > > while keep > > all the scalars rooted together and consecutively numbered > > while in the > > current scheme you end up to have tables intermixed with > scalars over > > time. > > > > Please note that there is nothing technically wrong with the MIBs as > > they are right now. My suggestion is purely stylistic and > > basically just > > increases readability in case updates are done in the future. > > > > I am aware that these MIB modules have passed WG last call and MIB > > review and are in the hands of the ADs and as such I do not > > ask to make > > a change just for stylistic reasons. I just wanted to bring > > this to your > > attention and I like to leave it to the editors/chairs to > > decide whether > > you want to make the relatively simple changes at this point > > in time or > > prefer to go ahead with what you have. > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, > > 28725 Bremen, > > Germany Proposed Resolution: Discuss
Issue 178: Allowing Hints in Request Messages Submitter name: Mauricio Sanchez Submitter email address: mauricio.sanchez@hp.com Date first submitted: March 6, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00225.html Document: draft-ietf-radext-vlan-00.txt Comment type: T Priority: 2 Section: Table in section 3, individual attributes Rationale/Explanation of issue:
Draft-ietf-radext-vlan-00 does not allow
the new attributes to be sent in ACCESS-REQUEST messages. If allowed,
attributes in the REQUEST message could serve as 'hints' to the RADIUS
server during the decision making process.
Requested change: Allow attributes to be sent ACCESS-REQUEST message
Proposed changes to the document.
- Descriptions of individual attribute descriptions would be changed to
allow attributes in access request, as follows:
Multiple <attr_name> attributes MAY be included in an Access-Request,
Access-Accept or CoA-Request packet; this attribute MUST NOT be sent
within an Access-Challenge, Access-Reject, Disconnect-Request,
Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
-Table in section 3 would be changed to:
Access- Access- Access- Access- CoA-
Request Accept Reject Challenge Req # Attribute
0+ 0+ 0 0 0+ TBD Egress-VLANID
0-1 0-1 0 0 0-1 TBD Ingress-Filters
0+ 0+ 0 0 0+ TBD Egress-VLAN-Name
0-1 0-1 0 0 0-1 TBD User-Priority-Table
Proposed Resolution: AcceptIssue 179: Editorial Issue Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00279.html Document: VLAN/Priority -00 Comment type: 'E'ditorial Priority: '1' Should fix Section: 1.3 Attribute Interpretation Rationale/Explanation of issue: missing quote Requested change:
s/value set to Unsupported Attribute" (401)/value set to "Unsupported Attribute" (401)/
Proposed Resolution: Accept
Issue 180: Misuse of Data Types Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html Document: VLAN/Priority -00 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.1. Egress-VLANID Rationale/Explanation of issue: I had previously raised this issue, and the resolution was we could use a RADIUS data type of Integer, because only the VLANID (12-bit) portion would be used. Thus, this object could be thought of as a range-limited integer. Since I see that we still have the VLAN Tag fields, that resolution falls apart. I claim that this data object is not an Integer. Someone offered the suggestion that Integers are not simply the mathematical definition, i.e. the positive and negative whole numbers and zero, that we all learned in high school. With all due respect, I think that's patently wrong. It is true that one can write programs that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data structures using mask, bit-field, shift and rotate operations. I still claim that those data structures are *not* integers simply because they can be packed within the computer memory storage that is also used by integers. Hopefully, there is more to data modeling than the storage length in bits. :-) We are currently having a debate on the RADEXT WG list about the issue of derived data types, and no consensus has yet been reached. However, until such a consensus is reached, it seems most appropriate to follow the existing practice of defining derived data types as Strings, with the bit-fields described in the text. I think that over-loading base RADIUS data types with new meanings is inappropriate. Given the relative timing of WGLC on this draft and the emerging consensus on RADIUS Attribute Design Guidelines, I think this is the best compromise. Requested change: OLD: Integer The Integer field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. NEW: String The String field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. Section: 2.3. Egress-VLAN-Name Rationale/Explanation of issue: I'm rather uncomfortable with the usage of the VLAN Tag field, as it seems to be at variance with the emerging WG consensus on complex or structured data types. Once we standardize this usage, there will be one more precedent in a RADIUS RFC to support ad-hoc data typing. If that's what RADEXT ultimately recommends, then this will be fine. If the recommendation is to use a more formal method of aggregating structured data, this will be one more anomaly. VLAN Tag The VLAN tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). Requested change: I have no idea what (if any change) to request. Chalk this comment up as my personal lament over the process that RADEXT has followed -- delaying consensus on attributes design to the point where we are standardizing new attributes using complex data types prior to having defined the design guidelines for complex data types. Section 2.4 User-Priority-Table Rationale/Explanation of issue: With all due deference to the well understood "array - string duality" we find in programming languages such as C, I think that expressing a attribute whose value is an array in the form of a RADIUS String type is unfortunate, for the reasons expressed above. Requested change: (See above.) The only way that I see to actually resolve my data typing / data modeling concerns is to delay sending any RADEXT work item that uses derived data types to the IESG until after we have sent the RADIUS Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, and that approach is not compatible with our milestones.
[Glen Zorn]
With all due respect, I think that you are the one doing the overloading: RFC 2568 says integer 32 bit unsigned value, most significant octet first. That's it. No range, no interpretation, nothing else.
[Emile Van Bergen]
> I see nothing that indicates this data type is anything other than an > integer, typically expressed in a C language declaration as "unsigned > long". You're completely correct. And in the case of the VLAN attribute, it *does* contain an unsigned integer value, one that's calculated as follows: value = vlanflag * 16777216 + vlanid The reverse goes as follows: vlanflag = value / 16777216 vlanid = value % 16777216 (where * denotes unsigned integer multiplication, + denotes unsigned integer addition, / denotes unsigned integer division and % denotes taking the reminder of an unsigned integer division, all to be carried out on unsigned integers in the range 0 .. 2**32-1) I'm not believing that people on this list would have to be explained that shifting and masking bits are *not* magic operations that you can only perform if you program in assembly (or its portable flavour, C), but that those are normal mathematical operations on normal integers: multiply and take remainder (by powers of 2). You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever. This whole issue has nothing whatsoever to do with C structures.
[Bernard Aboba]
Proposed Resolution:
Change "VLAN Tag" to "VLAN Flag" throughout the document.
[Greg Weber]
Now the VLAN-01 strawman says:
The VLAN Flag field is one octet in length,
and indicates whether the frames on the VLAN
are tagged (0x31) or untagged (0x32).
But it doesn't say *how* the flag field indicates
tagged vs. untagged. With the attribute name being
VLAN Flag, I would think that attribute's values
would be 1 or 0. Do I indicate 'tagged' by setting
the value of VLAN Flag to 1 or to 0x31?Proposed Resolution: Discuss
Issue 181: Review Submitter name: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: March 16, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00311.html Document: VLAN/Priority -00 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue:
I believe that the document is in pretty good shape, I still have a few
comments which I believe are worth being considered.
Content:
1. [RFC2674] is now obsoleted by [RFC4363]. I suggest to modify this
reference.
2. The supplicant definition in 1.1 says:
A supplicant is an entity that is being authenticated by an
authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN segment or
802.11 wireless link.
It is not clear why 'point-to-point' is mentioned here seemingly as
opposed to wireless. I believe that the point that is being made is
about connecting to a point-to-point or shared LAN segment. I suggest to
replace this by:
A supplicant is an entity that is being authenticated by an
authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point or shared LAN
segment
3. I believe that there is at least one other example of security attack
by insertion of attributes with a malicious content that is worth being
mentioned. This is the case when the user priority table is modified
causing either degradation of quality of service by downgrading user
priority of packets arriving at a port, or denial of service by
oversubscribing the switch or link capabilities by raising the level of
priority of traffic at multiple ports of a device.
Editorial:
1. It is recommended that abstract sections expand acronyms with the
exception of the obvious (IP, TCP, etc...). I would say that VLAN and
RADIUS are not in the obvious category.
2. NAS shows up first in section 1.3 and is not expanded.
3. The first phrase in Section 5 seems broken, I read it as the document
being vulnerable, which is not the intent, I believe. [David Nelson]
That is a good point. I think that further clarification would be
desirable, however. My recollection of IEEE 802.1X is that it applies
to ports, which may be point-to-point LAN links, or virtual ports on
shared media defined by a protected association.
So perhaps we could extend the suggested text, as follows:
A supplicant is an entity that is being authenticated by an
authenticator. The supplicant may be connected to the
authenticator at one end of a point-to-point LAN link or via
a protected association over a shared LAN segment.[Bernard Aboba] Added expansions of VLAN, RADIUS, NAS, etc. Fixed the references.
I noticed that the definitions are different from those used in [RFC3748]. This is probably not a good idea.
Recommend replacing them with the RFC 3748 and RFC 4005 definitions:
Authenticator The end of the link initiating EAP authentication. The term authenticator is used in [RFC3748] and [IEEE-802.1X], and has the same meaning in this document.
backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X].
Network Access Server (NAS) A device that provides an access service for a user to a network.
Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X].
Rewrote the security considerations section as follows:
"This specification describes the use of RADIUS for purposes of authentication, authorization and accounting in networks supporting [IEEE 802.1X]. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. This document specifies new attributes that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. See those documents for a more detailed description. The security mechanisms described in [RFC3579] and [RFC3576] are focused on preventing an attacker from spoofing packets or modifying packets in transit. They do not prevent an authorized RADIUS server or proxy from inserting attributes with malicious intent. VLAN attributes sent by a RADIUS server or proxy may enable access to unauthorized VLANs. These vulnerabilities can be limited by performing authorization checks at the NAS. For example, a NAS can be configured to accept only certain VLANIDs from a given RADIUS server/proxy. Similarly, an attacker gaining control of a RADIUS server or proxy can modify the user priority table, causing either degradation of quality of service (by downgrading user priority of packets arriving at a port), or denial of service (by raising the level of priority of traffic at multiple ports of a device, oversubscribing the switch or link capabilities)."
Proposed Resolution: Accept
Issue 182: AD Review Submitter name: Bert Wijnen Submitter email address: bwijnen@lucent.com Date first submitted: March 18, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00356.html Document: RFC2618bis-2621bis Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue:
I did just do draft-ietf-radext-rfc2618bis-02.txt
The others probably have similar minor issues.
As far as I am concerned, we can do IETF Last Call (these go
for standards track so we must do IETF LC) now. You can then
consider below comments as the first set of IETF LC comments.
And then address them right after IETF Last Call, or maybe you
want to wait and see if there are any IESG comments that you
could address at the same time. By that time, Dan will tell
you how to proceed.
Bert
---- comments
somewhat MUST change comments (easy, and basically admin
bureaucracy, but would be good to change):
We do want a copyright statement in the DESCRIPTION clause of a module
identity. So change
OLD:
DESCRIPTION
"The MIB module for entities implementing the client
side of the Remote Authentication Dial-In User Service
(RADIUS) authentication protocol."
NEW:
DESCRIPTION
"The MIB module for entities implementing the client
side of the Remote Authentication Dial-In User Service
(RADIUS) authentication protocol.
Copyright (C) The Internet Society (2006). This version
of this MIB module is part of RFC xxxx; see the RFC
itself for full legal notices."
-- RFC Ed.: replace xxxx with actual RFC number & remove this note
- radiusAuthServerInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the RADIUS authentication
server referred to in this table entry, using
the version neutral IP address format."
::= { radiusAuthServerExtEntry 3 }
according to RFC4001, you MUST specify which object of SYNTAX
InetAddressType controls the format of this object. I t is clear
which one it is, b ut it would be good to add that.
- radiusAuthClientServerInetPortNumber
According to RFC4001, you must specify what the value zero means
for this object.
- for this one
radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for authentication
clients implementing the RADIUS Authentication
Client IPv6 Extensions MIB. Implementation of
this module is for entities that support IPv6,
or support IPv4 and IPv6."
MODULE -- this module
MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }
::= { radiusAuthClientMIBCompliances 2 }
I think it would be better to do:
radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for authentication
clients implementing the RADIUS Authentication
Client IPv6 Extensions MIB. Implementation of
this module is for entities that support IPv6,
or support IPv4 and IPv6."
MODULE -- this module
MANDATORY-GROUPS { radiusAuthClientExtMIBGroup }
OBJECT radiusAuthServerInetAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is only required to support IPv4 and
globally unique IPv6 addresses."
OBJECT radiusAuthServerInetAddress
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is only required to support IPv4 and
globally unique IPv6 addresses."
- real nits and admin stuff
!! Contains embedded space:
P004 L021: textual conventions defined in this memo [RFC 4001] that support all
!! Missing citation for Normative reference:
P020 L018: [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
!! Missing citation for Normative reference:
P020 L022: [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
!! Missing citation for Normative reference:
P020 L049: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
!! Missing citation for Normative reference:
P021 L006: [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
RFC2574 and RFC2575 should be replaced by RFC3414 and RFC3415
RFC3410 is better listed as an Informative reference.
In general, pls re-check all citations/references.Proposed Resolution: Accept
Issue 183: Counter Wrap Submitter name: Carl Kalbfleisch Submitter email address: carlk@netrake.com Date first submitted: March 28, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00407.html Document: RFC2618bis-2621bis Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue:
I have implemented RFC-2618 and RFC-2620 in our security gateway. We allow the user to configure two accounting and two authentication servers. These show up as instances 1 and 2 in the associated tables in these MIBs. Now an issue arises if the user changes the IP or port of the radius servers. The system is now pointing to a different server. However, the counters are still whatever they are. I have a request to clear the counters, but this could cause spikes in the NMS to think the counter wrapped. What is needed is some discontinuity time value. I was thinking of overloading the IP and port attributes for our implementation and telling end users that if those values change then the counters should be treated as a discontinuity event. I realize that this would be non-standard so wanted to get some feedback on best practices. I realize that these MIBs are being updated, so perhaps we can add a discontinuity timer in a future revision. if so, I would suggest adding it per radius entry so that each server can have its own value. One other point to note. We have found that radius servers respond faster than 100th of a second. I'd suggest an update to the MIB where the response time is stored in micro-seconds. In addition, having the minimum, maximum and average are also helpful. We are adding such values to our enterprise MIB, but would opt for standard attributes if they existed.
Several more comments on discontinuity:
1) http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt defines only one object.
radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE
SYNTAX TimeTicks
UNITS "hundredths of a second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time (in hundredths of a second) since the
DAC module was last re-initialized."
::= { radiusDynAuthClientScalars 3 }
I recommend adding this attribute to the RadiusDynAuthServerEntry instead. The issue is that (for example in our box) we have instances of authentication MIB tables spread accross multiple nodes. Therefore it is possible for a node to reboot and have discontinuities independent of the mib as a whole.
2) The update to RFC-2618 http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt does not have a discontinuity timer. Again, I suggest adding the value to the table. Also, it there some reason why the authors did not just deprecate the radiusAuthServerAddress and then add the IPv6 attributes to the existing table. IE, why deprecate the entire table.
3) same comments as 2 for the uptdate to RFC 2620 - http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-02.txt
I have not implemented the server side mibs or reviewed the updates to them. The same or similar comments might apply.[David Nelson]
> I realize that these MIBs are being updated, > so perhaps we can add a discontinuity timer in a future revision. This is already an open issue from Area Director review of the revised MIB drafts, so will be included in the next draft version. > if so, I would suggest adding it per radius entry so that > each server can have its own value. That seems like a reasonable suggestion. > One other point to note. We have found that radius servers respond faster > than 100th of a second. I'd suggest an update to the MIB where the > response time is stored in micro-seconds. In addition, having the minimum, > maximum and average are also helpful. We are adding such values to our > enterprise MIB, but would opt for standard attributes if they existed. The revised MIBs have already been through WG last call and are now in IESG review. Does the WG wish to recall the documents from the publication requested state to consider adding this kind of new feature?
Proposed Resolution: Discuss
Issue 184: Review Submitter name: Hannes Tschofenig Submitter email address: Hannes.Tschofenig@gmx.net Date first submitted: March 28, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00405.html Document: VLAN-02 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue:I reviewed the draft and I came across a number of questions. I am referring only to the User-Priority-Table attribute.
The document defines a QoS provisioning and authorization solution based on traffic classes. These classes are defined in IEEE 802.1D.
The document does not describe the semantic when the User-Priority-Table attribute is included in the Access-Request. Section 1.3 talks about the provisioning semantic when included in the Access-Accept. I think it is necessary to describe the semantical difference between these two approaches.
How is the data traffic mapped to the QoS class? Which attribute carries this flow identifier? I think it is necessary to provide a description.
Why is the length of the value carried in the User-Priority-Table attribute 10 bytes long? (We are talking about 8 QoS classes, as I read from Annex G.) Why is the data type a string?
You seem to assume that the RADIUS server knows something about the link specific properties. I got the feedback that this is not appreciated for QoS. Here are two examples:
1) What happens if the RADIUS server receives the User-Priority-Table attribute in the Access-Request but it has only Y.1541 QoS classes stored in the user's profile? Do you assume that the RADIUS server is able to provide a mapping? Should the RADIUS server fail when it either does not understand the QoS classes or if it is unable to map them? Should the RADIUS client know what the RADIUS server understands?
2) Is the an applicability problem with provisioning in a roaming environment when the RADIUS server of my home network sends the User-Priority-Table attribute to the visited network which might be a IEEE 802.16e network? According to your description the RADIUS client would fail according to the description in Section 1.3. Would it be necessary for the RADIUS client to indicate that it is attached to a IEEE 802.1D network with support for the QoS classes in order to allow the Access-Accept message to be meaningful?
How long is the authoriziation decision valid when the User-Priority-Table attribute in sent in the Access-Request?
Do you see a need to reflect the QoS decision in the interworking with accounting or RADIUS prepaid (e.g., cost of the reservation)?
PS: It might be good to find a few QoS experts for review of this document. I could try to find someone, if you want.
[Bernard Aboba]
The document does not describe the semantic when the User-Priority-Table attribute is included in the Access-Request.
I was also a bit puzzled by this. Presumably the switch sends the default configuration, but I am not sure.
Section 1.3 talks about the provisioning semantic when included in the Access-Accept. I think it is necessary to describe the semantical difference between these two approaches.
The document says that the attribute when included in the Access-Request is a "hint". So I don't think that there is any provisioning going on in the Access-Request.
[Hannes]
Do you think it would be useful to provide more description of what the semantic of the User-Priority-Table attribute in the Access-Request or the Access-Accept means? I know you as someone that wants to describe the behavior in great detail.
[Bernard Aboba]
Since there is some confusion on that point, I think the answer is probably "yes".
I also think there may be more text required to specify exactly what 802.1D management elements this corresponds to.
How is the data traffic mapped to the QoS class? Which attribute carries this flow identifier? I think it is necessary to provide a description.
My understanding is that we are only talking about remapping of priority bits that are already set on inbound, and that this is described in IEEE 802.1D.
[Hannes]
What type of remapping of priority bits do you have in mind?Note that the reference to Annex G in the draft is a bit misleading since this section of the IEEE 802.1D spec just gives the rational behind the selection of the traffic classes based on the number of queues being available.
[Bernard Aboba]
I think that the correct reference may be Section 7.5.1 ("Regerating User Priority"). Annex G just provides some general background information. Table 7.1 specifies the default values of the User Priority Regeneration Table (no change). Clause 14.6.2 talks about modification of the default values by management. My assumption is that the User-Priority-Table attribute sent in an Access-Request would be the default in Table 7.1, absent changes via management.
Why is the length of the value carried in the User-Priority-Table attribute 10 bytes long?
It isn't. RADIUS includes the type and length fields in the total length, so it's 8 bytes long.
[Hannes] Why is it 8 bytes long?
[Bernard Aboba]
Clause 14.6.2.3.3 specifies the regeneration table as 8 values, each an integer in the range of 0-7.
[Hannes]
Section 14.6.2 also mentiones that the User Priority Regeneration Table is for a specific port. Hence, I guess you have to send one User Priority Regeneration Table for each port and the User-Priority-Table attribute then has to appear more than once (and has to refer to the respective port) in the Access-Accept.
You seem to assume that the RADIUS server knows something about the link specific properties.
The document specifies attributes for use with IEEE 802 networks. Information on the specific link type is provided in the NAS-Port-Type attribute.
[Hannes]
That's something you might want to mention in the document. I think you just want to delete the usage of the User-Priority-Table attribute in the Access-Request.
[Bernard Aboba]
Personally, I'm not clear what a RADIUS server would do with it; unless it's been modified by management it is a known quantity (e.g. the default).
1) What happens if the RADIUS server receives the User-Priority-Table attribute in the Access-Request but it has only Y.1541 QoS classes stored in the user's profile?
Since this would be a hint, I presume the server is free to ignore it.
Do you assume that the RADIUS server is able to provide a mapping?
Since it's a hint, I wouldn't think so. The RADIUS server isn't compelled to include the User-Priority-Table attribute in the Access-Accept.
Should the RADIUS server fail when it either does not understand the QoS classes or if it is unable to map them?
It is possible that implementations may not react well to the hint, but if they do understand the hint, they shouldn't fail because they don't return a User-Priority-Table in the Access-Accept.
Should the RADIUS client know what the RADIUS server understands?
I think that is only important if RADIUS servers won't react well to the hint. If servers don't send the attribute, the client probably won't care.
2) Is the an applicability problem with provisioning in a roaming environment when the RADIUS server of my home network sends the User-Priority-Table attribute to the visited network which might be a IEEE 802.16e network?
Presumably the attribute will only be sent if the NAS-Port-Type attribute indicates that it would be useful. 802.16k implements bridging, but 802.16e does not, so I don't think it would make sense to send this attribute to a RADIUS client running 802.16e. However, it appears there is no NAS-Port-Type for 802.16e, 802.16k, 802.20, etc. There probably should be.
Would it be necessary for the RADIUS client to indicate that it is attached to a IEEE 802.1D network with support for the QoS classes in order to allow the Access-Accept message to be meaningful?
The NAS-Port-Type attribute should provide this information.
How long is the authorization decision valid when the User-Priority-Table attribute in sent in the Access-Request?
Presumably until the expiration of Session-Timeout.
Do you see a need to reflect the QoS decision in the interworking with accounting or RADIUS prepaid (e.g., cost of the reservation)?
The attributes are not indicated to be sent in Accounting-Request packets, but perhaps they should be.
[Hannes]
It seems that you need to add a little bit more text to the draft to explain based on your response.[Bernard Aboba]
I think so. This would include:a. References to specific sections of 802.1D, explaining how this attribute relates to existing management objects.
b. Discussion of the semantics of inclusion in Access-Request (if this is in fact required)
[Hannes]
Let me explain what I would do with the description of this specific attribute:
The User-Priority-Table attribute is only used in the Access-Accept (and not in the Access-Request). You need to specify which traffic is assigned to a specific QoS class. Therefore, you need to add the NAS-Traffic-Rule. You need to add a normative reference to draft-ietf-radext-filter-rules-00.txt.
[Bernard Aboba]
As far as I can tell, the regeneration table doesn't assign traffic to a specific QoS class, it just remaps it.
This isn't based on filters, but just on the incoming markings. Obviously this is not a very sophisticated usage model.
[Hannes]
I went throught the spec in more detail and I came to the following (probably tentative) conclusion.
Section 6.3.9 (Frame Priority) gave some additional information: "The ability to signal user priority in IEEE 802 LANs allows user priority to be carried with end-to-end significance across a Bridged Local Area Network. This, coupled with a consistent approach to the mapping of user priority to traffic classes and of user priority to access_priority, allows consistent use of priority information, according to the capabilities of the Bridges and MACs in the transmission path.
"As such, the User Priority Regeneration Table has an impact to the QoS classes since they are essentially mapped to the traffic classes.
However, a subsequent paragraph in the same section says: "Under normal circumstances, user priority is not modified in transit through the relay function of a Bridge; however, network management can control how user priority is propagated. Table 7-1 provides the ability to map incoming user priority values on a per-Port basis. By default, the regenerated user priority is identical to the incoming user priority.
"From my reading of the specification I wasn't quite sure what the big value of the User Priority Regeneration Table actually is, given the fact that you ideally do not want to modify the user priority values anyway.
Maybe someone else knows the use cases better. I couldn't find it in the specification.
[Hannes]
Furthermore, you need to add the User-Priority-Table attribute to Accounting-Request messages.
[Bernard Aboba]
Probably.
[Hannes]
My previous understanding was wrong and hence I think that including the User-Priority-Table attribute to Accounting-Request messages does not make sense.
Without a description which traffic experiences the QoS treatment the entire stuff does not make sense.
[Bernard Aboba]
I think that regeneration is a separate issue from QoS treatment. I agree that it would not make much sense to do regeneration if you didn't have a QoS goal in mind, though.
[Hannes]
There is an indirect relationship. Mapping a high user priority value of an incoming frame to a low user priority value obviously impacts the QoS treatement.From a semantic point of view this is very similar to a DiffServ traffic marking.
[Bernard Aboba]
Regeneration is a kind of remapping (though not a sophisticated one).
[Hannes]
Here the rules for traffic marking is stored at the AAA server. This raises the question why you cannot just have a generic description with a set of QoS parameters. For IEEE 802.16e you would have to go through the same description just with different QoS parameters. The same for DiffServ, IntServ CL/GS, Y.1541, etc.
[Bernard Aboba]
Clearly that would be useful, but I think it is outside the scope of what the regeneration table is attempting to achieve.
Proposed Resolution: Discuss
Issue 185: NITs Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: March 26, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00403.html Document: Delegation-00 Comment type: 'E'ditorial Priority: '2' May Fix Section: 2,5 Rationale/Explanation of issue:
The draft looks ok to me. A couple editorial nits:
Section 5:
"IP SEC" -> "IPsec"
Section 2:
The idnit checker at tools.ietf.org complains:
Miscellaneous warnings:
- The document seems to use RFC 2119 keywords,
but does not seem to contain the recommended
RFC 2119 boilerplate
because the text of section 2 is not exactly like
like the boilerplate in 2119 (missing quote marks).Proposed Resolution: Accept
Issue 186: 802.1X Dependency Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 12, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00454.html Document: VLAN-02 Comment type: 'E'ditorial Priority: S Section: Abstract, 1, 1.1, 6 Rationale/Explanation of issue:The VLAN and priority attributes are usable for provisioning of access to IEEE 802 local area networks. There is no explicit IEEE 802.1X dependency in the document. For example, the attributes can be used with IEEE 802 technologies that do not implement IEEE 802.1X, such as IEEE 802.16k.
Therefore I do not believe that IEEE 802.1X should be listed as a normative reference. Also, the goal should be larger than just supporting 802.1X deployments, it should be to support access to IEEE 802 local area networks. The proposed changes are as follows:
In Section 1.1, delete the definition of authenticator, since the word is no longer used in the document.
Change the first paragraph of Section 6 from: " This specification describes the use of RADIUS for purposes of authentication, authorization and accounting in networks supporting [IEEE 802.1X]. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]." To: " This specification describes the use of RADIUS for purposes of authentication, authorization and accounting in IEEE 802 local area networks. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]."Move the reference to 802.1X from normative to informative. Delete references to 802.3, 802.11 and 802.11i.
Proposed Resolution: Accept
Issue 187: NITs Submitter name: Paul Congdon Submitter email address: paul_congdon@hp.com Date first submitted: April 12, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00428.html Document: VLAN-02 Comment type: 'E'ditorial Priority: S Section: 1.1, References Rationale/Explanation of issue:
I've read the latest version of the draft and believe it is in very good shape. I have a couple of editorial comments, but they are not binding and should not hold up any further progress. 1. Reference to Token Ring standard. I believe we discussed this in previous threads, but there is no reference to the Token Ring standard as there is to 802.3 and 802.11 in the opening sentence of the Introduction. We could either eliminate Token Ring from the list in this sentence or provide a reference. I'm not aware of any use of VLANs on Token Ring, so I would recommend removing it from the sentence. If, however, we decide to provide a reference instead, the reference is, "[IEEE 802.5] 8802-5-1998 (IEEE Std 802.5-1998) Token Ring Access Method and Physical Layer Specifications" 2. Most of the terms defined in the Terminology section are not used anymore in this document. This was checked by doing a search. Certainly "backend authentication server" and "Supplicant" can be removed. "Authenticator" is really only used in the 1st sentence of the abstract and could easily be removed as well and (if necessary) tweak the abstract.
[Bernard Aboba] Here is the proposed resolution:
Remove references to Token Ring as well as to 802.3 and 802.11 (see Issue 186).
Remove all terms in the terminology section other than "NAS".
Proposed Resolution: Accept
Issue 188: Delegated Prefix NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 15, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00460.html Document: draft-ietf-radext-delegated-prefix-00.txt Comment type: 'E'ditorial Priority: S Section: Various Rationale/Explanation of issue:
Abstract " The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is to be delegated to the user." Might add a bit to the abstract, such as a reference to the RADIUS protocol. Suggestion: " This document proposes an additional RADIUS (Remote Authentication Dial In User Service) attribute for an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter." Section 1 " The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint." This section does not state whether this attribute can be included in CoA-Request, Disconnect-Request, CoA-ACK, CoA-NAK, Disconnect-ACK Disconnect-NAK packets and Accounting-Request packets. Section 3 The attribute table does not clarify whether the attribute can be included in CoA-Request, Disconnect-Request, CoA-ACK, CoA-NAK, Disconnect-ACK or Disconnect-NAK packets. Section 5 "Use of IP SEC [7]" -> "Use of IPsec [7]" Section 6 I don't think references [4] and [6] are normative. I'd add an Informative Reference section and move these to that section. This way you won't have a document at PS making normative references to Informational RFCs. I think reference [7] has been replaced by [RFC4301]. Diameter compatibility The document lacks a "Diameter Considerations" section. Here is a suggestion (insert prior to IANA Considerations): 4. Diameter Considerations Diameter needs to define an identical attribute with the same Type value. The attribute should be available as part of the NASREQ application [RFC4005], as well as the Diameter EAP application [RFC4072]. Add references to [RFC4005] and [RFC4072]: [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
Proposed Resolution: Accept
Issue 189: Attribute Semantics Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: April 18, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00468.html Document: VLAN-03 Comment type: Technical Priority: 1 Section: 1.3 Rationale/Explanation of issue:
An explanation of how the attributes in this document would be applied to multi-user authentication environments, by means of "virtual ports" is required. The base IEEE 802 documents assume per physical port granularity. In the absence of explanation, conflicting results may occur. Requested change: Add the following text: The semantics of the RADIUS attributes described in this document apply to a single instance of a NAS port, or more specifically an IEEE 802.1Q bridge port. The underlying IEEE 802 standards, as listed in the references section, do not recognize finer management granularity than "per port". In some cases, such as with IEEE 802.11 wireless LANs, the concept of a "virtual port" is used in place of the physical port. Such virtual ports are typically based on security associations and scoped by station, or MAC address. If a NAS implementation, conforming to this document, supports "virtual ports", it may be possible to provision those "virtual ports" with unique values of the attributes described in this document allowing multiple users sharing the same physical port to each have a unique set of authorization parameters. The authorization parameters are applied on a per user basis and it is expected that there is a single user per port, however in some cases that port may be a "virtual port".
[Bernard Aboba] The proposed resolution is as follows:
"The attributes described in this document apply to a single instance of a NAS port, or more specifically an IEEE 802.1Q bridge port. [IEEE-802.1Q] [IEEE-802.1D] and [IEEE-802.1X] do not recognize finer management granularity than "per port". In some cases, such as with IEEE 802.11 wireless LANs, the concept of a "virtual port" is used in place of the physical port. Such virtual ports are typically based on security associations and scoped by station, or MAC address. The attributes defined in this document are applied on per user basis and it is expected that there is a single user per port; however in some cases that port may be a "virtual port". If a NAS implementation conforming to this document supports "virtual ports", it may be possible to provision those "virtual ports" with unique values of the attributes described in this document, allowing multiple users sharing the same physical port to each have a unique set of authorization parameters."
Proposed Resolution: Accept
Issue 190: Relationship of Tunnel and Egress-VLAN attributes Submitter name: Mauricio Sanchez Submitter email address: mauricio.sanchez@hp.com Date first submitted: April 27, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00483.html Document: VLAN-03 Comment type: Technical Priority: S Section: 2.1, 2.3 Rationale/Explanation of issue:
While the introduction acknowledges tunnel attributes from rfc2868 and rfc3580, there is no guidance on their use with the egress-vlanid and egress-vlan-name attributes. I suggest formalizing the fact that they can be used concurrently and providing guidance on their interaction/relationship.
Requested change:
1) To section 2.1 add the following paragraph between the second and third paragraphs of the description section for egress-vlanid:
"Tunnel attributes, as described in [RFC2868] and [RFC3580], and Egress-VLANID both can be used to configure the egress VLAN for untagged packets. These attributes can be used concurrently and MAY appear in the same RADIUS message. When they do appear concurrently, the list of allowed VLANs consists of the concatenation of all Egress-VLANID attributes and the Tunnel-Private-Group-ID(81) attribute.
Egress-VLANID does not alter the ingress VLAN untagged traffic on a port, also known as the PVID. The tunnel attributes from [RFC2868] and [RFC3580] should be relied upon instead to set the PVID."
2) To section 2.3 add the following paragraph between the first and second paragraphs of the description section for egress-vlan-name:
"Tunnel attributes, as described in [RFC2868] and [RFC3580], and Egress-VLAN-Name both can be used to configure the egress VLAN for untagged packets. These attributes can be used concurrently and MAY appear in the same RADIUS message. When they do appear concurrently, the list of allowed VLANs consists of the concatenation of all Egress-VLAN-Name attributes and the Tunnel-Private-Group-ID(81) attribute.
Egress-VLAN-Name does not alter the ingress VLAN for untagged traffic on a port, also known as the PVID. The tunnel attributes from [RFC2868] and [RFC3580] should be relied upon instead to set the PVID."
[Bernard Aboba] The proposed resolution is as follows:
Insert the following in Section 2.1, second
paragraph:
"As defined in [RFC3580], the VLAN assigned via tunnel
attributes applies both to the ingress VLANID for untagged
packets (known as the PVID) and the egress VLANID for
untagged packets. In contrast, the Egress-VLANID attribute configures only the
egress VLANID for either tagged or untagged packets. The
Egress-VLANID attribute MAY be included in the same RADIUS
packet as [RFC3580] tunnel attributes; however, the
Egress-VLANID attribute is not necessary if it is being used
to configure the same untagged VLANID included in tunnel attributes.
To configure an untagged VLAN for both ingress and egress,
the tunnel attrubutes of [RFC3580] MUST be used."
Proposed Resolution: Accept
Issue 191: Use of both "packet" and "frame" Submitter name: Mauricio Sanchez Submitter email address: mauricio.sanchez@hp.com Date first submitted: April 27, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00481.html Document: VLAN-03 Comment type: Editorial Priority: S Section: 2.1, 2.3 Rationale/Explanation of issue:
Sections 2.1 and 2.3 each begin refering to Ethernet frames as 'packets'. Subsequently, description changes to calling them 'frames'. Requested change: Change "packet" to "frame" wherever referencing Ethernet frames
Proposed Resolution: Accept
Issue 192: Comments Submitter name: Jouni Korhonen Submitter email address: jouni.korhonen@teliasonera.com Date first submitted: April 26, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00480.html Document: Filter-00 Comment type: Technical Priority: S Section: Various Rationale/Explanation of issue:
I had a quick look at this draft. A few initial comments:
o Introduction talks about 'home realm' and in the same
sentence also about 'local operator'. Maybe changing
home realm to home operator would be better?
o Introduction also discusses VLANs. I think that text
there does not really belong to this draft anymore.
o terminology section lists Authenticator, Authentication
Server and Supplicant even if those are not used in the
text outside the terminology section. Imho a reference
to 802.1X should be enough
o hot-lining is also only mentioned in the terminology
section. Should there be some more text in the draft
itself about hot-lining e.g. in form of motivation for
this draft? Actually I would like to see a general
short motivation section somewhere under section 1
o what is the purpose of the rule-delim in the
NAS-Traffic-Rule ABNF? As far as I interpreted the
ABNF there can be only one rule per attribute anyway?
I could be wrong ;)
o in the NAS-Traffic-Rule why there could not be
- ip-proto = ["!"] d8
- tcp-ports = ["!"] tcp-port *("," tcp-port)
That would ease blocking of specific ports and
protocols. E.g. in case of trying to block some
virus/worm generated traffic, while allowing
everything else..
o tcp-port name might be a bit misleading as ports are
also used for other protocols. Maybe just using
ports or similar?
o What's the intended use for the L2 filtering? I'd
like to see some real use case described here
o section 3.1 Acct-NAS-Traffic-Rule attribute definition
- the length should probably be >= 11
- The 'String' should probably be 'Counter'
- the description for 'Text' is missing
o Security considerations mention VLAN-related attributes
several times although those are now in a separate
document.
Some nits:
o section 2
s/one new RADIUS authentication attributes/...attribute
[Mauricio Sanchez]
> o Introduction talks about 'home realm' and in the same
> sentence also about 'local operator'. Maybe changing
> home realm to home operator would be better?
I'm open to this suggestion. It does seem more succinct when the home
operator term is used.
>
> o Introduction also discusses VLANs. I think that text
> there does not really belong to this draft anymore.
Sounds appropriate. We'll back off the usage of VLANs as a driving use case
and focus on what specifically drives the need for these attributes.
>
> o terminology section lists Authenticator, Authentication
> Server and Supplicant even if those are not used in the
> text outside the terminology section. Imho a reference
> to 802.1X should be enough
>
I remember adding this terms into the terminology section after group
discussion. I remember people wanting additional detail around this and
having only a reference to 802.1X did not seem like enough. I'll push back
and say that unless you really think having these terms are distraction,
then we should just leave them in.
> o hot-lining is also only mentioned in the terminology
> section. Should there be some more text in the draft
> itself about hot-lining e.g. in form of motivation for
> this draft? Actually I would like to see a general
> short motivation section somewhere under section 1
Hmmm, previous version talked about hotlining and people started to feel
that it was getting to be a distraction in the introduction. Elaboration on
hotlining was cut down to what it is now. Why do you feel we need to add
more motivation based on hot-lining?
> o what is the purpose of the rule-delim in the
> NAS-Traffic-Rule ABNF? As far as I interpreted the
> ABNF there can be only one rule per attribute anyway?
> I could be wrong ;)
The first version of the syntax had no rule delimiter and people commented
that having a delimiter would eliminate any possibility for ambiguity of
rule end.
>
> o in the NAS-Traffic-Rule why there could not be
> - ip-proto = ["!"] d8
> - tcp-ports = ["!"] tcp-port *("," tcp-port)
>
> That would ease blocking of specific ports and
> protocols. E.g. in case of trying to block some
> virus/worm generated traffic, while allowing
> everything else..
There no strong reason anymore why this couldn't be done. It used to be an
argument of remaining true to the L3-L4 capabilities specified by Diameter's
IPFilterRule to facilitate translation. However, given that we're going
down the path of creating a Diameter AVP for NAS-Traffic-Rule, we probably
no longer need to constrain ourselves to the limitations of the IPFilterRule
syntax.
>
> o tcp-port name might be a bit misleading as ports are
> also used for other protocols. Maybe just using
> ports or similar?
How about 'layer4-port' or 'l4-port'?
>
> o What's the intended use for the L2 filtering? I'd
> like to see some real use case described here
BPDU filtering is one real use case.
>
> o section 3.1 Acct-NAS-Traffic-Rule attribute definition
> - the length should probably be >= 11
> - The 'String' should probably be 'Counter'
> - the description for 'Text' is missing
Ok.
>
> o Security considerations mention VLAN-related attributes
> several times although those are now in a separate
> document.
Ok. Will update.
>
> Some nits:
>
> o section 2
> s/one new RADIUS authentication attributes/...attribute
Ok.
Proposed Resolution: Discuss
Issue 193: InetPortNumber Submitter name: Bert Wijnen Submitter email address: bwijnen@lucent.com Date first submitted: May 11, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00504.html Document: Client-MIB-05 Comment type: Editorial Priority: 1 Section: 4 Rationale/Explanation of issue:
I think this document is fine now.
However, when I read:
radiusDynAuthServerClientPortNumber OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The UDP destination port that the RADIUS Dynamic
Authorization Client is using to send requests to this
server. The value zero is invalid."
::= { radiusDynAuthServerEntry 4 }
I think I would make that
SYNTAX InetPortNumber (1..65535)
So that it is also determinable by machine that zero is invalid. I know that I only pointed out that according to RFC 4001 you must state what zero means. B ut if the value is not allowed, as I now understand it, then I think using the SYNTAX I suggest is better.
Proposed Resolution: Accept
Issue 194: InetPortNumber Submitter name: Bert Wijnen Submitter email address: bwijnen@lucent.com Date first submitted: May 11, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00504.html Document: Auth-Client-MIB-03, Acct-Client-MIB-03 Comment type: Editorial Priority: 1 Section: 7 Rationale/Explanation of issue:
When I read:
radiusAuthClientServerInetPortNumber OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The UDP port the client is using to send requests
to this server."
REFERENCE "RFC 2865 section 3"
::= { radiusAuthServerExtEntry 4 }
or
radiusAccClientServerInetPortNumber OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The UDP port the client is using to send requests
to this accounting server."
REFERENCE "RFC 2866 section 3"
::= { radiusAccServerExtEntry 4 }
I think I would make that
SYNTAX InetPortNumber (1..65535)
So that it is also determinable by machine that zero is invalid. I know that I only pointed out that according to RFC 4001 you must state what zero means. B ut if the value is not allowed, as I now understand it, then I think using the SYNTAX I suggest is better.
Proposed Resolution: Accept
Issue 195: NITs Submitter names: Alexey Melnikov Submitter email address: alekey.melnikov@isode.com Date first submitted: May 15, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00505.html Document: DIGEST-08 Comment type: 'E'ditorial Priority: S Section: 2.1.2, 2.2.1, 8.1, 9 Rationale/Explanation of issue: All major issues I've raised before are addressed. The document reads much better after removal of client side nonce generation. Some minor additional comments below: 2.1.2. Constructing an Access-Request [...] Due to syntactic requirements, HTTP-style protocols have to escape quote characters in contents of HTTP Digest directives. When "with backslash all quote and backslash characters in contents of ..." translating directives into RADIUS attributes, the RADIUS client only removes the surrounding quotes where present. See Section 3 for an example. 2.2.1. General Attribute Checks [...] The RADIUS server removes '\' characters that escape quote characters "... that escape quote and '\' characters ..." from the text values it has received in the Digest-* attributes. 8.1. Denial of Service [...] 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. The RADIUS client no longer generates nonces, so it can't verify signature, unless it knows how RADIUS server generates nonces. 9. Acknowledgments We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or typo: "for" providing comments and experimental implementation.
Proposed Resolution: Accept
Issue 196: User-Name Attribute Submitter names: Cristina Ruiz Submitter email address: cristina.ruiz@ericsson.com Date first submitted: June 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00527.html Document: DIGEST-09 Comment type: 'T'echnical Priority: S Section: 5, 6 Rationale/Explanation of issue:
The User-Name attribute is mandatory in the RADIUS Access Request as indicated in the table of attributes (Section 5). But in the initial HTTP GET method, the user-name is not received, and in the example (Section 6) nothing is sent in the User-name attribute in the B->C comunication. What does the RADIUS client include in the User-Name attribute in this case? And what shall the RADIUS Server do when this dummy user-name is received? I think the "client nonce generation mode" removed from draft 07 was usefull to avoid inventing a user name in this HTTP case (where the nonce generation does not depend on the user and this is not received in the initial request). Why was it removed?
Proposed Resolution: Discuss
Issue 197: IESG DISCUSS Comments Submitter names: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: June 11, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00553.html Document: VLAN-05 Comment type: 'T'echnical Priority: S Section: 1, 1.1, 4, 6 Rationale/Explanation of issue:Jari Arkko and Russ Housley have reviewed the VLAN/Priority document. In order to address their comments, the following changes are proposed:
Change Section 1 to the following:
"1. Introduction
This document describes Virtual LAN (VLAN) and re-prioritization
attributes that may prove useful for provisioning of access to IEEE
802 local area networks [IEEE-802] with the Remote Authentication
Dialin User Service (RADIUS) or Diameter.
While [RFC3580] enables support for VLAN assignment based on the
tunnel attributes defined in [RFC2868], it does not provide support
for a more complete set of VLAN functionality as defined by
[IEEE-802.1Q]. The attributes defined in this document provide
support within RADIUS and Diameter analogous to the management
variables supported in [IEEE-802.1Q] and MIB objects defined in
[RFC4363]. In addition, this document enables support for a wider
range of [IEEE-802.1X] configurations."
In Section 1.1, add the following definitions:
"RADIUS server
A RADIUS authentication server is an entity that provides an
authentication service to a NAS.
RADIUS proxy
A RADIUS proxy acts as an authentication server to the NAS, and a
RADIUS client to the RADIUS server."
Change Section 4 to the following:
"4. Diameter Considerations
When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the
attributes are as follows:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
Egress-VLANID OctetString| M | P | | V | Y |
Ingress-Filters Enumerated | M | P | | V | Y |
Egress-VLAN-Name UTF8String | M | P | | V | Y |
User-Priority-Table OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
The attributes in this specification have no special translation
requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
they are copied as is, except for changes relating to headers,
alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
4005] Section 9.
What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is
said about Access-Challenge applies in Diameter to AA-Answer [RFC
4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.
What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure.
What is said about COA-Request applies in Diameter to Re-Auth-Request
[RFC 4005].
What is said about Accounting-Request applies to Diameter Accounting-
Request [RFC 4005] as well."
Change Section 6 to the following:
"6. Security Considerations
This specification describes the use of RADIUS and Diameter for
purposes of authentication, authorization and accounting in IEEE 802
local area networks. RADIUS threats and security issues for this
application are described in [RFC3579] and [RFC3580]; security issues
encountered in roaming are described in [RFC2607]. For Diameter, the
security issues relating to this application are described in
[RFC4005] and [RFC4072].
This document specifies new attributes that can be included in
existing RADIUS packets, which are protected as described in
[RFC3579] and [RFC3576]. In Diameter, the attributes are protected
as specified in [RFC3588]. See those documents for a more detailed
description.
The security mechanisms supported in RADIUS and Diameter are focused
on preventing an attacker from spoofing packets or modifying packets
in transit. They do not prevent an authorized RADIUS/Diameter server
or proxy from inserting attributes with malicious intent.
VLAN attributes sent by a RADIUS/Diameter server or proxy may enable
access to unauthorized VLANs. These vulnerabilities can be limited
by performing authorization checks at the NAS. For example, a NAS
can be configured to accept only certain VLANIDs from a given
RADIUS/Diameter server/proxy.
Similarly, an attacker gaining control of a RADIUS/Diameter server or
proxy can modify the user priority table, causing either degradation
of quality of service (by downgrading user priority of frames
arriving at a port), or denial of service (by raising the level of
priority of traffic at multiple ports of a device, oversubscribing
the switch or link capabilities)."
Proposed Resolution: Discuss
Issue 198: Attribute Concatenation/Splitting Submitter names: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: June 30, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00640.html Document: Filter-00 Comment type: 'T'echnical Priority: S Section: 2 and 4 Rationale/Explanation of issue:
Section 2 currently says that "Where more than one NAS-Filter-Rule attribute is included in a RADIUS packet, the attributes MUST be consecutive and it is assumed that the attributes are to be concatenated to form a single filter list." I guess this means that a single long rule can be split into multiple NAS-Filter-Rule attributes? And a single NAS-Filter-Rule attribute could contain pieces of multiple rules? If so, I'd recommend separating the individual rules somehow. In the current version of NAS-Traffic-Rule each individual rule ends with LF, making it easy to determine where one rule ends and another one begins. I'd suggest adopting this same convention for RADIUS NAS-Filter-Rule. This concatenation/splitting has also implications for Diameter translation (Section 4): AVPs coming from Diameter side may have to be split to several RADIUS attributes (and rule delimiters added), and attributes coming from RADIUS side have to be concatenated/split to Diameter AVPs (and rule delimiter removed).
[Pasi Eronen]
> BTW, do the same issues also apply to the NAS-Filter-Rule AVP > defined in RFC 4005? As far as I can tell, no: in RFC 4005, a single AVP always contains one complete rule (long rules are not split into multiple AVPs, and one AVP never contains multiple rules).
[Rajith R]
AFAIK, splitting & concatenation are necessitated by the 255 byte limit for RADIUS attributes. So it would be better to split at 253 byte (for the attribute payload) boundary rather than LF or some other attribute specific delimiter, I think this would have the advantage of * same & simple logic for concatenation/splitting of any suitable RADIUS attribute of length > 255 * packing efficiency in the message, though not a principal concern
[Pasi Eronen] This simple concatenation/splitting works when you need to include a single, potentially long data item (e.g. EAP-Message) in a RADIUS message. But it gets complex if you need to include multiple, potentially long data items of the same type (in this case, individual filter rules) and you need to maintain the boundaries between the individual data items somehow. In particular, if we decide to support individual filter rules longer than 253 characters, it looks like a RADIUS-to-Diameter translation agent will need code specific to NAS-Filter-Rule no matter how we choose to do the concatenation/splitting on the RADIUS side. The difference is just how complex that code needs to be (e.g., is it sufficient just to recognize "LF", or understand the full filter rule syntax).
[BA]I am wondering if the following approach to the concatenation/splitting problem with NAS-Filter-Rule might work:
a. Add a single octet Tag field:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
b. Specify that a multiple NAS-Filter-Rule attributes with the same value of the Tag field represent a single rule and are to be concatenated when translating to Diameter NAS-Filter-Rule. c. Prohibit reordering of NAS-Filter-Rule attributes. d. Suggest that ASCII values (e.g. '1'=0x31, etc.) be used in the tag field so they can be entered easily.
[Glen Zorn] This sounds very similar to what was discussed in Montreal. I think that this would work fine, and particularly well with the VSA method of extending the attribute space.
[David Nelson] Currently the document does not describe how the Tag value of zero is handled. I would suggest that the Tag value of 0 be reserved as an indicator of un-tagged attributes. If it is not already clear from the diagram and text, we should clarify that this Tag is not optional, as it is for strings in 2868. [BA] My suggestion is that a value of zero (0) be used to indicate a filter-rule that is less than 253 octets, so that concenation if not required, and multiple filter-rules can utilize the same zero (0) value. Here is the proposed text: Tag The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of zero (0) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of zero MUST NOT be concatenated, and one or more Filter-Rule attributes with a tag value of zero may be included in a single RADIUS packet, each describing a single filter rule.
[Bernard Aboba]
Question: In the interest of making it easier to enter in Filter-Rules as ASCII strings, does it make sense to make the Tag value 0x30 (The '0' character) the way to indicate that a filter rule is untagged, rather than NULL (0x00)? My understanding is that there may not be an easy way to enter in a NULL character in an ASCII string within some RADIUS server implementations, whereas entering a '0' character is easy.
Here is the current text: Tag The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of zero (0) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of zero MUST NOT be concatenated, and one or more Filter-Rule attributes with a tag value of zero may be included in a single RADIUS packet, each describing a single filter rule. With the change, it might look like this: The Tag field is one octet, and MUST always be present. It is used to identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule MUST be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of '0' (0x30) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of 0x30 MUST NOT be concatenated, and one or more Filter-Rule attributes with a tag value of 0x31 may be included in a single RADIUS packet, each describing a single filter rule.
[David Nelson]
Looks good to me, with the change to consistent use of 0x30, noted by Jouni.
Currently the document does not describe how the Tag value of zero is handled. I would suggest that the Tag value of 0 be reserved as an indicator of un-tagged attributes. If it is not already clear from the diagram and text, we should clarify that this Tag is not optional, as it is for strings in 2868.
[BA]
My suggestion is that a value of zero (0) be used to indicate a filter-rule that is less than 253 octets, so that concenation if not required, and multiple filter-rules can utilize the same zero (0) value. Here is the proposed text:
TagThe Tag field is one octet, and MUST always be present. It is used to
identify the filter rule that is represented. Where a single filter rule exceeds 253 octets in length, the rule may be encoded across multiple NAS-Filter-Rule attributes, each with the same non-zero Tag value; non-zero Tag values MUST be unique for each filter rule present in a RADIUS packet. The value of zero (0) in the Tag field indicates that the attribute contains a filter rule that does not exceed 253 octets in length; as a result attributes with a Tag value of zero MUST NOT be concatenated, and multiple Filter-Rule attributes with a tag value of zero may be included in a single RADIUS packet. --
[Bernard Aboba]
So as to lessen restrictions on the number of potential rules, here is another attempt at text relating to the Tag field. Is this better?
" Tag
The Tag field is used to identify the filter rule that is
represented; the length of the Tag field is one octet and it MUST
always be present.
Where a single filter rule is less than or equal to 252 octets in
length, it MUST be encoded with a Tag field value of zero (0) and
MUST NOT be split between multiple NAS-Filter-Rule attributes. On
receipt, attributes with a Tag field value of zero (0) MUST NOT be
concatenated to form a single filter rule.
Where a single filter rule exceeds 252 octets in length, the rule
MUST be encoded across multiple NAS-Filter-Rule attributes, each
with the same Tag value which MUST be in the range 0x01 - 0x3F.
NAS-Filter-Rule attributes comprising a
single filter rule MUST be sent
consecutively, without intervening attributes with another Tag field value.
The Tag field value of 0xFF is reserved and NAS-Filter-Rule attributes
containing this Tag field value should be ignored upon receipt.
Adjacent filter rules exceeding 252 octets in length MUST be
encoded with different non-zero Tag field values; however, the Tag
field value used for a given filter rule need not be unique within
the entire RADIUS packet.
[Emile Bergen] This is too complex.
[Bernard Aboba] Here is a revised Section 2:
"2. NAS-Filter-Rule Attribute
Description
This attribute indicates filter rules to be applied for this user.
Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
Accept, CoA-Request, or Accounting-Request packets.
The NAS-Filter-Rule attribute is not intended to be used
concurrently with any other filter rule attribute, including
Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST
NOT appear in the same RADIUS packet. If a Filter-Id or NAS-
Traffic-Rule attribute is present, then implementations of this
specification MUST silently discard NAS-Filter-Rule attributes, if
present.
Where multiple NAS-Filter-Rule attributes are included in a RADIUS
packet, the String field of the attributes are to be concatenated
to form a set of filter rules. As noted in [RFC2865] Section 2.3,
"the forwarding server MUST NOT change the order of any attributes
of the same type", so that RADIUS proxies will not reorder NAS-
Filter-Rule attributes.
A summary of the NAS-Filter-Rule Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
>=3
String
The String field is one or more octets. It contains filter rules
in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
individual filter rules separated by a NUL (0x00). A NAS-Filter-
Rule attribute may contain a partial rule, one rule, or more than
one rule. Filter rules may be continued across attribute
boundaries, so implementations cannot assume that individual
filter rules begin or end on attribute boundaries.
The set of NAS-Filter-Rule attributes SHOULD be created by
concatenating the individual filter rules, separated by a NUL
(0x00) octet. The resulting data should be split on 253 byte
boundaries to obtain a set of NAS-Filter-Rule attributes. On
reception, the individual filter rules SHOULD be determined by
concatenating the contents of all NAS-Filter-Rule attributes, and
then splitting individual filter rules with the the NUL octet
(0x00) as a delimeter."
Proposed Resolution: Discuss
Issue 199: Attribute Length Submitter names: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: June 27, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00601.html Document: Filter-00 Comment type: 'T'echnical Priority: S Section: 2 Rationale/Explanation of issue:
Quick note: it appears that the minimum length of this attribute is actually 35 (Type+Length+"deny in 1 from 1.2.3.4 to 2.3.4.5"), rather than 3 as stated in section 2.
[BA]
This issue pointed out that a single rule cannot be less than 32 octets in length. However, with the proposed Tag format, it is possible for a rule fragment to be included in the value field of a NAS-Filter-Rule attribute. Such a fragment could be as small as 1 octet. Therefore the minimum length of the modified NAS-Filter-Rule attribute appears to be 4 octets.
Proposed Resolution: Accept