Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option
draft-ietf-dhc-agentopt-radius-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Bert Wijnen |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2004-09-27
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-09-24
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-09-24
|
08 | Amy Vezza | IESG has approved the document |
2004-09-24
|
08 | Amy Vezza | Closed "Approve" ballot |
2004-09-24
|
08 | Margaret Cullen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman |
2004-09-24
|
08 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-09-22
|
08 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2004-09-17
|
08 | (System) | Removed from agenda for telechat - 2004-09-16 |
2004-09-16
|
08 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
2004-09-15
|
08 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-09-15
|
08 | Margaret Cullen | [Note]: 'On agenda to clear Ted''s and Bert''s discusses or to clarify what issues persist.' added by Margaret Wasserman |
2004-09-13
|
08 | Ted Hardie | [Ballot discuss] The -08 version of the draft still contains the following text: If the relay agent forwards RADIUS … [Ballot discuss] The -08 version of the draft still contains the following text: If the relay agent forwards RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. I asked previously why this was not a MUST, and I'm afraid I still don't understand the answer. It seems like interoperability of servers and relay agents is going to be much easier if this is simply ruled out; is there a use case in which the DHCP server NOT ignoring them is useful enought to override that? If there is an example, could it be included in the text? If I've missed the point, and this matches some other behavior, please let me know; taken alone, though, this doesn't quite make sense to me. |
2004-09-09
|
08 | Margaret Cullen | Placed on agenda for telechat - 2004-09-16 by Margaret Wasserman |
2004-09-09
|
08 | Margaret Cullen | [Note]: 'On agenda to clear Thomas'' and Bert''s discusses or to clarify what issues persist.' added by Margaret Wasserman |
2004-09-08
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-09-08
|
08 | (System) | New version available: draft-ietf-dhc-agentopt-radius-08.txt |
2004-08-08
|
08 | Margaret Cullen | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Margaret Wasserman |
2004-08-08
|
08 | Margaret Cullen | Meeting held at IETF60 in San Diego. Agreement was reached to make changes to this MIB to satisfy Bert's discuss issues (based on AAA Doctor … Meeting held at IETF60 in San Diego. Agreement was reached to make changes to this MIB to satisfy Bert's discuss issues (based on AAA Doctor review). |
2004-07-29
|
08 | Bert Wijnen | [Ballot discuss] From the original 9 issues, revision 07 has addressed quite a bit. These are the remaining open issues. 1. Truncation issue. … [Ballot discuss] From the original 9 issues, revision 07 has addressed quite a bit. These are the remaining open issues. 1. Truncation issue. The truncation issue raises objections from several reviewers, and other objections related to the inability of the RADIUS server to determine that the lower MTU was in effect. As a result, it seems that the truncation issue is the fundamental problem here. Eliminating the 253 byte limitation is necessary in order for this mechanism to be robust. See detailed issues 1 and 2 from the AAA-doctor review summary (review of revision 07). There are a number of ways in which this can be handled. Paul Funk has made a suggestion about enabling long options and is probably the most general way. But the DHC WG may also have other ideas on how to fix this. If I understand the discussion correctly then the original purpose of this specification was to allow a RADIUS server to send a Framed-Pool or Framed-IPv6-Pool attribute to 802.11 APs, much as it does today in dialup networking situations. The idea was to allow existing RADIUS server functionality to be used with new media without the needs for changes to RADIUS servers, proxies, etc. Restricting RADIUS servers to 253 octets of attributes without a means of informing them of the restriction, or limiting inter-domain use of RADIUS (something which is widely deployed today) in order to use an existing RADIUS server facility takes us fairly far from the original design goals. In particular, in large networks with many RADIUS clients, it can be quite difficult to keep track of the capabilities of each client. Frequently the capabilities can vary by the characteristics of the client, the firmware load, etc. In that kind of environment, requiring the RADIUS server to keep track of whether the client implements the DHCP options draft, and therefore whether the MTU needs to be lowered can be a large administrative burden. 2. Normative language updating or contradicting RFC 2865. Section 4 of -07 states: The RADIUS server that implements this specification MUST be configured to return the User-Name and Class attributes to the NAS, and MAY return other attributes. If it is desired that the RADIUS server change its behavior based on the NAS implementation of this specification, then it is necessary for the NAS to inform the RADIUS server that the specification has been implemented (see Issue #1). The issue can be resolved if the above sentence gets deleted, since Section 5 states: The relay agent SHOULD include the User-Name and Class attributes in the RADIUS Attributes sub-option if available, and MAY include other attributes." A detailed summary has also been sent to DHC WG chair ---- original DISCUSS on 2004-04-29 -- now replaced by above Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS and COMMENT statements. Added on 2004-05-24 It is a pretty long set of comments. So I have send the raw data to the WG chair (Ralph Droms) and recorded it separately in the ID-tracker. |
2004-07-08
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-07-08
|
07 | (System) | New version available: draft-ietf-dhc-agentopt-radius-07.txt |
2004-06-29
|
08 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-05-24
|
08 | Bert Wijnen | [Ballot discuss] Original DISCUSS on 2004-04-29 Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS … [Ballot discuss] Original DISCUSS on 2004-04-29 Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS and COMMENT statements. Added on 2004-05-24 It is a pretty long set of comments. So I have send the raw data to the WG chair (Ralph Droms) and recorded it separately in the ID-tracker. |
2004-05-24
|
08 | Bert Wijnen | [Ballot discuss] Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS and COMMENT statements. It … [Ballot discuss] Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS and COMMENT statements. It is a pretty long set of comments. So I have send the raw data to the WG chair (Ralph Droms) and recorded it separately in the ID-tracker. |
2004-05-24
|
08 | Bert Wijnen | -----Original Message----- From: Wijnen, Bert (Bert) Sent: maandag 24 mei 2004 14:08 To: 'Ralph Droms' Cc: jschnizl@cisco.com; Margaret Wasserman Subject: RE: Discuss on draft-ietf-dhc-agentopt-radius-06.txt … -----Original Message----- From: Wijnen, Bert (Bert) Sent: maandag 24 mei 2004 14:08 To: 'Ralph Droms' Cc: jschnizl@cisco.com; Margaret Wasserman Subject: RE: Discuss on draft-ietf-dhc-agentopt-radius-06.txt > Bert - draft-ietf-dhc-agentopt-radius-06.txt is part of the > PROTO team pilot in which the WG chair (in this case, me) takes > on the responsibility to follow up on discuss points published > against a document that has been submitted to the IESG for > publication. > > I see that you have a discuss point against > draft-ietf-dhc-agentopt-radius-06.txt: > > Discuss: > Quite a set of comments and concerns from the AAA-doctors. > Need to merge them into one set of DISCUSS and COMMENT statements. > Sorry for not having done so earlier. > Would you please forward the comments and concerns from the AAA-doctors so > we (John Schnizlein and I) can respond and revise the doc as necessary? > Thanks... OK, here we go. Did not yet take the time to merge them. So just frowarding raw comments so you have it right now. Can you let me know if you need more info from me? - There was a review of revision 5 back in .. I checkedith the reviewer of back then and aksed if the issues raised against rev 5 were addressed. This is the response: Yes, I did check and the comments that related to updates to RFC 2865 were not addressed. The AAA-doctors picked up on most of those issues (and found a lot more things, too). I have attached below (at the very bottom of this email), the review copmments from Bernar on rev 5. - Comments on revision 6 (again from Bernard): Draft -06 states: " The NAS truncates the RADIUS attributes to fit in the RADIUS Attributes sub-option. For predictable behavior, the RADIUS server should be configured to return few than 255 octets of RADIUS attributes." In RADIUS, a single attribute (such as User-Name) can be 253 octets, and packets may be up to 4096 octets in length. Since the draft does not provide a way for the NAS to tell the RADIUS server that this specification is implemented, it would seem like a RADIUS server would always have to configured to return no more than 255 octets of RADIUS attributes in order to function correctly. That's a pretty major constaint on RADIUS server implementations. I'm not sure why this is necessary, since RFC 3396 enables encoding of long options in DHCPv4. The draft also imposes other constraints on RADIUS implementations using normative language. Given that it is not possible for the RADIUS server to know if this specification is being implemented, the effect is to update RFC 2865. This seems inappropriate to me. - Comments from various other AAA doctors below. Bert -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com] Sent: woensdag 28 april 2004 19:59 To: aaa-doctors@ops.ietf.org Subject: RE: Pls review/comment on: draft-ietf-dhc-agentopt-radius-06.txt Top of page 4: "...in RFC 2865, in octets b1...bN." In the corresponding figure, the octets are labeled as o1...oN. I concur with Bernard's comments about the attributes truncation issue. On page 4: " ...a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service." How would the RADIUS Server know? RADIUS provides for the use of "hint" attributes in Access-Request messages, which the RADIUS Server may use to determine an appropriate set of atttributes for includion in an Access-Accept message. Does this ID anticiapte the use of hints for conveying the capabiliites of the DHCP realy agent and/or server to the RADIUS Server? Otherwise, it is not clear how this "SHOULD" requirement might be met. Why does the DHCP Server want to see the RADIUS User-Name attribute? Is there an intent for the DHCP server to make AAA-like policy decisions based on user identity? It should be mentioned that in some RADIUS use cases, the User-Name attribute is only a "billing identity" or an "anonymous" identity, with the acutal authenticated user identity only available to the peers of an EAP session. I agree with Bernard's comment that any normative text that would modify the behavior described in the base RADIUS RFCs would seem to be inappropriate in this document. It seems to me that some guidance should be provided in this document, specifically addressing the static IP address assignment attribute of RADIUS, and the incompatibility of that attribute with DHCP. While static IP address assignment via RADIUS is little (not ?) used today, it probably ought to be discusssed. If the DHCP Server is using the contents of the sub-option as advisory material (i.e. "hints") as to how to provision DHCP information for the DHCP client, then the security model as stated is probably sufficient. This document specifies a transitive trust relationship. The NAS and RADIUS Server establish trust by means of a shared secret, and optionally by use of IPsec protections. The NAS (and therefore the DPCH Relay Agent) and the DHCP Server establish trust by the measns referenced in the Security Consideration section. I haven't taken any time to give serious consideration to whether this provides the opportunity for any form of attack based on a compromised NAS, that would not already be covered by the Security Considerations section of the base RADIUS RFC(s). -- Dave -----Original Message----- From: Greg Weber [mailto:gdweber@cisco.com] Sent: donderdag 29 april 2004 3:23 To: bwijnen@lucent.com Cc: aaa-doctors@ops.ietf.org Subject: Re: Pls review/comment on: draft-ietf-dhc-agentopt-radius-06.txt Some additional comments, The table in Section 4 lists RADIUS attributes which MAY be returned by the server to the NAS, but most of these are precluded from inclusion in Access-Accepts by RFC 2865 Section 5.44. E.g. Calling-Session-Id (attr.30) is not returned by the server- it is sent to the server. If the intent is that the NAS supplies these directly to the DHCP relay, that conflicts with Section 5 of the draft: "The RADIUS Attributes sub-option MUST only contain the attributes provided in the RADIUS Access/Accept message." Guidance is needed on the lifetime of the authorization data. DHCP is independent of 802.1x; there is no guarantee that any DHCP packets will immediately (or ever) follow the authentication process. How long is the NAS supposed to hang on to this authorziation data hoping to insert it into DHCP requests? Are the data inserted into all subsequent DHCP requests- until what point? Guidance may be needed on how the NAS is supposed to correlate DHCP requests with the previous RADIUS requests. Is this based on MAC address? Does that pose a spoofing threat specific to the proposed functionality which should be covered in the Security Considerations section? Greg -----Original Message----- From: Ashwin Palekar [mailto:ashwinp@windows.microsoft.com] Sent: donderdag 29 april 2004 6:02 To: list, Cc: bwijnen@lucent.com; Bernard Aboba Subject: Comments on dhc-agentopt-radius-06.txt I've looked at draft-ietf-dhc-agentopt-radius-06.txt. Here's my review: 1. "a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service. " Comment 1: How does the RADIUS server know that the DHCP server will provide the associated service? 2. "The RADIUS server that implements this specification MUST be configured to return the User-Name and Class attributes to the NAS, and MAY return other attributes." # Attribute --- --------- 1 User-Name (RFC 2865 [3]) 4 NAS-IP-Address (RFC 2865) 6 Service-Type (RFC 2865) 25 Class (RFC 2865) 26 Vendor-Specific (RFC 2865) 27 Session-Timeout (RFC 2865) 30 Called-Station-Id (RFC 2865) 31 Calling-Station-Id (RFC 2865) 32 NAS-Identifier (RFC 2865) 44 Acct-Session-Id (RFC 2866 [5]) 50 Acct-Multi-Session-Id (RFC 2866) 87 NAS-Port-Id (RFC 2869 [6]) 88 Framed-Pool (RFC 2869) 100 Framed-IPv6-Pool (RFC 3162 [8]) Comment 2: Newer EAP authentication protocols allow the RADIUS server to authenticate multiple identities. What if the RADIUS server is authenticating multiple identities user and machine? Which identity should it return? Comment 3: The para possibly imposes a major constraint on RADIUS implementations by requiring them to return User-Name attribute. Not all RADIUS servers return this attribute. Comment 4: The para requires the DHCP relay agent to send many RADIUS attributes to the DHCP server. In addition, the interoperability impact is unclear if the DHCP relay does not forward certain attributes (like Vendor-Specific). Instead, can't we achieve the same thing if the RADIUS server returns one additional RADIUS attribute (DHCP-user-class) specifically designed to be handled by DHCP relay-agents. The DHCP relay agent only forwards the single attribute DHCP-user-class to the DHCP server. The DHCP server can then assign configuration options based on this option. Regards, Ashwin -----Original Message----- From: Paul Funk [mailto:paul@funk.com] Sent: donderdag 29 april 2004 11:29 To: Wijnen, Bert (Bert); aaa-doctors@ops.ietf.org Subject: Re: Pls review/comment on: draft-ietf-dhc-agentopt-radius-06.txt Yet another approach would be to have a RADIUS attribute that encapsulated a DHCP option. Then, the RADIUS server could be configured to allow arbitrary options to be added to a DHCP request. They could be vendor-specific as well. Paul ---------------------- Bert, I read the draft quickly, but it appears that the all the RADIUS attributes are encoded into a single DHCP option. Since that is limited to 255 bytes, I'm not sure how useful or reliable this will be. RADIUS servers cannot be configured to limit the total length of their attributes to 255 bytes and remain usable for their main purpose, which is authentication and authorization. I'm not sure if it is legal in DHCP to repeat an option. If it is, RADIUS attributes could be encoded one per option. An alternate approach would be to configure the RADIUS server as to which attributes should be forwarded to the DHCP server. There might be a new or VS attribute that would be useful in some application to forward to the DHCP server, and it is always more convenient to configure such things in the RADIUS server rather than in the NAS. The NAS is best left to blindly do what it is told rather than to make decisions like which attribute to forward as a DHCP option. The basic problem is the sheer volume of information produced. In such cases, maybe the best thing is to just to provide a method of indirection, like a policy name or something. For example, to configure a packet filter, you can send the name of the filter rather than a list of rules. So maybe what's really required is a RADIUS "DHCP-Policy" attribute, jointly configured at RADIUS server and DHCP server, and the NAS simply forwards between the two. Paul ---------- Forwarded message ---------- Date: Wed, 7 Apr 2004 09:47:51 -0700 (PDT) From: Bernard Aboba To: Margaret Wasserman Subject: Re: Fwd: draft-ietf-dhc-agentopt-radius-05.txt Here's my review: Review of: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-05.txt There should be an informative reference to the IEEE 802.1X standard: [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. Section 1 In Figure 1, change "Authentication confirm/deny" to "Access-Accept/Reject" Change "RADIUS Service" to "RADIUS Server" " The RADIUS Attributes sub-option for the DHCP Relay Agent option provides a way in which network elements can pass information obtained through layer 2 authentication to a DHCP server [2]." Actually, the information is obtained via a RADIUS exchange, and may not relate to layer 2 authentication (e.g. a VPN authentication would still work). Suggest rephrasing to: " The RADIUS Attributes sub-option for the DHCP Relay Agent option provides a way in which a NAS can pass selected attributes obtained from a RADIUS server to a DHCP server [2]." "The NAS then supplies these credentials to a RADIUS server, which either confirms or denies the identity of the user of the device requesting network access. " Actually, the RADIUS server accepts or rejects access. This could be due to failed authentication or it could be for other reasons (insufficient authorization). Suggest rephrasing to: "The NAS then supplies these credentials to the RADIUS server, which eventually sends either an Access-Accept or an Access-Reject in response to an Access-Request." Section 2.2 It would probably be safest to copy definitions from other documents, such as from [RFC2865] Section 1: RADIUS Server A RADIUS server is responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. Network Access Server A Network Access Server (NAS) provides access to the network and operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned. Attribute A Type-Length-Value tuple encapsulating data elements as defined in [RFC2865]. Section 3 You might say a few words about what happens if the Length of the enclosed RADIUS attributes exceeds the potential length of the sub-option. Section 4 " The RADIUS server that implements this specification MUST be configured to return the User-Name and Class attributes to the NAS, and MAY return other attributes. To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, only the attributes in the table below SHOULD be included in this sub-option. Because RADIUS servers rely on the directive in section 1.1 or RFC 2865 that "A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.", a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service. The following table, based on the analysis in RFC 3580 [9], lists attributes that MAY be included:" Since there is no way for a RADIUS server to know that the NAS supports this specification, I'm not sure how the directives in this paragraph can be carried out. The implication here seems to be that the User-Name and Class attributes are required to determine the IP configuration of the host, even where the Framed-Pool or Framed-IPv6-Prefix attributes are included. Since RFC 2865 specifies that the inclusion of the User-Name and Class attributes in an Access-Accept is optional, the statement above effectively implies an udpate to the attribute table in RFC 2865 Section 5.44. Also, I think the issue is not what a RADIUS server sends, but what a DHCP relay encapsulates in the option or what the DHCP server looks at or ignores, because the RADIUS server has no way to know whether the NAS supports this specification or not. I'd prefer that these paragraphs be rephrased as follows: " The table below, based on the analysis in RFC 3580 [9], lists attributes that MAY be included in the sub-option. In order to avoid potential side effects that would change the meaning of existing RADIUS attributes, a relay agent SHOULD only encapsulate the attributes included in the table below. The DHCP server MUST use the attributes that are included to provide the service implied by those attributes and MUST NOT introduce unintended side effects. Inclusion of the User-Name and Class attributes may be useful for diagnostic purposes as well as to assist the DHCP server in determining the appropriate configuration. However, since this specification does not provide a mechanism for a RADIUS server to determine whether the NAS supports this specification, a RADIUS server cannot know that the User-Name and Class attributes are expected. As indicated in [RFC2865] Section 5.44, the inclusion of the User-Name and Class attributes within an Access-Accept is optional. A DHCP server therefore cannot depend on these attributes being present, and where they are ommitted, the DHCP server MUST provide IP configuration as best it can, based on the contents of the DHCP packet and the other RADIUS attributes present, such as Framed-Pool and Framed-IPv6-Prefix. However, since inclusion of the User-Name and Class attributes in an Access-Accept may be useful for other reasons (such as where Identity privacy or tunneled EAP methods are supported), for optimal diagnosability and interoperability, it is suggested that RADIUS servers be configured to return the User-Name and Class attributes in the Access-Accept whenever EAP authentication is used." Section 5 " The RADIUS Attributes sub-option MUST only contain the attributes provided in the RADIUS Access/Accept message. The DHCP relay agent MUST NOT add more than one RADIUS Attributes sub-option in a message." This seems to imply that all the attributes are included. Suggest rephrasing to: " The RADIUS Attributes sub-option MUST only contain a subset of attributes provided in the RADIUS Access-Accept message. The DHCP relay agent MUST NOT add more than one RADIUS Attributes sub-option in a message." Section 6 " When the DHCP server receives a message from a relay agent containing a RADIUS Attributes sub-option, it extracts the contents of the sub-option and uses that information in selecting configuration parameters for the client. Even if the relay agent forwards other RADIUS attributes from the RADIUS server, the DHCP server SHOULD ignore any attributes it receives for which it cannot ensure that the associated service will be provided either by the DHCP server or the relay agent. If the DHCP server uses attributes not specified here, it might result in side effects not anticipated in the existing RADIUS specifications." Suggest rephrasing to: " When the DHCP server receives a message from a relay agent containing a RADIUS Attributes sub-option, it extracts the contents of the sub-option and uses that information in selecting configuration parameters for the client. If the relay agent forwards RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. If the DHCP server uses attributes not specified here, this may result in side effects not anticipated in the existing RADIUS specifications." |
2004-05-01
|
08 | Margaret Cullen | [Note]: 'Participant in PROTO Team pilot: Working Group Chair Followup of DISCUSS Comments http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by Margaret Wasserman |
2004-04-29
|
08 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-04-29
|
08 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Amy Vezza |
2004-04-29
|
08 | Margaret Cullen | Note field has been cleared by Margaret Wasserman |
2004-04-29
|
08 | Bert Wijnen | [Ballot discuss] Quite a set of comments and concerns from the AAA-doctors. Need to merge them into one set of DISCUSS and COMMENT statements. |
2004-04-29
|
08 | Bert Wijnen | [Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen |
2004-04-29
|
08 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-04-28
|
08 | Margaret Cullen | [Note]: 'There are recent comments on this document from the AAA doctors that may need to be addressed before publication.' added by Margaret Wasserman |
2004-04-28
|
08 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-04-28
|
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-04-28
|
08 | Jon Peterson | [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson |
2004-04-28
|
08 | Jon Peterson | [Ballot comment] Nit: Last paragraph of Section 3, "to return few than", should be "to return fewer than"? |
2004-04-28
|
08 | Jon Peterson | [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson |
2004-04-27
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Undefined by Russ Housley |
2004-04-27
|
08 | Russ Housley | [Ballot comment] Please ensure that "IEEE" appears before "802.1X" throughout the document. In section 8, please add "[1]" following the reference to RFC 2131 … [Ballot comment] Please ensure that "IEEE" appears before "802.1X" throughout the document. In section 8, please add "[1]" following the reference to RFC 2131. In section 8, please add "[5]" following the reference to RFC 3046. I find the following alternative to Figure 1 easier to read. If you agree, use it. +-----------------+ |Device requesting| | network access | +-----------------+ | ^ | | (1) | (1) Request for access | | | (4) (2) Request for authentication v | +-----------------+ (3) Access-Accept/Reject | NAS | |(802.1X and DHCP | (4) Success/Failure | relay agent) | +-----------------+ | ^ | | (2) | | | | (3) v | +-----------------+ | RADIUS | | Server | +-----------------+ |
2004-04-27
|
08 | Russ Housley | [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley |
2004-04-27
|
08 | Ted Hardie | [Ballot discuss] These two statements seem to be at odds: The RADIUS Attributes sub-option described in this document is … [Ballot discuss] These two statements seem to be at odds: The RADIUS Attributes sub-option described in this document is not limited to use in conjunction with IEEE 802.1X and can be used to carry RADIUS attributes obtained by the relay agent for any reason. and a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service. The following table, based on the analysis in RFC 3580 [10], lists attributes that MAY be included That is, there seems to be a functional contradiction in the second statement to the first statement--you SHOULD limit the use of this sub-option to those cases where the relay agent can ensure that the service will be provided. Perhaps it might be simpler to adjust the first to say "but it is not limited to use in 802.11x contexts". I'm also a bit confused as to why the second is a SHOULD. This section raised a similar question: If the relay agent forwards RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. Why are these SHOULDs rather than MUSTs? For example, could someone use something like draft-adrangi-radiusext-location-information or a Vendor specific attribute that did something similar? |
2004-04-27
|
08 | Ted Hardie | [Ballot discuss] These two statements seem to be at odds: The RADIUS Attributes sub-option described in this document is … [Ballot discuss] These two statements seem to be at odds: The RADIUS Attributes sub-option described in this document is not limited to use in conjunction with IEEE 802.1X and can be used to carry RADIUS attributes obtained by the relay agent for any reason. and a RADIUS server SHOULD send only those attributes for which the relay agent can ensure that either the relay agent or the DHCP server will provide the associated service. The following table, based on the analysis in RFC 3580 [10], lists attributes that MAY be included That is, there seems to be a functional contradiction in the second statement to the first statement--you SHOULD limit the use of this sub-option ot those cases where the relay agent can ensure that the service will be provided. Perhaps it might be simpler to adjust the first to say "but it is not limited to use in 802.11x contexts". I'm also a bit confused as to why the second is a SHOULD. This section raised a similar question: If the relay agent forwards RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. Why are these SHOULDs rather than MUSTs? For example, could someone use something like draft-adrangi-radiusext-location-information or a Vendor specific attribute that did something similar? |
2004-04-27
|
08 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie |
2004-04-27
|
08 | Steven Bellovin | [Ballot comment] In section 3, do you mean "octets o1...oN" or "b1...bN"? |
2004-04-27
|
08 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-04-19
|
08 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-04-17
|
08 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for Writeup::Revised ID Needed by Margaret Wasserman |
2004-04-17
|
08 | Margaret Cullen | Placed on agenda for telechat - 2004-04-29 by Margaret Wasserman |
2004-04-17
|
08 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-04-17
|
08 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-04-17
|
08 | Margaret Cullen | Created "Approve" ballot |
2004-04-13
|
06 | (System) | New version available: draft-ietf-dhc-agentopt-radius-06.txt |
2004-04-01
|
05 | (System) | New version available: draft-ietf-dhc-agentopt-radius-05.txt |
2004-03-25
|
08 | Margaret Cullen | State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Margaret Wasserman |
2004-03-23
|
08 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-03-09
|
08 | Amy Vezza | Last call sent |
2004-03-09
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-03-08
|
08 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-03-08
|
08 | Margaret Cullen | State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Margaret Wasserman |
2004-03-08
|
08 | (System) | Ballot writeup text was added |
2004-03-08
|
08 | (System) | Last call text was added |
2004-03-08
|
08 | (System) | Ballot approval text was added |
2004-03-08
|
08 | Margaret Cullen | Further comments from Bernard Aboba to be handled along with IETF Last Call comments. |
2004-02-13
|
04 | (System) | New version available: draft-ietf-dhc-agentopt-radius-04.txt |
2004-02-03
|
08 | Margaret Cullen | Waiting for an update from the authors based on comments from Bernard. |
2004-01-30
|
08 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2004-01-30
|
08 | Margaret Cullen | Document will be updated based on discussion between authors and Bernard Aboba. |
2004-01-19
|
08 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2004-01-19
|
08 | Margaret Cullen | Waiting for comments from Thomas, based on Bernard's review. |
2003-12-16
|
08 | Margaret Cullen | Thomas has review comments from expert reviewers that he needs to get together and send to the authors and the WG. |
2003-10-07
|
03 | (System) | New version available: draft-ietf-dhc-agentopt-radius-03.txt |
2002-11-04
|
02 | (System) | New version available: draft-ietf-dhc-agentopt-radius-02.txt |
2002-10-24
|
01 | (System) | New version available: draft-ietf-dhc-agentopt-radius-01.txt |
2002-02-21
|
00 | (System) | New version available: draft-ietf-dhc-agentopt-radius-00.txt |