From owner-ietf-radius@livingston.com Wed Mar 1 00:11:38 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11652 for ; Wed, 1 Mar 2000 00:11:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA26071; Tue, 29 Feb 2000 21:08:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA17889 for ietf-radius-outgoing; Tue, 29 Feb 2000 21:10:41 -0800 (PST) Message-ID: <38BCA48B.EC61E355@asiapacificm01.nt.com> Date: Wed, 01 Mar 2000 05:03:07 +0000 From: "Andrew Morton" Organization: Nortel Networks, Wollongong Australia X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.9-27mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Glen Zorn CC: ietf-radius@livingston.com Subject: Re: (radius) interim-update accounting References: <200003010451.UAA08236@franklin.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Andrew Morton" Content-Transfer-Encoding: 7bit Thanks, Glen. Do you know why the Acct-Interim-Interval attribute is restricted to Access-Accept? What would be the issues if this were also used by the server to modify the interval mid-session? Glen Zorn wrote: > > At 02:18 AM 03/01/2000 +0000, Andrew Morton wrote: > > > >[ Aplogies if this is an FAQ - I've just joined ]. > > > >This concerns interim accounting - the ability for a client to > >periodically send accounting updates to the server for a particular > >session. > > > >I note that draft-ietf-radius-accounting-v2-05 mentions 'Interim-Update' > >as being a valid value for the Acct-Status-Type attribute. It doesn't > >describe the design intent but I guess that's pretty obvious. > > > >I have a customer requirement for interim updates so this capability > >will be useful. But there is also a requirement to be able to adjust > >the frequency with which the client sends the updates - perhaps hourly > >for the first 24 hours, daily after that, etc. > > Using the Acct-Interim-Interval attribute (see below), the update interval can be set on a per-session basis. > > > > >Has there been any consideration given to allowing the server to specify > >this frequency? This could be an attribute of the > >accounting-request(start) message. Alternatively (and I prefer this), > >the server could add an attribute to each > >accounting-request(interim-update) message's ack to tell the client when > >it should next send an interim update. > > The attribute is Acct-Interim-Interval; it is described in section 5.16 of http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-07.txt; its usage is described in section 2.1 of the same document. It is only allowed in Access-Accept messages. > > > > >I'd appreciate some guidance on how to provide this functionality - it > >would be quite ideal if this capability were captured in the draft so > >VSA proliferation can be avoided. > > > >Thanks. > >- > >To unsubscribe, email 'majordomo@livingston.com' with > >'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Mar 11 13:59:27 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19361 for ; Sat, 11 Mar 2000 13:59:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id KAA20758; Sat, 11 Mar 2000 10:56:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA22411 for ietf-radius-outgoing; Sat, 11 Mar 2000 10:50:24 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-radius@livingston.com Subject: (radius) moving to ds without utf8 interoperability Message-Id: Date: Sat, 11 Mar 2000 10:49:34 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit as no one has responded to the request for an interoperability report for utf8 encodings, we need to consider how to move forward should none be forthcoming. from rfc2026 4.1.2 Draft Standard ... The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 14 13:50:07 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17175 for ; Tue, 14 Mar 2000 13:49:53 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id KAA06432; Tue, 14 Mar 2000 10:46:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA02894 for ietf-radius-outgoing; Tue, 14 Mar 2000 10:43:39 -0800 (PST) X-Authentication-Warning: hme0.s0092.idc1.oss.level3.com: bjames owned process doing -bs Date: Tue, 14 Mar 2000 11:39:41 -0700 (MST) From: Barry L James X-Sender: bjames@hme0.s0092.idc1.oss.level3.com To: ietf-radius@livingston.com Subject: (radius) Some questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry L James Hi all, I have just a couple of questions that I'm unclear on and was wondering if anyone might provide some insight. 1. What are "undistinguished octets" exactly? Does this mean there should not be any discrete boundaries between octets and that the server shouldn't assume to "cast" them into any specific data type? 2. Why is the minimum length for a CHAP-Challenge 7? With RFC defaults, it would be three (1+1+1 since a STRING value cannot be NULL). Is there some CHAP requirement of a minimum of a 5 byte challenge? 3. How does everyone feel about the attribute name guideline? It seems desirable to have all implementations use the same printable text names for attributes but real-world evaluation shows this is not the case (ie User-Service vs Service-Type for example). The RFC doesn't (or I couldn't find) speak about the desire to have congruency in printable text names. Even though the text name won't affect the operation of the protocol, it does shorten negotiation time when coming to common terms with different implementations that might use different attribute names in dictionaries. Is there an official RADIUS WG stand on this? Thanks in advance for any comments. Regards, Barry Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's http://www.level3.com | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 14 15:42:00 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01329 for ; Tue, 14 Mar 2000 15:41:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA10007; Tue, 14 Mar 2000 12:38:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA09762 for ietf-radius-outgoing; Tue, 14 Mar 2000 12:38:26 -0800 (PST) Date: Tue, 14 Mar 2000 12:38:23 -0800 (PST) From: Carl Rigney Message-Id: <200003142038.MAA09754@server.livingston.com> To: bjames@Level3.net Subject: Re: (radius) Some questions Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney 1. What are "undistinguished octets" exactly? It means they should be treated as 8-bit values without any particular internal structure; i.e. don't assume its ASCII text or in a specific format. 2. Why is the minimum length for a CHAP-Challenge 7? With RFC defaults, it would be three (1+1+1 since a STRING value cannot be NULL). Is there some CHAP requirement of a minimum of a 5 byte challenge? There's a 1-octet Chap ID, and the minimum CHAP-Challenge is 32 bits (4 octets), so that's a minimum length of 7 octets. A CHAP-Challenge shorter of 24 bits or shorter is only pretend security since it would be easily dictionary-attacked. Actually even a challenge of 32-bits is pretty short, but at least one major RADIUS vendor supported 32-bit challenges, so that was set as the minimum. 3. How does everyone feel about the attribute name guideline? It seems desirable to have all implementations use the same printable text names for attributes but real-world evaluation shows this is not the case (ie User-Service vs Service-Type for example). It's an implementation issue. User-Service was the old name for Service-Type, so some RADIUS servers still use it, or support both for backwards compatibility (6 years later...). Even though the text name won't affect the operation of the protocol, it does shorten negotiation time when coming to common terms with different implementations that might use different attribute names in dictionaries. When comparing different implementations you should use the attribute numbers, which must be the same. The attribute names are an implementation detail. Its convenient if implementers wind up using the same attribute names, but I wouldn't depend on it. And in some cases the attributes wind up getting renamed, like Signature in the latest extensions draft being renamed Message-Authenticator. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Mar 16 17:34:50 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22258 for ; Thu, 16 Mar 2000 17:34:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id OAA11992; Thu, 16 Mar 2000 14:30:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA17232 for ietf-radius-outgoing; Thu, 16 Mar 2000 14:27:16 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Thu, 16 Mar 2000 17:08 EST Subject: (radius) draft conflict Content-Type: text/plain Message-ID: <38d15fbc0.4320@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff I believe there's a conflict between draft-ietf-radius-radius-v2-06.txt and draft-ietf-radius-ext-07.txt. The latter, in section 5.13, says " A RADIUS Server not supporting EAP-Message MUST return an Access- Reject if it receives an Access-Request containing an EAP-Message attribute." but the former, in section 5, says " A RADIUS server MAY ignore Attributes with an unknown Type." These statements conflict, as a server not supporting EAP will treat EAP-Message as an unknown attribute type. In practice this should not be a problem, as a request containing EAP-Message will not contain User-Password or CHAP-Password, and is likely to be rejected anyway, but I think the wording conflict should be resolved, by putting the requirement on the NAS instead: "A NAS which has sent an Access-Request containing EAP-Message and receives an Access-Accept or Access-Challenge not containing an EAP-Message, should treat the packet as an Access-Reject." This choice is in accord with the principle that new features should not retroactively require changes in nodes not supporting them. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 20 17:47:46 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11485 for ; Mon, 20 Mar 2000 17:47:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id OAA06077; Mon, 20 Mar 2000 14:44:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA17837 for ietf-radius-outgoing; Mon, 20 Mar 2000 14:40:12 -0800 (PST) From: "Leonard Cuff" To: Subject: (radius) Session ID in accounting on/off ? Date: Mon, 20 Mar 2000 14:30:57 -0800 Message-ID: <000301bf92bb$f5e18340$ed69c081@multipro.acc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <199811121538.KAA11698@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Leonard Cuff" Content-Transfer-Encoding: 7bit The current draft of the accounting spec says that exactly 1 Accounting-Session ID attribute should be present in all RADIUS accounting messages. (In the list in paragraph 5.13). Is this true for accounting-on and accounting-off messages? TIA Leonard - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 21 02:52:19 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13799 for ; Tue, 21 Mar 2000 02:52:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id XAA12257; Mon, 20 Mar 2000 23:48:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id XAA07369 for ietf-radius-outgoing; Mon, 20 Mar 2000 23:48:43 -0800 (PST) X-Authentication-Warning: hme0.s0092.idc1.oss.level3.com: bjames owned process doing -bs Date: Tue, 21 Mar 2000 00:45:16 -0700 (MST) From: Barry L James X-Sender: bjames@hme0.s0092.idc1.oss.level3.com To: ietf-radius@livingston.com Subject: (radius) Login-Service Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry L James Hi all, Can anyone tell me why the value 7 is skipped in the enumerated values for this attribute? Thanks! Barry - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 31 16:13:36 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18341 for ; Fri, 31 Mar 2000 16:13:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id NAA05887; Fri, 31 Mar 2000 13:09:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA09630 for ietf-radius-outgoing; Fri, 31 Mar 2000 13:03:30 -0800 (PST) From: Chris_Cormier@3com.com X-Lotus-FromDomain: 3COM To: randy@psg.com cc: ietf-radius@livingston.com, matt@ascend.com, wijnen@VNET.IBM.COM Message-ID: <882568B3.0073064D.00@hqoutbound.ops.3com.com> Date: Fri, 31 Mar 2000 12:56:43 -0800 Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Chris_Cormier@3com.com > draft-ietf-radius-radius-v2-03.txt > o waiting for changes as outlined in carl's message [1] below I've submitted (today) draft-ietf-radius-radius-v2-04.txt including this change. > draft-ietf-radius-ext-05.txt > o waiting for response to security review comments [2] below > o also would be nice if iana points in [3] were addressed in an iana > considerations section or by some other means I've submitted (today) draft-ietf-radius-ext-06.txt with these two changes updating draft 05. Signature has been renamed Message-Authenticator and the claims about preventing dictionary attacks clarified to indicate that they do not protect against packet interception for offline attacks, only against dictionary attacks against the server itself (using the text suggested on the ietf-radius mailing list by the person who raised the objection). An IANA Considerations section has been added as follows (I also added the same language to the RADIUS Accounting draft): IANA Considerations The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces as described in the "IANA Considerations" section of [1], in accordance with BCP 26 [10]. [1] refers to the updated RADIUS Draft. --- Attachment From randy@psg.com Fri Jan 28 16:53:41 2000 From: Randy Bush To: Matt Holdrege Cc: crigney@lucent.com, ietf-radius@livingston.com Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt Message-Id: Date: Fri, 28 Jan 2000 16:53:07 -0800 ---[1]--- From: Carl Rigney Date: Wed, 5 Jan 2000 04:02:01 -0800 (PST) To: ietf-radius@livingston.com Subject: (radius) Security Considerations text Here's the text I plan to put into Security Considerations of the new RADIUS draft. The authors for the RADIUS Tunneling draft should insert similar language (for Tunnel-Password instead of Password) and also insert an IANA Considerations section into their draft (feel free to borrow the one from my latest RADIUS draft). Please make these changes and submit the update to the Internet-Drafts directory by this Friday 1/7 so things can move along. I'll have the new RADIUS draft submitted Wednesday. The User-Password hiding mechanism described in Section 5.2 has not been subjected to significant amounts of cryptanalysis in the published literature. Some in the IETF community are concerned that this method might not provide sufficient confidentiality protection [14] to passwords transmitted using RADIUS. Users should evaluate their threat environment and consider whether additional security mechanisms should be employed. [14] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. Suggestions for wordsmithing the language to be more useful are gratefully accepted, if you send them Wednesday. ---[2]--- Much of my nervousness about cryptographic goop appearing in this draft was in the section that describes the ARAP authentication protocol. Since this is descriptive, rather than prescriptive, I can't really say that any issue I have with it is meaningful; ARAP isn't our protocol. Section 5.14 talks about Signature attributes. Two issues with this: 1) They're not really signatures, if we want to be precise in our use of the language. A more precise usage would be a MAC (Message Authenticator Code). 2) The draft talks about how this attribute can prevent dictionary attacks against CHAP, ARAP or EAP. I fail to see how it accomplishes this. If I can intercept one of these packets, then I can still mount a dictionary attack against a CHAP response, for example, and use a front-door attack using the NAS. That is, I don't need to be able to forge NAS<-->RADIUS-SERVER packets in order to sucessfully mount a dictionary attack. While having a cryptographic MAC in the NAS<--->RADIUS-SERVER protocol is useful for other very good reasons, it doesn't, in this case, provide protection from dictionary attacks. ---[3]--- Rereading all the notes, I now see that there is an IANA considerations section in draft-ietf-radius-radius-v2-03.txt (coming down the pipeline) that takes care of much of this. However, they don't list all the types that have been defined (the IANA site should do this I guess), rather they just say what is left to assign (which isn't exactly in sync with what is up on the IANA page). Seem to me like draft-ietf-radius-ext-05.txt defines a bunch of the IANA values that are apparently in use, but are not recorded on the IANA page. It would be good if the document would be clear that IANA needs to record them. -30- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 31 16:16:38 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18372 for ; Fri, 31 Mar 2000 16:16:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id NAA05971; Fri, 31 Mar 2000 13:12:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA09958 for ietf-radius-outgoing; Fri, 31 Mar 2000 13:09:42 -0800 (PST) From: Chris_Cormier@3com.com X-Lotus-FromDomain: 3COM To: ietf-radius@livingston.com Message-ID: <882568B3.007312AD.00@hqoutbound.ops.3com.com> Date: Fri, 31 Mar 2000 12:57:20 -0800 Subject: (radius) IPv6? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Chris_Cormier@3com.com Hi - In the archives for this list, it is mentioned that Radius for IPv6 is beyond the scope of this working group. I am wondering if Radius support of IPv6 might be addressed by this or another working group in the near (or distant) future. Assuming that this item isn't currently on any groups charter, I do realize that I am asking for nothing more than an educated guess. Any and all info/guesses/etc. are appreciated, Thanks, Bridgette - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.