From owner-ietf-radius@livingston.com Thu Feb 3 18:55:42 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 SAA02294 for ; Thu, 3 Feb 2000 18:55:41 -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 PAA18277; Thu, 3 Feb 2000 15:52:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA27443 for ietf-radius-outgoing; Thu, 3 Feb 2000 15:46:55 -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) time to finish this already! Message-Id: Date: Thu, 03 Feb 2000 15:45:35 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit hellooooo! how can we finish, declare victory, and move on to a new life? what can i do to help? randy 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 Date: Fri, 28 Jan 2000 16:53:07 -0800 the status of drafts is as follows: draft-ietf-radius-radius-v2-03.txt o waiting for changes as outlined in carl's message [1] below draft-ietf-radius-tunnel-auth-09.txt o iesg has in process 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 draft-ietf-radius-tunnel-acct-05.txt o approved by iesg pending security warnings as agreed draft-ietf-radius-accounting-v2-02.txt o normative reference to tunnel-auth, so waiting for the latter to pass randy ---[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. From owner-ietf-radius@livingston.com Fri Feb 4 10:10:03 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 KAA29544 for ; Fri, 4 Feb 2000 10:10:02 -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 HAA29772; Fri, 4 Feb 2000 07:06:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA24860 for ietf-radius-outgoing; Fri, 4 Feb 2000 07:02:55 -0800 (PST) Message-Id: <4.2.2.20000204093929.00d1d160@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 04 Feb 2000 09:59:50 -0500 To: Randy Bush , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) time to finish this already! In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" At 03:45 PM 2/3/00 -0800, Randy Bush wrote: >---[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. I've had an off-line discussion with Marcus about this, I think we came to an understanding between us. The confusion over term "dictionary attacks" seems profound. There is nothing proscribed in RADIUS to prevent front door dictionary attacks. The RFCs/drafts do not ever mention keeping state on number of attempts, or blacklisting, etc, etc. These are left to the authentication implementation. In this context, we are referring to a weakness in RADIUS whereas, authentication request messages are "secured" based on the shared secret and the encrypted contents of the User-Password attribute. If the User-Password attribute is not authenticated in the processing of a message, as happens with CHAP, or some compulsory tunnel setups, then the knowledge of the secret has not been confirmed. This opens the door for a system with access to the network to send RADIUS packets to the server and attempt to guess an account password without knowing a secret. (actually most servers these days will not respond to an unknown client, (also not an RFC requirement) but masquerading as a known client could be attempted) By adding an attribute that both includes an integrity check, and causes the secret to be confirmed, and therefore strengthens the security of NAS<-->RADIUS-SERVER exchanges in these cases. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 4 10:28: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 KAA00073 for ; Fri, 4 Feb 2000 10:28:17 -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 HAA00223; Fri, 4 Feb 2000 07:25:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA25662 for ietf-radius-outgoing; Fri, 4 Feb 2000 07:23:31 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "David Mitton" Cc: ietf-radius@livingston.com Subject: Re: (radius) time to finish this already! References: <4.2.2.20000204093929.00d1d160@ZBL6C008.corpeast.baynetworks.com> Message-Id: Date: Fri, 04 Feb 2000 07:20:16 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > I've had an off-line discussion with Marcus about this, I think we came to > an understanding between us. thank you! > The confusion over term "dictionary attacks" seems profound. > > There is nothing proscribed in RADIUS to prevent front door dictionary > attacks. The RFCs/drafts do not ever mention keeping state on number of > attempts, or blacklisting, etc, etc. These are left to the authentication > implementation. > > In this context, we are referring to a weakness in RADIUS whereas, > authentication request messages are "secured" based on the shared secret > and the encrypted contents of the User-Password attribute. If the > User-Password attribute is not authenticated in the processing of a > message, as happens with CHAP, or some compulsory tunnel setups, then the > knowledge of the secret has not been confirmed. This opens the door for a > system with access to the network to send RADIUS packets to the server and > attempt to guess an account password without knowing a secret. (actually > most servers these days will not respond to an unknown client, (also not an > RFC requirement) but masquerading as a known client could be attempted) > > By adding an attribute that both includes an integrity check, and causes > the secret to be confirmed, and therefore strengthens the security of > NAS<-->RADIUS-SERVER exchanges in these cases. so what is the conclusion? will marcus un-object, or will the document be changed? randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Feb 5 04:13:25 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 EAA02721 for ; Sat, 5 Feb 2000 04:13:25 -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 BAA16059; Sat, 5 Feb 2000 01:11:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA09950 for ietf-radius-outgoing; Sat, 5 Feb 2000 01:08:43 -0800 (PST) Date: Fri, 04 Feb 2000 14:26:02 -0800 From: Paul Krumviede Subject: Re: (radius) time to finish this already! In-reply-to: <4.2.2.20000204093929.00d1d160@ZBL6C008.corpeast.baynetworks.com> To: David Mitton , Randy Bush , ietf-radius@livingston.com Message-id: <486589954.949674362@ndss171.remote.sdsc.edu> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Content-Transfer-Encoding: 7BIT Isn't it true that even in the presence of a User-Password attribute it isn't possible to distinguish between an invalid password or use of an invalid secret? I'd not sure that this allows any interesting attack, but it seems misleading to to suggest that there is any real authentication of a request. -paul --On Friday, 04 February, 2000 09:59 -0500 David Mitton wrote: > At 03:45 PM 2/3/00 -0800, Randy Bush wrote: >> ---[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. > > I've had an off-line discussion with Marcus about this, I think we came > to an understanding between us. The confusion over term "dictionary > attacks" seems profound. > > There is nothing proscribed in RADIUS to prevent front door dictionary > attacks. The RFCs/drafts do not ever mention keeping state on number of > attempts, or blacklisting, etc, etc. These are left to the > authentication implementation. > > In this context, we are referring to a weakness in RADIUS whereas, > authentication request messages are "secured" based on the shared secret > and the encrypted contents of the User-Password attribute. If the > User-Password attribute is not authenticated in the processing of a > message, as happens with CHAP, or some compulsory tunnel setups, then > the knowledge of the secret has not been confirmed. This opens the door > for a system with access to the network to send RADIUS packets to the > server and attempt to guess an account password without knowing a > secret. (actually most servers these days will not respond to an > unknown client, (also not an RFC requirement) but masquerading as a > known client could be attempted) > > By adding an attribute that both includes an integrity check, and causes > the secret to be confirmed, and therefore strengthens the security of > NAS<-->RADIUS-SERVER exchanges in these cases. > > Dave. > > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Consulting Engineer, Nortel Networks 978-288-4570 Direct > Carrier Packet Solutions, Preside 978-288-3030 FAX > Billerica, MA 01821 dmitton@nortelnetworks.com > > - > 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 Mon Feb 7 10:12:03 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 KAA12067 for ; Mon, 7 Feb 2000 10:11:59 -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 HAA05307; Mon, 7 Feb 2000 07:07:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA11001 for ietf-radius-outgoing; Mon, 7 Feb 2000 07:03:16 -0800 (PST) Message-Id: <4.2.2.20000207093344.00d21100@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 07 Feb 2000 10:00:36 -0500 To: Paul Krumviede , "David Mitton" , Randy Bush , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) time to finish this already! In-Reply-To: <486589954.949674362@ndss171.remote.sdsc.edu> References: <4.2.2.20000204093929.00d1d160@ZBL6C008.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Paul, It's true that if either the password data is incorrect, or the "shared" secret used to generate the contents of the User-Password attribute in the message is incorrect, that the server cannot tell the difference, and can only do one thing, return an Access-Reject. For the authentication to be made, both have to be correct. Everything else is a failed attempt. So I'm not sure what you think is misleading here? Well, okay, are you really asking about non-User-Password accesses? And the use of the Signature attribute there? In that case, only the message content and Secret is being validated. You're right that there is no password authentication. But this would typically be used where a Chap challenge/response has done it's own obscuring, or in the tunnelling case where we are just the first step in multi-phase authentication. Dave. BTW: I didn't participate in the design of this stuff. I found RADIUS pretty much the way it is in 1996 when I joined Xylogics and started implementing it as a replacement for our own proprietary AAA protocol. The RADIUS WG was chartered to write the RFC pretty much as-is. And was repeatedly advised by it's then AD and WG Chair to not attempt to make significant design changes to the protocol. Any attempt to do significant revamps of the protocol, like say draft-ietf-calhoun-enh-radius-00.txt, June-1996, were rejected as working group items. So I can explain how the stuff works within the confines of what has been done in the WG since then, but we haven't been allowed (or given much incentive) to do much better than that. At 02:26 PM 2/4/00 -0800, Paul Krumviede wrote: >Isn't it true that even in the presence of a User-Password attribute >it isn't possible to distinguish between an invalid password or use >of an invalid secret? I'd not sure that this allows any interesting >attack, but it seems misleading to to suggest that there is any >real authentication of a request. > >-paul > >--On Friday, 04 February, 2000 09:59 -0500 David Mitton > wrote: > >>At 03:45 PM 2/3/00 -0800, Randy Bush wrote: >>>---[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. >> >>I've had an off-line discussion with Marcus about this, I think we came >>to an understanding between us. The confusion over term "dictionary >>attacks" seems profound. >> >>There is nothing proscribed in RADIUS to prevent front door dictionary >>attacks. The RFCs/drafts do not ever mention keeping state on number of >>attempts, or blacklisting, etc, etc. These are left to the >>authentication implementation. >> >>In this context, we are referring to a weakness in RADIUS whereas, >>authentication request messages are "secured" based on the shared secret >>and the encrypted contents of the User-Password attribute. If the >>User-Password attribute is not authenticated in the processing of a >>message, as happens with CHAP, or some compulsory tunnel setups, then >>the knowledge of the secret has not been confirmed. This opens the door >>for a system with access to the network to send RADIUS packets to the >>server and attempt to guess an account password without knowing a >>secret. (actually most servers these days will not respond to an >>unknown client, (also not an RFC requirement) but masquerading as a >>known client could be attempted) >> >>By adding an attribute that both includes an integrity check, and causes >>the secret to be confirmed, and therefore strengthens the security of >>NAS<-->RADIUS-SERVER exchanges in these cases. >> >> Dave. >> >>--------------------------------------------------------------- >>David Mitton ESN: 248-4570 >>Consulting Engineer, Nortel Networks 978-288-4570 Direct >>Carrier Packet Solutions, Preside 978-288-3030 FAX >>Billerica, MA 01821 dmitton@nortelnetworks.com >> >>- >>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. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 9 18:20: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 SAA26704 for ; Wed, 9 Feb 2000 18:20: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 PAA06122; Wed, 9 Feb 2000 15:14:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA29303 for ietf-radius-outgoing; Wed, 9 Feb 2000 15:10:19 -0800 (PST) Date: Wed, 09 Feb 2000 15:10:08 -0800 From: Paul Krumviede Subject: Re: (radius) time to finish this already! In-reply-to: <4.2.2.20000207093344.00d21100@ZBL6C008.corpeast.baynetworks.com> To: David Mitton , Randy Bush , ietf-radius@livingston.com Message-id: <921235714.950109008@SKOLEM2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Content-Transfer-Encoding: 7BIT --On Monday, 07 February, 2000 10:00 -0500 David Mitton wrote: > Paul, > > It's true that if either the password data is incorrect, or the "shared" > secret used to generate the contents of the User-Password attribute in > the message is incorrect, that the server cannot tell the difference, > and can only do one thing, return an Access-Reject. > > For the authentication to be made, both have to be correct. > Everything else is a failed attempt. > > So I'm not sure what you think is misleading here? The issue is that I've seen groups that want to raise an alarm on successive failures. Of course, they want the alarm to be unambiguous so that it can be dealt with correctly. The question is, how does one categorize such failures, even if the User-Password attribute is present? Attempts to guess a password for a particular account? A user persistently using an incorrect password? A mis- configured NAS? Or somebody attempting to spoof a NAS? The latter 2 are a bit easier, as all attempts from that source address would fail, but this isn't all that reliable in large facilities at off-peak hours. The concern is simply that people not automatically assume that a failed authentication attempt, or more particularly a series of failed attempts, can be reliably determined to fall into any particular failure category. > Well, okay, are you really asking about non-User-Password accesses? > And the use of the Signature attribute there? > In that case, only the message content and Secret is being validated. > You're right that there is no password authentication. > > But this would typically be used where a Chap challenge/response has > done it's own obscuring, or in the tunnelling case where we are just the > first step in multi-phase authentication. > > Dave. > > BTW: I didn't participate in the design of this stuff. I found RADIUS > pretty much the way it is in 1996 when I joined Xylogics and started > implementing it as a replacement for our own proprietary AAA protocol. > The RADIUS WG was chartered to write the RFC pretty much as-is. And was > repeatedly advised by it's then AD and WG Chair to not attempt to make > significant design changes to the protocol. I seem to recall quite a few a rounds of this advice :-) > Any attempt to do significant revamps of the protocol, like say > draft-ietf-calhoun-enh-radius-00.txt, June-1996, were rejected as > working group items. > > So I can explain how the stuff works within the confines of what has > been done in the WG since then, but we haven't been allowed (or given > much incentive) to do much better than that. I know, and I'm not suggesting we do anything other than perhaps make it explicit that even in the case of use of the User-Password attribute it isn't clear that a failed authentication is due to a bad user password or a bad secret (or a broken implementation of something, but that goes without saying and is beyond the scope of a spec anyway). -paul > At 02:26 PM 2/4/00 -0800, Paul Krumviede wrote: >> Isn't it true that even in the presence of a User-Password attribute >> it isn't possible to distinguish between an invalid password or use >> of an invalid secret? I'd not sure that this allows any interesting >> attack, but it seems misleading to to suggest that there is any >> real authentication of a request. >> >> -paul >> >> --On Friday, 04 February, 2000 09:59 -0500 David Mitton >> wrote: >> >>> At 03:45 PM 2/3/00 -0800, Randy Bush wrote: >>>> ---[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. >>> >>> I've had an off-line discussion with Marcus about this, I think we came >>> to an understanding between us. The confusion over term "dictionary >>> attacks" seems profound. >>> >>> There is nothing proscribed in RADIUS to prevent front door dictionary >>> attacks. The RFCs/drafts do not ever mention keeping state on number >>> of attempts, or blacklisting, etc, etc. These are left to the >>> authentication implementation. >>> >>> In this context, we are referring to a weakness in RADIUS whereas, >>> authentication request messages are "secured" based on the shared >>> secret and the encrypted contents of the User-Password attribute. If >>> the User-Password attribute is not authenticated in the processing of a >>> message, as happens with CHAP, or some compulsory tunnel setups, then >>> the knowledge of the secret has not been confirmed. This opens the >>> door for a system with access to the network to send RADIUS packets to >>> the server and attempt to guess an account password without knowing a >>> secret. (actually most servers these days will not respond to an >>> unknown client, (also not an RFC requirement) but masquerading as a >>> known client could be attempted) >>> >>> By adding an attribute that both includes an integrity check, and >>> causes the secret to be confirmed, and therefore strengthens the >>> security of NAS<-->RADIUS-SERVER exchanges in these cases. >>> >>> Dave. >>> >>> --------------------------------------------------------------- >>> David Mitton ESN: 248-4570 >>> Consulting Engineer, Nortel Networks 978-288-4570 Direct >>> Carrier Packet Solutions, Preside 978-288-3030 FAX >>> Billerica, MA 01821 dmitton@nortelnetworks.com >>> >>> - >>> 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. > > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Consulting Engineer, Nortel Networks 978-288-4570 Direct > Carrier Packet Solutions, Preside 978-288-3030 FAX > Billerica, MA 01821 dmitton@nortelnetworks.com > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 10 10:16:33 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 KAA00012 for ; Thu, 10 Feb 2000 10:16:33 -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 HAA17719; Thu, 10 Feb 2000 07:11:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA26968 for ietf-radius-outgoing; Thu, 10 Feb 2000 07:09:18 -0800 (PST) Message-Id: <4.2.2.20000210095458.046da350@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 10 Feb 2000 10:03:37 -0500 To: Paul Krumviede , "David Mitton" , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) time to finish this already! In-Reply-To: <921235714.950109008@SKOLEM2> References: <4.2.2.20000207093344.00d21100@ZBL6C008.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Not to continue the issue with respect to the draft, but to offer a suggestion to would be server implementors... At 03:10 PM 2/9/00 -0800, Paul Krumviede wrote: >--On Monday, 07 February, 2000 10:00 -0500 David Mitton > wrote: > >>Paul, >> >>It's true that if either the password data is incorrect, or the "shared" >>secret used to generate the contents of the User-Password attribute in >>the message is incorrect, that the server cannot tell the difference, >>and can only do one thing, return an Access-Reject. >> >>For the authentication to be made, both have to be correct. >>Everything else is a failed attempt. >> >>So I'm not sure what you think is misleading here? > >The issue is that I've seen groups that want to raise an alarm >on successive failures. Of course, they want the alarm to be >unambiguous so that it can be dealt with correctly. The question >is, how does one categorize such failures, even if the User-Password >attribute is present? Attempts to guess a password for a particular >account? A user persistently using an incorrect password? A mis- >configured NAS? Or somebody attempting to spoof a NAS? The >latter 2 are a bit easier, as all attempts from that source address >would fail, but this isn't all that reliable in large facilities at off-peak >hours. > >The concern is simply that people not automatically assume that >a failed authentication attempt, or more particularly a series of >failed attempts, can be reliably determined to fall into any particular >failure category. Given the way RADIUS is, a server implementing user authentication failure thresholds should assume each authentication failure is a per user problem deal with as per it's policy, assuming/considering that configuration failures are rare and quickly dealt with. To detect configuration failures, the server should keep a simple counter of failures per NAS IP address, and if they reach a threshold, raise an alert that the secret may be mis-set, or you are under attack. A paranoid server may consider client blacklisting policies too. Dave. .... --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 10 10:36:32 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 KAA01046 for ; Thu, 10 Feb 2000 10:36:27 -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 HAA18253; Thu, 10 Feb 2000 07:29:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA27727 for ietf-radius-outgoing; Thu, 10 Feb 2000 07:29:41 -0800 (PST) Date: Thu, 10 Feb 2000 07:29:02 -0800 From: Paul Krumviede Subject: Re: (radius) time to finish this already! In-reply-to: <4.2.2.20000210095458.046da350@ZBL6C008.corpeast.baynetworks.com> To: David Mitton , ietf-radius@livingston.com Message-id: <979970074.950167742@[10.0.1.6]> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Content-Transfer-Encoding: 7BIT Your comment is eminently reasonable, with the possible exception of client black-listing. Given the ease of spoofing source addresses for protocols on top of IP, that sounds like a recipe for denial of service attacks. In particular, it was the apparent intention of some people to do this that made this issue stick in my mind at the time and to raise it now. -paul --On Thursday, 10 February, 2000 10:03 -0500 David Mitton wrote: > Not to continue the issue with respect to the draft, but to offer a > suggestion to would be server implementors... > > At 03:10 PM 2/9/00 -0800, Paul Krumviede wrote: >> --On Monday, 07 February, 2000 10:00 -0500 David Mitton >> wrote: >> >>> Paul, >>> >>> It's true that if either the password data is incorrect, or the >>> "shared" secret used to generate the contents of the User-Password >>> attribute in the message is incorrect, that the server cannot tell the >>> difference, and can only do one thing, return an Access-Reject. >>> >>> For the authentication to be made, both have to be correct. >>> Everything else is a failed attempt. >>> >>> So I'm not sure what you think is misleading here? >> >> The issue is that I've seen groups that want to raise an alarm >> on successive failures. Of course, they want the alarm to be >> unambiguous so that it can be dealt with correctly. The question >> is, how does one categorize such failures, even if the User-Password >> attribute is present? Attempts to guess a password for a particular >> account? A user persistently using an incorrect password? A mis- >> configured NAS? Or somebody attempting to spoof a NAS? The >> latter 2 are a bit easier, as all attempts from that source address >> would fail, but this isn't all that reliable in large facilities at >> off-peak hours. >> >> The concern is simply that people not automatically assume that >> a failed authentication attempt, or more particularly a series of >> failed attempts, can be reliably determined to fall into any particular >> failure category. > > Given the way RADIUS is, a server implementing user authentication > failure thresholds should assume each authentication failure is a per > user problem deal with as per it's policy, assuming/considering that > configuration failures are rare and quickly dealt with. > > To detect configuration failures, the server should keep a simple > counter of failures per NAS IP address, and if they reach a threshold, > raise an alert that the secret may be mis-set, or you are under attack. > A paranoid server may consider client blacklisting policies too. > > Dave. > > > .... > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Consulting Engineer, Nortel Networks 978-288-4570 Direct > Carrier Packet Solutions, Preside 978-288-3030 FAX > Billerica, MA 01821 dmitton@nortelnetworks.com > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 10 18:08: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 SAA12718 for ; Thu, 10 Feb 2000 18:08:25 -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 PAA29848; Thu, 10 Feb 2000 15:04:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA24753 for ietf-radius-outgoing; Thu, 10 Feb 2000 15:04:01 -0800 (PST) Date: Thu, 10 Feb 2000 23:00:45 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: ietf-radius@livingston.com Subject: (radius) User-Name with realms In-Reply-To: <979970074.950167742@[10.0.1.6]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry James When a proxy RADIUS receives a User-Name attribute with a realm prefix or suffix should it forward the request to the appropriate realm server with the User-Name unmodified (ie still containing the realm information) or should it strip the realm identifier and only send the username? Maybe I missed it, but I didn't see any specific mention of this behavior in the v2-03 draft. Thanks, 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 Fri Feb 11 09:41:57 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 JAA10150 for ; Fri, 11 Feb 2000 09:41:47 -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 GAA10847; Fri, 11 Feb 2000 06:39:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA22810 for ietf-radius-outgoing; Fri, 11 Feb 2000 06:35:22 -0800 (PST) From: mikko.alutoin@nokia.com Message-ID: <11CD408013B6D2119BB50008C7EA510C0291482B@eseis05nok> To: ietf-radius@livingston.com Cc: mikko.alutoin@nokia.com Subject: (radius) Question about RADIUS terminology Date: Fri, 11 Feb 2000 16:22:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: mikko.alutoin@nokia.com Dear all, I have a question related to the RADIUS terminology. What is the difference between proxy authentication and pre-authentication when talking about querying VPN tunnel attributes? Does proxy authentication mean that the first RADIUS server (at the tunnel client endpoint) has all the information needed to establish the tunnel and the session, because its database is updated periodicly by the RADIUS server at the tunnel server endpoint? And does the pre-authentication mean that the first RADIUS server proxies the Access-Request (which may contain either PPP user name + password or just the dialed number as a user name with some dummy password) to the RADIUS server at the tunnel server endpoint, which then returns the tunnel attributes in the Access-Accept with or without checking the PPP password? So what I'm trying to ask is that is the distinction between the two terms: A) Whether the NAS at the tunnel client endpoint fills the initial Access-Request with the PPP user name + password or dialed number + dummy password, in order to receive tunnel attributes. B) Whether the first RADIUS server needs to proxy the Access-Request in order to receive the tunnel attributes or not. C) Whether the PPP password is checked by the first RADIUS server or not. Best regards, Mikko Alutoin - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 11 12:03:02 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 MAA14678 for ; Fri, 11 Feb 2000 12:02: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 IAA13110; Fri, 11 Feb 2000 08:58:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA28430 for ietf-radius-outgoing; Fri, 11 Feb 2000 08:53:20 -0800 (PST) Message-Id: <4.2.2.20000211113132.042a9260@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 11 Feb 2000 11:49:51 -0500 To: mikko.alutoin@nokia.com, ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) Question about RADIUS terminology Cc: mikko.alutoin@nokia.com In-Reply-To: <11CD408013B6D2119BB50008C7EA510C0291482B@eseis05nok> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" At 04:22 PM 2/11/00 +0200, mikko.alutoin@nokia.com wrote: >Dear all, > >I have a question related to the RADIUS terminology. >What is the difference between proxy authentication >and pre-authentication when talking about querying >VPN tunnel attributes? > >Does proxy authentication mean that the first RADIUS >server (at the tunnel client endpoint) has all the >information needed to establish the tunnel and >the session, because its database is updated >periodicly by the RADIUS server at the tunnel >server endpoint? No. Typically a proxy server does not keep a database of authenticated sessions, except maybe in RAM for active tracking. In the case of roaming applications and broker proxies, it may track usage based on organization, but not the user's password. >And does the pre-authentication mean that the >first RADIUS server proxies the Access-Request >(which may contain either PPP user name + password >or just the dialed number as a user name with >some dummy password) to the RADIUS server at the >tunnel server endpoint, which then returns the >tunnel attributes in the Access-Accept with or >without checking the PPP password? Yes. >So what I'm trying to ask is that is the distinction >between the two terms: > >A) Whether the NAS at the tunnel client endpoint > fills the initial Access-Request with the > PPP user name + password or dialed number + dummy > password, in order to receive tunnel attributes. Yes, both implementations could exist depending on the requirements and capabilities of the NAS and it's tunneling service. >B) Whether the first RADIUS server needs to proxy the > Access-Request in order to receive the tunnel > attributes or not. It depends... If you read draft-ietf-radius-tunnel-imp-05.txt (soon to be an RFC) the authors lay out several alternatives. It's going to vary with your implementation. All of the implementations I'm familiar with, do NOT proxy, but instead pass tunnel server profile information back to the NAS. The NAS establishes the connection to the tunnel server, using whatever service authentication that tunnel protocol supports, and then typically the PPP authentication inside the tunnel service, authenticates the user to the AAA support behind the tunnel server. >C) Whether the PPP password is checked by the first > RADIUS server or not. Typically not. The point is that client end is offering an access service, that is dependent on the successful authentication at the server end. From a management standpoint, you don't want to be distributing your authentication information all over the network. That first RADIUS server, in outsourcing models, could be any old ma & pop ISP. >Best regards, >Mikko Alutoin >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 11 12:05:44 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 MAA14722 for ; Fri, 11 Feb 2000 12:05:41 -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 JAA13249; Fri, 11 Feb 2000 09:00:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA28913 for ietf-radius-outgoing; Fri, 11 Feb 2000 08:59:04 -0800 (PST) Message-Id: <4.2.2.20000211115028.042b02c0@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 11 Feb 2000 11:55:58 -0500 To: Barry James , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) User-Name with realms In-Reply-To: References: <979970074.950167742@[10.0.1.6]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" There is no standard that covers this behavior. Practically speaking, in my experience, you will want both behaviors depending on what the downstream RADIUS server needs. If it is hosting multiple realms, it may still want the information to differentiate the users itself. Recommendation: Make it an option. There is very little in the RADIUS RFCs & drafts that covers proxy operation. You may want to look at RoamOps RFCs and 2607 in particular. Dave. At 11:00 PM 2/10/00 +0000, Barry James wrote: >When a proxy RADIUS receives a User-Name attribute with a realm prefix or >suffix should it forward the request to the appropriate realm server with >the User-Name unmodified (ie still containing the realm information) or >should it strip the realm identifier and only send the username? Maybe I >missed it, but I didn't see any specific mention of this behavior in the >v2-03 draft. > >Thanks, >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. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Feb 13 00:12:50 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 AAA02307 for ; Sun, 13 Feb 2000 00:12:49 -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 VAA03205; Sat, 12 Feb 2000 21:10:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA00716 for ietf-radius-outgoing; Sat, 12 Feb 2000 21:07:32 -0800 (PST) Date: Sat, 12 Feb 2000 21:06:58 -0800 (PST) From: Carl Rigney Message-Id: <200002130506.VAA00704@server.livingston.com> To: randy@psg.com Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt Cc: ietf-radius@livingston.com, matt@ascend.com, wijnen@VNET.IBM.COM Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > 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. From owner-ietf-radius@livingston.com Tue Feb 15 20:42:59 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 UAA00197 for ; Tue, 15 Feb 2000 20:42: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 RAA21235; Tue, 15 Feb 2000 17:40:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA08701 for ietf-radius-outgoing; Tue, 15 Feb 2000 17:36:46 -0800 (PST) From: blanders@metaip.checkpoint.com Message-ID: To: ietf-radius@livingston.com Subject: (radius) IPv6? Date: Tue, 15 Feb 2000 17:20:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: blanders@metaip.checkpoint.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. From owner-ietf-radius@livingston.com Wed Feb 16 03:57:25 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 DAA20739 for ; Wed, 16 Feb 2000 03:57:14 -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 AAA25521; Wed, 16 Feb 2000 00:54:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id AAA19804 for ietf-radius-outgoing; Wed, 16 Feb 2000 00:53:47 -0800 (PST) From: "Bernard Aboba" To: , Subject: RE: (radius) IPv6? Date: Wed, 16 Feb 2000 00:52:05 -0800 Message-ID: <051301bf785b$1adc8580$2d8939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit IPv6 support is a requirement under consideration by the AAA WG. See http://www.drizzle.com/~aboba/AAA/REQTS/draft-ietf-aaa-na-reqts-02a.txt for details. -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of blanders@metaip.checkpoint.com Sent: Tuesday, February 15, 2000 5:21 PM To: ietf-radius@livingston.com Subject: (radius) IPv6? 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. From owner-ietf-radius@livingston.com Mon Feb 21 13:46:05 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 NAA14401 for ; Mon, 21 Feb 2000 13:46:05 -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 KAA22892; Mon, 21 Feb 2000 10:43:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA08047 for ietf-radius-outgoing; Mon, 21 Feb 2000 10:38:57 -0800 (PST) Message-ID: From: "Partington, Heath" To: "Ietf-Radius@Livingston. Com (E-mail)" Subject: (radius) Transport-Mode IPSec Date: Mon, 21 Feb 2000 13:37:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Partington, Heath" I have been trying to find out if anyone is doing any work with RADIUS accounting for IPSec connections in Transport-Mode. Two drafts "draft-ietf-radius-tunnel-acct-05.txt" and "draft-ietf-radius-tunnel-auth-09.txt" seem to handle RADIUS accounting for IPSec connections in Tunnel-mode as far as RADIUS acct-status types and appropriate attributes with appropriate values. I did notice a draft in the working group archives in November of 1997 called "draft-ietf-radius-ipsec-00.txt" which did have some additional attributes defined which may be helpful in the transport-mode case but it looks like the draft has pretty much disappeared over time. Since this draft uses standard attribute space numbers I don't want to start using them unless others are using them as well. Is everyone using proprietary methods to perform RADIUS accounting for transport-mode IPSec connections or is there some more standard way to do this? Thanks. Heath _________________ Heath Partington (978) 635-3739 x121 hpartington@springtidenet.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 22 16:29:42 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 QAA23792 for ; Tue, 22 Feb 2000 16:29: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 NAA15998; Tue, 22 Feb 2000 13:26:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA07881 for ietf-radius-outgoing; Tue, 22 Feb 2000 13:19:29 -0800 (PST) Message-ID: From: Brian Czako To: "'ietf-radius@livingston.com'" Subject: (radius) Shared secret questions Date: Tue, 22 Feb 2000 16:17:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Brian Czako I have a few questions regarding shared secrets. Hopefully, they haven't been discussed to death here. 1) Are shared secrets allowed to be updated dynamically, or is it required to restart both client and server for the change to take effect? 2) How have people resolved sync'ing up the client with the server in this case? 3) Must a shared secret be consistent within a call or can it change between, say, an Accounting-Start and Accounting-Stop packet? Non-shared secret questions 4) If a connection is lost to the RADIUS server and then later re-established, is there an Accounting-On packet required? 5) Should the "vendor length" value in vendor-specific attributes be clarified to say that it includes the 2 bytes corresponding to the "vendor type" and "vendor length" fields? Thanks in advance, Brian Czako - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 03:03:02 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 DAA16393 for ; Wed, 23 Feb 2000 03:03:01 -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 XAA25393; Tue, 22 Feb 2000 23:59:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id XAA01864 for ietf-radius-outgoing; Tue, 22 Feb 2000 23:58:00 -0800 (PST) From: "Bernard Aboba" To: "'Partington, Heath'" , "'Ietf-Radius@Livingston. Com \(E-mail\)'" Subject: RE: (radius) Transport-Mode IPSec Date: Tue, 22 Feb 2000 23:55:29 -0800 Message-ID: <007101bf7dd3$5b8e09f0$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit There are certainly accounting approaches that can be used to keep track of IPSEC transport mode packets sent/received (RTFM, IPSEC MIB, etc.). However, without a standardized keepalive, I would argue that it is not possible to accurately account for the lifetime of IPSEC SAs, in any mode with any protocol. -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of Partington, Heath Sent: Monday, February 21, 2000 10:37 AM To: Ietf-Radius@Livingston. Com (E-mail) Subject: (radius) Transport-Mode IPSec I have been trying to find out if anyone is doing any work with RADIUS accounting for IPSec connections in Transport-Mode. Two drafts "draft-ietf-radius-tunnel-acct-05.txt" and "draft-ietf-radius-tunnel-auth-09.txt" seem to handle RADIUS accounting for IPSec connections in Tunnel-mode as far as RADIUS acct-status types and appropriate attributes with appropriate values. I did notice a draft in the working group archives in November of 1997 called "draft-ietf-radius-ipsec-00.txt" which did have some additional attributes defined which may be helpful in the transport-mode case but it looks like the draft has pretty much disappeared over time. Since this draft uses standard attribute space numbers I don't want to start using them unless others are using them as well. Is everyone using proprietary methods to perform RADIUS accounting for transport-mode IPSec connections or is there some more standard way to do this? Thanks. Heath _________________ Heath Partington (978) 635-3739 x121 hpartington@springtidenet.com - 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 Wed Feb 23 11:05:21 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 LAA24724 for ; Wed, 23 Feb 2000 11:05: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 IAA29970; Wed, 23 Feb 2000 08:00:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA13118 for ietf-radius-outgoing; Wed, 23 Feb 2000 07:59:31 -0800 (PST) Message-Id: <4.2.2.20000223101458.00d31e90@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 23 Feb 2000 10:52:24 -0500 To: Brian Czako , "'ietf-radius@livingston.com'" From: "David Mitton" Subject: Re: (radius) Shared secret questions In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" At 04:17 PM 2/22/00 -0500, Brian Czako wrote: >I have a few questions regarding shared secrets. >Hopefully, they haven't been discussed to death here. > >1) Are shared secrets allowed to be updated dynamically, or >is it required to restart both client and server for the change to take >effect? Most people/implementations assume that shared secrets are "long lived" and NOT changed in real-time. Scanning RFC 2138, I do find [page 10] that the Request-Authenticator is supposed to be unique "over the lifetime of the secret". But that's the only mention of time. In any case the RFC says nothing about requirements to "restart" an implementation given a change. In practice, some do, some don't. Depends on their information update model. If changes are made, it's usually done to debug and converge on the correct configuration, which is then typically left static. >2) How have people resolved sync'ing up the client with the server in this >case? I'd be interested to hear from anyone that has attempted intentional dynamic changes. >3) Must a shared secret be consistent within a call or can it change >between, say, an Accounting-Start and Accounting-Stop packet? The RFC makes no requirements. >Non-shared secret questions >4) If a connection is lost to the RADIUS server and then later >re-established, is there an Accounting-On packet required? Not specified. We (Bay/Xylo/Annex/5399) used to do that, and it ran into problems with multi-pathed proxies to the same central server. We changed to only send Accounting-Ons at boot-up. >5) Should the "vendor length" value in vendor-specific attributes be >clarified to say that it includes the 2 bytes corresponding to the "vendor >type" and "vendor length" fields? I guess you could. But all other attribute lengths work this way, so it's assumed. >Thanks in advance, >Brian Czako > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 21:06:53 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 VAA06833 for ; Wed, 23 Feb 2000 21:06:52 -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 SAA12912; Wed, 23 Feb 2000 18:02:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA16557 for ietf-radius-outgoing; Wed, 23 Feb 2000 18:00:20 -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) Re: one iesger's review of draft-ietf-radius-radius-v2-04.txt Message-Id: Date: Wed, 23 Feb 2000 17:59:22 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit we will now get a tour through one of the iesg's fads of the season, character sets and representations. the least pain will be to o come up with specific and clear responses to the issues which are actually already covered but need to be explained to someone whose reading of the draft was for review purposes, i.e. they never have and never will use or implement radius. o for those issues which warrant document changes, make those changes once and well, and get this thing outta here. randy ------------ > String is also used in RADIUS to encode binary data, which does NOT use > UTF-8. Oh... > Operation of the RADIUS protocol itself does not depend on the > content of attribute fields whose codification is not specified. Where > the RADIUS protocol's operation does depend on the contents of a field, > the codification IS specified in the document. Does this mean that the attribute field is not used by the radius protocol itself, but it might be the case that the content of the field is passed through the layers which uses Radius, and in the end be displayed to a user? Either directly in a dialogue/error message or in a logfile? > If text is encoded, UTF-8 is supposed to be used, but various mays and > shoulds are there to reflect the reality that many RADIUS > implementations still use ASCII (a subset of UTF-8) and backwards > compatibility is useful for interoperability. Ok. Does this work in practice as one ISP (for example) or otherwise "island of Radius usage" checks and defines whether UTF-8 is in use or just ASCII? >> I think all of the issues can be solved by an introduction stating that >> every time the term "text" or "string" (or such) is used, UTF-8 encoded >> ISO 10646 MUST be used. > > It already states: > > Note that a "string" in RADIUS does not terminate with a NUL > (hex 00). The Attribute has a length field and does not use > a terminator. Strings may contain UTF-8 characters or 8-bit > binary data and servers and servers and clients MUST be able to deal > with embedded nulls. > > I can up that MAY to a MUST, but if I do, it should probably go back > to working group last call. Here "string" is defined but not "text", and other things which then should be "string", or? I.e. in the text below this definition of string, you use all different kind of terms, and maybe then all of them should be "string". Or, you should define "text" being a "string" which contains characters which should be UTF-8 encoded. The you can use string or text in the I-Ds for the two cases. >>> 4.3. Access-Reject >>> >>> Description >>> >>> If any value of the received Attributes is not acceptable, then >>> the RADIUS server MUST transmit a packet with the Code field set >>> to 3 (Access-Reject). It MAY include one or more Reply-Message >>> Attributes with a text message which the NAS MAY display to the >>> user. >> >> It "just" mentiones a "test message"... > > S/he seems to have misread "text message" as "test message"? No, I read the correct thing, but typed the wrong one :-) Issue is still there. What is a "text message"? Is that a "string" and therefore defined by the text above? >>> simple Consisting only of printable UTF-8 [6] characters. >> >> It is unclear to me what a "printable UTF-8" character is. > > I could remove "printable" and "displayable"; in practice most people > are using monolithic or network access identifiers, not simple, > anyway. Please let me know if that's what you want; I could turn > around that change in under an hour. I just want "simple" to be defined being something which is defined earlier in the document, or something which is defined in what you reference. [6] doesn't talk about "printable UTF-8 characters". Do you mean that "simple" is a subset of "string"? In that case, what differs a "string" from "simple"? >>> 5.30. Called-Station-Id >>> 5.31. Calling-Station-Id >>> The codification of the range of allowed usage of this field >>> is outside the scope of this specification. > >> Even more "confusing" for me :-) > > Since the contents of these fields depend on whatever the ISDN PRI or > equivalent sends to the NAS for these values, it would have to > reference ITU standards. We discussed detailing these in a working > group meeting, and it turns out that their codification is potentially > complex, but irrelevant to the operation of the RADIUS protocol itself, > which is just transporting the data for the benefit of the server. > > Note that of the hundreds of questions I've had emailed to me over the > years as Author, none have ever concerned these two attributes. So? What will you define the content being in these attributes? "string"? Same as above. I just want the I-D to use the same definitions in all places you talk about the same thing. >>> Strings should use UTF-8 instead of US-ASCII and should be handled as >>> 8-bit data. >> >> Is "should" enough as one go from 7 to 8 bits? I.e. two implementations >> can be completely incompatible if one doesn't support 8-bit data in >> textual strings, and I see in 2119 that one might have an implementation >> which is noy 8-bit clean for some weird reasons and still that is ok, or? > > If I increase should to MUST, I break most of the existing RADIUS > implementations, to what benefit? The point to the working group was > to document existing RADIUS servers, which used ASCII, and at the step > to proposed draft the IESG requested that we use UTF-8 instead of > ASCII, so it was added as should to indicate to implementers that they > should add support for UTF-8 but also be backwards compatible with > ASCII. If we now say ASCII should not be handled, we break "be > generous in what you accept", a cardinal virtue of internet protocols. Understood. Do you have multiple interoperable implementations of (client and server) radius which uses UTF-8? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 21:10:57 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 VAA06899 for ; Wed, 23 Feb 2000 21:10:56 -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 SAA12923; Wed, 23 Feb 2000 18:02:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA16684 for ietf-radius-outgoing; Wed, 23 Feb 2000 18:02:41 -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) Re: UTF-8 encoded 10646 or some other encoding? Message-Id: Date: Wed, 23 Feb 2000 18:01:46 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit a breakthrough! > what i am trying to understand is how much of this is relevant and > legitimate at this date and stage in the cycle of radius document > review. I am happy with his explanation, and only want the document to use the same term all over the place when he talks about the two things he is using: - string, which can be any set of octets 0-255 - text, which seems to be UTF-8 encoded 10646 I.e. just get rid of all talk about 'printable UTF-8' etc. Just say either "string" all over the place, or something else, like "text" which is a subset of "string". - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 21:21: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 VAA06982 for ; Wed, 23 Feb 2000 21:21:19 -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 SAA13281; Wed, 23 Feb 2000 18:13:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA17265 for ietf-radius-outgoing; Wed, 23 Feb 2000 18:12:52 -0800 (PST) Date: Wed, 23 Feb 2000 18:12:48 -0800 (PST) From: Carl Rigney Message-Id: <200002240212.SAA17257@server.livingston.com> To: randy@psg.com Subject: Re: (radius) Re: UTF-8 encoded 10646 or some other encoding? Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney OK. That seems very reasonable. So my plan is to use text for UTF-8 encoded 10646 and string for any set of octets 0-255, with text as a subset of string, and remove all the talk about printable and displayable? Its a fair bit of work to go through and change things to either text or string but straightforward; I can do these tonight and have an updated draft submitted in a few hours. I'll start that now. I assume they'll want the same change in accounting and extensions, but I'll do RADIUS first. >> what i am trying to understand is how much of this is relevant and >> legitimate at this date and stage in the cycle of radius document >> review. > >I am happy with his explanation, and only want the document to use the same >term all over the place when he talks about the two things he is using: > > - string, which can be any set of octets 0-255 > - text, which seems to be UTF-8 encoded 10646 > >I.e. just get rid of all talk about 'printable UTF-8' etc. Just say either >"string" all over the place, or something else, like "text" which is a >subset of "string". - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 21:24:06 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 VAA07014 for ; Wed, 23 Feb 2000 21:24:05 -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 SAA13467; Wed, 23 Feb 2000 18:16:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA17403 for ietf-radius-outgoing; Wed, 23 Feb 2000 18:15:50 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Carl Rigney Cc: ietf-radius@livingston.com Subject: Re: (radius) Re: UTF-8 encoded 10646 or some other encoding? References: <200002240212.SAA17257@server.livingston.com> Message-Id: Date: Wed, 23 Feb 2000 18:14:52 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > OK. That seems very reasonable. So my plan is to use text for UTF-8 > encoded 10646 and string for any set of octets 0-255, with text as a > subset of string, and remove all the talk about printable and displayable? > > Its a fair bit of work to go through and change things to either text > or string but straightforward; I can do these tonight and have an > updated draft submitted in a few hours. I'll start that now. I assume > they'll want the same change in accounting and extensions, but I'll do > RADIUS first. if there are no further issues by other iesg reviewers, no promises, that should put the lot to bed. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 23 22:42:51 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 WAA09740 for ; Wed, 23 Feb 2000 22:42:51 -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 TAA14611; Wed, 23 Feb 2000 19:37:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id TAA19853 for ietf-radius-outgoing; Wed, 23 Feb 2000 19:31:20 -0800 (PST) Date: Wed, 23 Feb 2000 19:31:17 -0800 (PST) From: Carl Rigney Message-Id: <200002240331.TAA19844@server.livingston.com> To: randy@psg.com, wijnen@VNET.IBM.COM Subject: (radius) Updated RADIUS drafts sent to internet-drafts Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The following three drafts have been submitted to internet-drafts, with the requested changes made clarifying usage of UTF-8. draft-ietf-radius-radius-v2-06.txt draft-ietf-radius-accounting-v2-05.txt draft-ietf-radius-ext-07.txt They are available now on ftp://ftp.livingston.com/pub/radius/ -- Carl Rigney RADIUS WG Chair - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 24 00:21:13 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 AAA11003 for ; Thu, 24 Feb 2000 00:21:12 -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 VAA15834; Wed, 23 Feb 2000 21:18:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA22645 for ietf-radius-outgoing; Wed, 23 Feb 2000 21:16:50 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Carl Rigney Cc: wijnen@VNET.IBM.COM, ietf-radius@livingston.com Subject: (radius) Re: Updated RADIUS drafts sent to internet-drafts References: <200002240331.TAA19844@server.livingston.com> Message-Id: Date: Wed, 23 Feb 2000 21:15:50 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit thank you! randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 24 11:05:18 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 LAA04046 for ; Thu, 24 Feb 2000 11:05:17 -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 HAA21450; Thu, 24 Feb 2000 07:58:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA07279 for ietf-radius-outgoing; Thu, 24 Feb 2000 07:57:50 -0800 (PST) Message-ID: From: Brian Czako To: "'ietf-radius@livingston.com'" Subject: RE: (radius) Shared secret questions Date: Thu, 24 Feb 2000 10:55:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Brian Czako > > 1) Are shared secrets allowed to be updated dynamically, or > > is it required to restart both client and server for the change to take > > effect? > > I believe this is implementation dependent and the RADIUS protocol doesn't > speak to it. > Well, if this is implementation dependent, is it reasonable to do the following: Provide a mechanism where both the old and new secrets are kept around for a configurable period of time. If a password decryption or packet authentication fails within this interval, the old secret is tried. The goal we're trying to reach is that no components need to ever be brought down and no calls are lost. Also, just how often are shared secrets being changed? Thanks, Brian - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 24 11:22:18 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 LAA04771 for ; Thu, 24 Feb 2000 11:22:17 -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 IAA22162; Thu, 24 Feb 2000 08:17:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA08296 for ietf-radius-outgoing; Thu, 24 Feb 2000 08:18:42 -0800 (PST) Message-Id: <200002241616.LAA28877@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: Brian Czako cc: "'ietf-radius@livingston.com'" Subject: Re: (radius) Shared secret questions In-Reply-To: Message from Brian Czako of "Thu, 24 Feb 2000 10:55:02 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Feb 2000 11:16:29 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson % % > > 1) Are shared secrets allowed to be updated dynamically, or % > > is it required to restart both client and server for the change to take % > > effect? % > % > I believe this is implementation dependent and the RADIUS protocol doesn't % > speak to it. % > % Well, if this is implementation dependent, is it reasonable to do % the following: % Provide a mechanism where both the old and new secrets are kept % around for a configurable period of time. % If a password decryption or packet authentication fails within this % interval, the old secret is tried. You are trying to come up with a kind of simple key management scheme. While this is a fine goal, it is outside the scope of this (soon to disappear) WG because the WG charter is limited to documenting the existing deployed practice. % The goal we're trying to reach is that no components need to ever be % brought down and no calls are lost. % % Also, just how often are shared secrets being changed? In practice, I've never heard of anyone ever changing the "shared secret" anyplace once it was initially deployed. The RADIUS specifications are silent on how shared secrets would ever be updated. They don't prohibit it, but they also do not specify how it is done. Regards, Ran rja@corp.home.net NB: @Home doesn't actually use RADIUS for anything, so comments about observed use necessarily are based on data outside @Home. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 24 12:57:55 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 MAA07350 for ; Thu, 24 Feb 2000 12:57:54 -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 JAA24548; Thu, 24 Feb 2000 09:54:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA13889 for ietf-radius-outgoing; Thu, 24 Feb 2000 09:55:54 -0800 (PST) X-Authentication-Warning: hme0.s0092.idc1.oss.level3.com: bjames owned process doing -bs Date: Thu, 24 Feb 2000 10:51:16 -0700 (MST) From: Barry L James X-Sender: bjames@hme0.s0092.idc1.oss.level3.com To: ietf-radius@livingston.com Subject: (radius) 2-04 typo 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 fyi.. On page 67 of 2-04 doc, the second "[Note 1]" should read "[Note 2]" -blj 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 Thu Feb 24 13:03:37 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 NAA07507 for ; Thu, 24 Feb 2000 13:03:35 -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 JAA24553; Thu, 24 Feb 2000 09:54:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA13846 for ietf-radius-outgoing; Thu, 24 Feb 2000 09:55:14 -0800 (PST) X-Authentication-Warning: hme0.s0092.idc1.oss.level3.com: bjames owned process doing -bs Date: Thu, 24 Feb 2000 10:50:36 -0700 (MST) From: Barry L James X-Sender: bjames@hme0.s0092.idc1.oss.level3.com To: ietf-radius@livingston.com Subject: (radius) Re: Shared secrets 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 (my mail system bounced these messages last night, so...) Hi Brian, > 1) Are shared secrets allowed to be updated dynamically, or > is it required to restart both client and server for the change to take > effect? I believe this is implementation dependent and the RADIUS protocol doesn't speak to it. > 3) Must a shared secret be consistent within a call or can it change > between, say, an > Accounting-Start and Accounting-Stop packet? Since the spec doesn't require that the secret last throughout the entire session (as opposed to req/res transactional pairs) I don't think there would be a problem with the accounting portion. It might be alittle trickier for the access piece as you may need to keep the previous secret for any pending access-requests that may be queued up to be processed. > Non-shared secret questions > 4) If a connection is lost to the RADIUS server and then later > re-established, > is there an Accounting-On packet required? The RFC doesn't state that an Accounting-On ever has to be sent, but most NAS gear I've worked with only send Accounting-On's at bootup. Regards, Barry > > Thanks in advance, > Brian Czako > > 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 Thu Feb 24 13:12:48 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 NAA07720 for ; Thu, 24 Feb 2000 13:12:43 -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 KAA25196; Thu, 24 Feb 2000 10:09:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA15073 for ietf-radius-outgoing; Thu, 24 Feb 2000 10:11:16 -0800 (PST) X-Authentication-Warning: hme0.s0092.idc1.oss.level3.com: bjames owned process doing -bs Date: Thu, 24 Feb 2000 11:06:35 -0700 (MST) From: Barry L James X-Sender: bjames@hme0.s0092.idc1.oss.level3.com To: Brian Czako cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) Shared secret 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 Hey Brian, On Thu, 24 Feb 2000, Brian Czako wrote: > Well, if this is implementation dependent, is it reasonable to do > the following: > Provide a mechanism where both the old and new secrets are kept > around for a configurable period of time. > If a password decryption or packet authentication fails within this > interval, the old secret is tried. It seems to make sense to have some configurable value that would allow you to keep your old password for a short period of time (like an ACE server that still lets you login even if your token # changes while you're waiting for authentication). Or, maybe the client may send some semantic value in an attribute that will allow the server to know which secret (or permutation) was used with the packet. Kind of like the serial number in DNS; each change of secret increments this serial and the serial may be passed in some attribute (maybe State) to the server. Again, the RFC wouldn't necessarily specify how this would be accomplished, but leaves the option open to the implementor. > The goal we're trying to reach is that no components need to ever be > brought down and no calls are lost. You're also getting into the realm of redundancy and high-availability here. > Also, just how often are shared secrets being changed? Often enough that the change increases the expense of hijacking a session, yet seldom enough that the computational complexity and expense of managing numerous valid secrets doesn't adversely affect the operation of your AAA infrastructure, I'd think. Regards, Barry > > Thanks, > Brian > > > > > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > 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 Fri Feb 25 00:20:02 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 AAA19238 for ; Fri, 25 Feb 2000 00:20:02 -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 VAA08799; Thu, 24 Feb 2000 21:14:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA20997 for ietf-radius-outgoing; Thu, 24 Feb 2000 21:12:09 -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) Re: one iesger's review of draft-ietf-radius-radius-v2-04.txt Message-Id: Date: Thu, 24 Feb 2000 21:09:58 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > please check the new versions just checked in > > ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-radius-v2-06.txt > ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-accounting-v2-05.txt > ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-07.txt > > or i suspect that they will be in the i-d directory in the (est) morning. I am VERY happy with the changes. Now, do we have multiple implementations which can handle UTF-8 text in attributes? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 25 00:24:08 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 AAA19335 for ; Fri, 25 Feb 2000 00:24:06 -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 VAA08977; Thu, 24 Feb 2000 21:21:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA21281 for ietf-radius-outgoing; Thu, 24 Feb 2000 21:21:32 -0800 (PST) Date: Thu, 24 Feb 2000 21:21:29 -0800 (PST) From: Carl Rigney Message-Id: <200002250521.VAA21267@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Interoperable UTF-8 in RADIUS? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney ATTENTION list members! Anyone whose implementation of RADIUS supports UTF-8, please speak up now, whether client or server. We need to know so RADIUS can advance to Draft Standard. Email either the list or me. And if your implementation does not support UTF-8, send me email. -- Carl Rigney RADIUS WG Chair 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 Fri Feb 25 18:12:48 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 SAA23019 for ; Fri, 25 Feb 2000 18:12:47 -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 PAA23705; Fri, 25 Feb 2000 15:09:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA29777 for ietf-radius-outgoing; Fri, 25 Feb 2000 15:10:11 -0800 (PST) Message-ID: <9A9367D1556AD21182C40000F80930AB01FA229D@crchy28b.us.nortel.com> From: "Gokul Subramaniam" To: ietf-radius@livingston.com Subject: (radius) RADIUS tunnel-auth-09 Comment Date: Fri, 25 Feb 2000 16:55:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7FE3.672CB470" X-Orig: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Gokul Subramaniam" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7FE3.672CB470 Content-Type: text/plain Hello., With the increased use of L2TP over IPSec to address the VPN scenarios and deployments, there are some limitations in the use of RADIUS Attributes for Tunnel Support. NAS can communicate with the remote RADIUS Server during user authentication (using Access Req/Accept) messages and in the process get the tunnel server endpoint address and tunnel type (example value: tunnel type=3 L2TP). However, there is no option to differentiate between L2TP and L2TP over IPSec. It would be easier from a NAS stand-point to get this information from the remote radius server in the access accept message. in order to do this the draft should support a value for L2TP over IPSec. The rationale for doing this in the RADIUS message is due to the increased use of VPNs to access private and corporate networks. Along with the enhancement of supporting a new value for tunnel-type, it would also be essential to define a new attribute for the shared key to start IKE between the tunnel initiator and the tunnel terminator. The value of being able to do this via RADIUS authentication messages helps the NAS to learn about the necessary remote network tunneling security requirements (if this network is private or corporate or example). This way a separate or proprietry message/vendor-specific messages need not be sent to support L2TP over IPSec. Suggestions to enhance the draft are: Add new tunnel-type value. Value 13 - L2TP over IPSec Add new attribute: Shared Key. This way once authentication is done the NAS would have all the information needed to start either L2TP or L2TP over IPSec (besides all the other tunnel options). If a new attribute for Shared Key is not added into the draft then option would be to override the Tunnel-Password parameter to pass the shared key. Since doing L2TP tunnel authentication is redundant if there is anyway going to be L2TP over IPSec. So whenever the tunnel-type value is 13, then the Tunnel Password will carry the shared key for L2TP over IPSec. Suggest me if there are anyother ways to handle the above mentioned scenario. Your feedback is appreciated. -Gokul Gokul V. Subramaniam NORTEL Networks CDMA Wireless Data Development email:gokuls@nortelnetworks.com Ph:972 685 8214. ESN:445 8214 ------_=_NextPart_001_01BF7FE3.672CB470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RADIUS tunnel-auth-09 Comment

Hello.,

With the increased use of L2TP over = IPSec to address the VPN scenarios and deployments, there are some = limitations in the use of RADIUS Attributes for Tunnel = Support<draft-ietf-radius-tunnel-auth-09.txt>.

NAS can communicate with the remote = RADIUS Server during user authentication (using Access = Req/Accept)
messages and in the process get the = tunnel server endpoint address and tunnel type (example value: tunnel = type=3D3 L2TP).
However, there is no option to = differentiate between L2TP and L2TP over IPSec.
It would be easier from a NAS = stand-point to get this information from the remote radius server in = the access accept message.

in order to do this the draft should = support a value for L2TP over IPSec.
The rationale for doing this in the = RADIUS message is due to the increased use of VPNs to access private = and corporate networks. Along with the enhancement of supporting a new = value for tunnel-type, it would also be essential to define a new = attribute for the shared key to start IKE between the tunnel initiator = and the tunnel terminator.

The value of being able to do this via = RADIUS authentication messages helps the NAS to learn about the = necessary remote network tunneling security requirements (if this = network is private or corporate or example). This way a separate or = proprietry message/vendor-specific messages need not be sent to support = L2TP over IPSec.

Suggestions to enhance the draft = are:
Add new tunnel-type value.
Value 13 - L2TP over IPSec

Add new attribute:
Shared Key.

This way once authentication is done = the NAS would have all the information needed to start either L2TP or = L2TP over IPSec (besides all the other tunnel options).

If a new attribute for Shared Key is = not added into the draft then option would be to override the = Tunnel-Password parameter to pass the shared key. Since doing L2TP = tunnel authentication is redundant if there is anyway going to be L2TP = over IPSec.

So whenever the tunnel-type value is = 13, then the Tunnel Password will carry the shared key for L2TP over = IPSec.

Suggest me if there are anyother ways = to handle the above mentioned scenario.
Your feedback is appreciated.

-Gokul

Gokul V. = Subramaniam          =
NORTEL = Networks
CDMA = Wireless Data Development
email:gokuls@nortelnetworks.com
Ph:972 = 685 8214. ESN:445 8214


------_=_NextPart_001_01BF7FE3.672CB470-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 29 21:29:41 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 VAA06672 for ; Tue, 29 Feb 2000 21:29:40 -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 SAA24264; Tue, 29 Feb 2000 18:26:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA13410 for ietf-radius-outgoing; Tue, 29 Feb 2000 18:26:38 -0800 (PST) Message-ID: <38BC7E07.B49906C0@asiapacificm01.nt.com> Date: Wed, 01 Mar 2000 02:18:47 +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: ietf-radius@livingston.com Subject: (radius) interim-update accounting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Andrew Morton" Content-Transfer-Encoding: 7bit [ 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. 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. 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.