From owner-ietf-radius@livingston.com Thu Dec 2 11:35:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13939 for ; Thu, 2 Dec 1999 11:35: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 IAA24478; Thu, 2 Dec 1999 08:23:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA11275 for ietf-radius-outgoing; Thu, 2 Dec 1999 08:19:43 -0800 (PST) Message-ID: From: "Gallagher, Mick" To: "'ietf-radius@livingston.com'" Subject: (radius) RADIUS secure for both call directions?? Date: Thu, 2 Dec 1999 16:18:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Gallagher, Mick" Dear All, I have a question regarding RADIUS use and security. Please indulge me if my question appears so obviously misinformed. I'm currently looking at setting up a RADIUS client, and wonder what attributes I must support in order to facilitate CHAP security. I expected to find some sort of attribute that would indicate the direction of the call, so that a RADIUS server could use a call-direction specific CHAP secret to evaluate the peer challenge-response; but I cannot find any. Possible conclusions are: (a) I have not read the RFC properly (b) Call-direction specific CHAP secrets are not supported because it was missed (which I doubt) (c) Call-direction specific CHAP secrets are not supported because RADIUS is only designed to support authentication for incoming calls, not outgoing calls. (But if this is true, then this suggest that RAS boxes must store all dial-out user authentication information locally). Any guidance gratefully received. Best regards, Mick Gallagher - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 2 12:24:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08717 for ; Thu, 2 Dec 1999 12:24: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 JAA25800; Thu, 2 Dec 1999 09:17:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA14891 for ietf-radius-outgoing; Thu, 2 Dec 1999 09:19:43 -0800 (PST) Message-ID: From: "Gallagher, Mick" To: "'ietf-radius@livingston.com'" Cc: "'Nelson, David'" Subject: RE: (radius) RADIUS secure for both call directions?? Date: Thu, 2 Dec 1999 17:18:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Gallagher, Mick" Dave, Thanks for that. Your notion certainly rocks my view of the authenticating world. And so, just to complete my obviously warped picture.... If RADIUS authentication really is just for dial-in, then can I presume that RADIUS accounting has no way of centralising dial-out call information either? I would have supposed that centralised storage of such information (advice of charge, for example) would be extremely valuable for outgoing calls. Or does another scheme exist for this? RADOUS, perhaps? ;-) Regards, Mick > -----Original Message----- > From: Nelson, David [SMTP:dnelson@cabletron.com] > Sent: Thursday, December 02, 1999 4:41 PM > To: 'Gallagher, Mick'; 'ietf-radius@livingston.com' > Subject: RE: (radius) RADIUS secure for both call directions?? > > Mick Gallagher writes... > > >(c) Call-direction specific CHAP secrets are not supported because RADIUS > is > >only designed to support authentication for incoming calls, not outgoing > >calls. > > Bingo! Remember, RADIUS stands for Remote Access Dial In User Service. > Emphasis on the "Dial In". > > Regards, > > Dave > > David B. Nelson Cabletron Systems, Inc. > Software Engineer V 50 Minuteman Road > (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 2 17:59:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24488 for ; Thu, 2 Dec 1999 17:59:21 -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 OAA04180; Thu, 2 Dec 1999 14:47:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA06313 for ietf-radius-outgoing; Thu, 2 Dec 1999 14:48:40 -0800 (PST) Date: Thu, 2 Dec 1999 14:48:38 -0800 (PST) From: Carl Rigney Message-Id: <199912022248.OAA06305@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The Implementation Survey and IANA Considerations documents are at last done and the six RADIUS Drafts are now off to IETF Last Call or IESG approval, as appropriate. -- Carl Rigney cdr@livingston.com IETF RADIUS WG Chair To: randy@psg.com wijnen@VNET.IBM.COM Subject: 6 RADIUS Drafts ready for IESG action Cc: iesg-secretary@ietf.org The following 3 drafts have been updated and submitted to internet-drafts. Once they've been copied into the usual directories everything is ready to move forward. draft-ietf-radius-accounting-v2-02.txt draft-ietf-radius-ext-05.txt draft-ietf-radius-radius-v2-02.txt All six of the following drafts have undergone RADIUS Working Group Last Call and are ready for IESG action as follows: draft-ietf-radius-radius-v2-02.txt is ready for IETF Last Call for advancement to Draft Standard, superceding RFC 2138. It now contains an IANA Considerations section providing guidance on allocating values. The (rather large) report on Independent Interoperable implementations is available at ftp://ftp.livingston.com/pub/radius/interop.report draft-ietf-radius-tunnel-auth-09.txt is ready for IETF Last Call for advancement to Proposed Standard. draft-ietf-radius-accounting-v2-02.txt is ready for IESG approval to be issued as an informational RFC superceding RFC 2139. draft-ietf-radius-ext-05.txt draft-ietf-radius-tunnel-acct-05.txt draft-ietf-radius-tunnel-imp-05.txt are all ready for IESG approval to be issued as informational RFCs. (If you want to do an IETF Last Call for all 6 documents, I have no objection to that.) That's all the documents in the RADIUS WG pipeline. If you have any questions or any changes are needed please let me know by email or phone. -- Carl Rigney cdr@livingston.com 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 Fri Dec 3 11:16:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14084 for ; Fri, 3 Dec 1999 11:16: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 IAA18406; Fri, 3 Dec 1999 08:08:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA11639 for ietf-radius-outgoing; Fri, 3 Dec 1999 08:09:46 -0800 (PST) Date: Fri, 3 Dec 1999 08:09:20 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call To: Carl Rigney Cc: ietf-radius@livingston.com In-Reply-To: "Your message with ID" <199912022248.OAA06305@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" All, Having looked at the Interoperability report, I would like to ask how many people have *actually* implemented and interoperated on the v2 draft? I do not know of any, but I have been out of the loop for a little while. Specifically, the v2 draft includes lots of protocol changes, and section 2.3 includes many new concepts that were not present in RFC 2138, some of which is questionable how well they would work in a large network (i.e. Internet). PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 3 12:29:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21094 for ; Fri, 3 Dec 1999 12:29:32 -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 JAA20036; Fri, 3 Dec 1999 09:23:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA15822 for ietf-radius-outgoing; Fri, 3 Dec 1999 09:23:22 -0800 (PST) Date: Fri, 3 Dec 1999 09:23:18 -0800 (PST) From: Carl Rigney Message-Id: <199912031723.JAA15806@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call Cc: Pat.Calhoun@eng.sun.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Actually, the v2 draft doesn't include any Protocol changes; it just clarifies and explains proxy better, and adds a few values, and improves the examples. Its not really even v2; that's just the naming convention the Internet Drafts directory wanted to use for the advance from proposed to draft standard. Everything in the draft showed good interoperability at the Washington Bake-off two years ago. Some people implemented Proxy incorrectly, but everyone who implemented it according to the spec interoperated. Note that the interoperability report includes some features added in the extensions draft, which is on an informational track, not standards, primarily for LAT and Appletalk support, which many NAS vendors aren't going to be doing. Are there any specific items that you're concerned about? -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 6 10:44:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11226 for ; Mon, 6 Dec 1999 10:44: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 HAA24246; Mon, 6 Dec 1999 07:34:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA24537 for ietf-radius-outgoing; Mon, 6 Dec 1999 07:31:15 -0800 (PST) Date: Mon, 6 Dec 1999 07:31:01 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call To: Carl Rigney Cc: ietf-radius@livingston.com, Pat.Calhoun@eng.sun.com In-Reply-To: "Your message with ID" <199912031723.JAA15806@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" > Actually, the v2 draft doesn't include any Protocol changes; it just > clarifies and explains proxy better, and adds a few values, and improves > the examples. > > Its not really even v2; that's just the naming convention the Internet > Drafts directory wanted to use for the advance from proposed to draft > standard. > > Everything in the draft showed good interoperability at the Washington > Bake-off two years ago. Some people implemented Proxy incorrectly, > but everyone who implemented it according to the spec interoperated. > > Note that the interoperability report includes some features added > in the extensions draft, which is on an informational track, not > standards, primarily for LAT and Appletalk support, which many NAS > vendors aren't going to be doing. > > Are there any specific items that you're concerned about? actually, the following really scares me (I've sent an e-mail some time back in regards to this particular item): " A forwarding server may either perform its forwarding function in a pass through manner, where it sends retransmissions on as soon as it gets them, or it may take responsibility for retransmissions, for example in cases where the network link between forwarding and remote server has very different characteristics than the link between NAS and forwarding server. Extreme care should be used when implementing a proxy server that takes responsibility for retransmissions so that its retransmission policy is robust and scalable." This defines a new type of proxy that wasn't supported (as far as I can tell) in RFC2138. Here are my issues: 1. How does the server *know* the network link characteristics. Furthermore, The difference in link speed may be a few hops away, and the protocol doesn't provide any round trip calculation which makes this *nearly* impossible. Furthermore, given the nature of the RADIUS protocol, I really don't see how one *could* really determine the round trip time in a proxy environment. 2. The lack of retransmission logic in the protocol is just another way for people to do Really Bad Implementations (TM), which will hamper the network. The DHCP people had to remove their text from their I-D at the request of the IESG, and theirs was much better defined than this draft. 3. The fact that each RADIUS node in the chain MAY/WILL retransmit, how does one syncronize the events? 4. Certain attributes in the RADIUS protocol must be updated prior to retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST be updated each time something within the packet must be updated. So, who updates these attributes, and how is the identifier field maintained. 5. The warning above makes it clear that even the authors of the I-D think this is a pretty dangerous area. So, why leave it in the draft? So, the above rambling are just some things that come to mind. I have a really really hard time with leaving the text in the draft. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 6 12:25:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17102 for ; Mon, 6 Dec 1999 12:25:09 -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 JAA26030; Mon, 6 Dec 1999 09:19:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA29579 for ietf-radius-outgoing; Mon, 6 Dec 1999 09:21:36 -0800 (PST) Date: Mon, 6 Dec 1999 09:21:05 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call To: Matt Holdrege Cc: "pcalhoun@eng.sun.com" , Carl Rigney , ietf-radius@livingston.com In-Reply-To: "Your message with ID" <4.2.2.19991206090714.00aecab0@porky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" Matt, I agree that we owe it to the community, but this *particular* change in the new draft really concerns me. I would like to see it taken out of the draft, before it is moved to last call. I really don't think that the new sentence adds ANY benefit, in fact it simply casts a shadow of doubt on how proxies really should work. As you say, servers do it today, and they follow RFC2138. So remove the two paragraphs, and let servers do what they want. It really isn't as if the draft proposes HOW a server can do it, so what *is* the benefit of having these two paragraphs? PatC > Pat, > > You know as well (or better) as the rest of us about the limitations of > RADIUS in a proxy environment. But nevertheless, a great many SP's are > using it in a proxy environment and have been for some time. The protocol > described in RFC 2138 has been applied to many scenarios that were never > considered at the time it originally was approved by the WG and one of them > is proxy. > > It does no good (IMHO) to worry about whether RFC 2138 allowed it or not, > because RADIUS server vendors made it work anyway. Going to Draft Standard > means that a lot of people are using the protocol and it is good to > document the protocol as used. RADIUS is what it is. > > I think the current draft that is in last call now is fine and we have > enough disclaimers in the text. We also have the ROAMOPS RFC's. > > Let's put RADIUS to bed. We owe it to the community. > > > > At 07:31 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: > > > Actually, the v2 draft doesn't include any Protocol changes; it just > > > clarifies and explains proxy better, and adds a few values, and improves > > > the examples. > > > > > > Its not really even v2; that's just the naming convention the Internet > > > Drafts directory wanted to use for the advance from proposed to draft > > > standard. > > > > > > Everything in the draft showed good interoperability at the Washington > > > Bake-off two years ago. Some people implemented Proxy incorrectly, > > > but everyone who implemented it according to the spec interoperated. > > > > > > Note that the interoperability report includes some features added > > > in the extensions draft, which is on an informational track, not > > > standards, primarily for LAT and Appletalk support, which many NAS > > > vendors aren't going to be doing. > > > > > > Are there any specific items that you're concerned about? > > > >actually, the following really scares me (I've sent an e-mail some time back > >in regards to this particular item): > > >" A forwarding server may either perform its forwarding function in a > > pass through manner, where it sends retransmissions on as soon as it > > gets them, or it may take responsibility for retransmissions, for > > example in cases where the network link between forwarding and remote > > server has very different characteristics than the link between NAS > > and forwarding server. > > > > Extreme care should be used when implementing a proxy server that > > takes responsibility for retransmissions so that its retransmission > > policy is robust and scalable." > > > >This defines a new type of proxy that wasn't supported (as far as I can > tell) >in RFC2138. Here are my issues: > > > >1. How does the server *know* the network link characteristics. Furthermore, > >The difference in link speed may be a few hops away, and the protocol > doesn't >provide any round trip calculation which makes this *nearly* > impossible. >Furthermore, given the nature of the RADIUS protocol, I really > don't see how >one *could* really determine the round trip time in a proxy > environment. > > >2. The lack of retransmission logic in the protocol is just another way for > >people to do Really Bad Implementations (TM), which will hamper the network. > >The DHCP people had to remove their text from their I-D at the request of > the >IESG, and theirs was much better defined than this draft. > > > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, how does > >one syncronize the events? > > >4. Certain attributes in the RADIUS protocol must be updated prior to > >retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST > be >updated each time something within the packet must be updated. So, who > updates >these attributes, and how is the identifier field maintained. > > > >5. The warning above makes it clear that even the authors of the I-D think > >this is a pretty dangerous area. So, why leave it in the draft? > > > >So, the above rambling are just some things that come to mind. I have a > really >really hard time with leaving the text in the draft. > > > >PatC > > > >- > >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 Dec 6 12:26:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17783 for ; Mon, 6 Dec 1999 12:26: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 JAA25829; Mon, 6 Dec 1999 09:12:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA29132 for ietf-radius-outgoing; Mon, 6 Dec 1999 09:14:11 -0800 (PST) Message-Id: <4.2.2.19991206090714.00aecab0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 06 Dec 1999 09:16:04 -0800 To: "pcalhoun@eng.sun.com" From: Matt Holdrege Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call Cc: Carl Rigney , ietf-radius@livingston.com In-Reply-To: References: <"Your message with ID" <199912031723.JAA15806@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege Pat, You know as well (or better) as the rest of us about the limitations of RADIUS in a proxy environment. But nevertheless, a great many SP's are using it in a proxy environment and have been for some time. The protocol described in RFC 2138 has been applied to many scenarios that were never considered at the time it originally was approved by the WG and one of them is proxy. It does no good (IMHO) to worry about whether RFC 2138 allowed it or not, because RADIUS server vendors made it work anyway. Going to Draft Standard means that a lot of people are using the protocol and it is good to document the protocol as used. RADIUS is what it is. I think the current draft that is in last call now is fine and we have enough disclaimers in the text. We also have the ROAMOPS RFC's. Let's put RADIUS to bed. We owe it to the community. At 07:31 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: > > Actually, the v2 draft doesn't include any Protocol changes; it just > > clarifies and explains proxy better, and adds a few values, and improves > > the examples. > > > > Its not really even v2; that's just the naming convention the Internet > > Drafts directory wanted to use for the advance from proposed to draft > > standard. > > > > Everything in the draft showed good interoperability at the Washington > > Bake-off two years ago. Some people implemented Proxy incorrectly, > > but everyone who implemented it according to the spec interoperated. > > > > Note that the interoperability report includes some features added > > in the extensions draft, which is on an informational track, not > > standards, primarily for LAT and Appletalk support, which many NAS > > vendors aren't going to be doing. > > > > Are there any specific items that you're concerned about? > >actually, the following really scares me (I've sent an e-mail some time back >in regards to this particular item): > >" A forwarding server may either perform its forwarding function in a > pass through manner, where it sends retransmissions on as soon as it > gets them, or it may take responsibility for retransmissions, for > example in cases where the network link between forwarding and remote > server has very different characteristics than the link between NAS > and forwarding server. > > Extreme care should be used when implementing a proxy server that > takes responsibility for retransmissions so that its retransmission > policy is robust and scalable." > >This defines a new type of proxy that wasn't supported (as far as I can tell) >in RFC2138. Here are my issues: > >1. How does the server *know* the network link characteristics. Furthermore, >The difference in link speed may be a few hops away, and the protocol doesn't >provide any round trip calculation which makes this *nearly* impossible. >Furthermore, given the nature of the RADIUS protocol, I really don't see how >one *could* really determine the round trip time in a proxy environment. > >2. The lack of retransmission logic in the protocol is just another way for >people to do Really Bad Implementations (TM), which will hamper the network. >The DHCP people had to remove their text from their I-D at the request of the >IESG, and theirs was much better defined than this draft. > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, how does >one syncronize the events? > >4. Certain attributes in the RADIUS protocol must be updated prior to >retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST be >updated each time something within the packet must be updated. So, who updates >these attributes, and how is the identifier field maintained. > >5. The warning above makes it clear that even the authors of the I-D think >this is a pretty dangerous area. So, why leave it in the draft? > >So, the above rambling are just some things that come to mind. I have a really >really hard time with leaving the text in the draft. > >PatC > >- >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 Dec 6 18:33:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06280 for ; Mon, 6 Dec 1999 18:33: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 PAA03677; Mon, 6 Dec 1999 15:26:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA22494 for ietf-radius-outgoing; Mon, 6 Dec 1999 15:28:05 -0800 (PST) Date: Mon, 6 Dec 1999 15:27:59 -0800 (PST) From: Carl Rigney Message-Id: <199912062327.PAA22487@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Proxy Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I'm interested in hearing from people who've actually implemented Proxy RADIUS or have operational experience with it. Was the language in the current draft (which passed working group last call in May with no objections then) useful to you? Can you make concrete suggestions as to how to make it more useful to future implementers? Have people found any interoperability problems other than just cases where other implementers didn't implement proxy or deliberately ignored the way it's documented to work? Having implemented proxy support myself, in Livingston's RADIUS server 2.1, the current text captures the best state of my knowledge as to the things to best look out for. As for forwarding servers manipulating the contents of access-accepts, I recall us hashing that out at length nearly a year ago, and reaching consensus that implementations WERE going to do it, so we might as well make implementers aware that that sort of thing might happen. -- 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 Mon Dec 6 20:55:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10874 for ; Mon, 6 Dec 1999 20:55: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 RAA06800; Mon, 6 Dec 1999 17:37:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA04800 for ietf-radius-outgoing; Mon, 6 Dec 1999 17:39:09 -0800 (PST) Message-Id: <4.2.2.19991206173624.00a8a460@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 06 Dec 1999 17:41:01 -0800 To: "pcalhoun@eng.sun.com" From: Matt Holdrege Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call Cc: cdr@livingston.com, ietf-radius@livingston.com In-Reply-To: References: <"Your message with ID" <4.2.2.19991206090714.00aecab0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege If RADIUS were a new protocol that we had just churned out of an active working group, I would agree with you. But we are simply documenting something from a nearly dead working group that very much needs documenting. So I would turn your argument around and say, "what harm is it to leave those two paragraphs in?" We aren't trying to describe anything new. The harm in trying to remove it is that we may have to go to WG last call again and delay the whole process. I don't think there is enough harm here to do that. At 09:21 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: >Matt, > >I agree that we owe it to the community, but this *particular* change in the >new draft really concerns me. I would like to see it taken out of the draft, >before it is moved to last call. I really don't think that the new sentence >adds ANY benefit, in fact it simply casts a shadow of doubt on how proxies >really should work. > >As you say, servers do it today, and they follow RFC2138. So remove the two >paragraphs, and let servers do what they want. It really isn't as if the draft >proposes HOW a server can do it, so what *is* the benefit of having these two >paragraphs? > >PatC > > > Pat, > > > > You know as well (or better) as the rest of us about the limitations of > > RADIUS in a proxy environment. But nevertheless, a great many SP's are > > using it in a proxy environment and have been for some time. The protocol > > described in RFC 2138 has been applied to many scenarios that were never > > considered at the time it originally was approved by the WG and one of > them > > is proxy. > > > > It does no good (IMHO) to worry about whether RFC 2138 allowed it or not, > > because RADIUS server vendors made it work anyway. Going to Draft Standard > > means that a lot of people are using the protocol and it is good to > > document the protocol as used. RADIUS is what it is. > > > > I think the current draft that is in last call now is fine and we have > > enough disclaimers in the text. We also have the ROAMOPS RFC's. > > > > Let's put RADIUS to bed. We owe it to the community. > > > > > > > > At 07:31 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: > > > > Actually, the v2 draft doesn't include any Protocol changes; it just > > > > clarifies and explains proxy better, and adds a few values, and > improves > > > > the examples. > > > > > > > > Its not really even v2; that's just the naming convention the Internet > > > > Drafts directory wanted to use for the advance from proposed to draft > > > > standard. > > > > > > > > Everything in the draft showed good interoperability at the Washington > > > > Bake-off two years ago. Some people implemented Proxy incorrectly, > > > > but everyone who implemented it according to the spec interoperated. > > > > > > > > Note that the interoperability report includes some features added > > > > in the extensions draft, which is on an informational track, not > > > > standards, primarily for LAT and Appletalk support, which many NAS > > > > vendors aren't going to be doing. > > > > > > > > Are there any specific items that you're concerned about? > > > > > >actually, the following really scares me (I've sent an e-mail some > time back > > >in regards to this particular item): > > > >" A forwarding server may either perform its forwarding function in a > > > pass through manner, where it sends retransmissions on as soon as it > > > gets them, or it may take responsibility for retransmissions, for > > > example in cases where the network link between forwarding and remote > > > server has very different characteristics than the link between NAS > > > and forwarding server. > > > > > > Extreme care should be used when implementing a proxy server that > > > takes responsibility for retransmissions so that its retransmission > > > policy is robust and scalable." > > > > > >This defines a new type of proxy that wasn't supported (as far as I can > > tell) >in RFC2138. Here are my issues: > > > > > >1. How does the server *know* the network link characteristics. > Furthermore, > > >The difference in link speed may be a few hops away, and the protocol > > doesn't >provide any round trip calculation which makes this *nearly* > > impossible. >Furthermore, given the nature of the RADIUS protocol, I really > > don't see how >one *could* really determine the round trip time in a proxy > > environment. > > > >2. The lack of retransmission logic in the protocol is just another > way for > > >people to do Really Bad Implementations (TM), which will hamper the > network. > > >The DHCP people had to remove their text from their I-D at the request of > > the >IESG, and theirs was much better defined than this draft. > > > > > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, > how does > > >one syncronize the events? > > > >4. Certain attributes in the RADIUS protocol must be updated prior to > > >retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST > > be >updated each time something within the packet must be updated. So, who > > updates >these attributes, and how is the identifier field maintained. > > > > > >5. The warning above makes it clear that even the authors of the I-D think > > >this is a pretty dangerous area. So, why leave it in the draft? > > > > > >So, the above rambling are just some things that come to mind. I have a > > really >really hard time with leaving the text in the draft. > > > > > >PatC > > > > > >- > > >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 Tue Dec 7 07:58:42 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22376 for ; Tue, 7 Dec 1999 07:58: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 EAA12913; Tue, 7 Dec 1999 04:51:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA28879 for ietf-radius-outgoing; Tue, 7 Dec 1999 04:48:19 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199912071247.EAA22594@ha1mpk-mail.eng.sun.com> Date: Tue, 7 Dec 1999 04:40:11 -0800 To: "Matt Holdrege" , "pcalhoun@eng.sun.com" Cc: , Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit Matt, Alhough the WG is nearly dead, there are many new companies actually implementing RADIUS for use *other* than dial-in PPP (and some actually do develop it for what it was intended for). Anyways, my point here is that there are many new implementations coming on board, and documenting something half-ass (couldn't find any other language that really represented my feeling about this issue), doesn't help anyone. I would really be interested in finding out what an implementor does when he reads these two paragraphs. "Here is something you can do. We REALLY discourage you from doing it, and if you do, please do it right". What do you expect an implementor to do? How does he know whether he did it right? There are no guidelines, no rules, nothing. A very vague statement. Given the nature of the protocol, and the issues that I listed, this can be VERY tricky to implement, and to get it right it's even harder. Since people have done it, using their own imaginations, let's leave it out and let the future implementors use their own imaginations as well. PatC >If RADIUS were a new protocol that we had just churned out of an active >working group, I would agree with you. But we are simply documenting >something from a nearly dead working group that very much needs documenting. > >So I would turn your argument around and say, "what harm is it to leave >those two paragraphs in?" We aren't trying to describe anything new. The >harm in trying to remove it is that we may have to go to WG last call again >and delay the whole process. I don't think there is enough harm here to do >that. > > >At 09:21 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: >>Matt, >> >>I agree that we owe it to the community, but this *particular* change in the >>new draft really concerns me. I would like to see it taken out of the draft, >>before it is moved to last call. I really don't think that the new sentence >>adds ANY benefit, in fact it simply casts a shadow of doubt on how proxies >>really should work. >> >>As you say, servers do it today, and they follow RFC2138. So remove the two >>paragraphs, and let servers do what they want. It really isn't as if the draft >>proposes HOW a server can do it, so what *is* the benefit of having these two >>paragraphs? >> >>PatC >> >> > Pat, >> > >> > You know as well (or better) as the rest of us about the limitations of >> > RADIUS in a proxy environment. But nevertheless, a great many SP's are >> > using it in a proxy environment and have been for some time. The protocol >> > described in RFC 2138 has been applied to many scenarios that were never >> > considered at the time it originally was approved by the WG and one of >> them >> > is proxy. >> > >> > It does no good (IMHO) to worry about whether RFC 2138 allowed it or not, >> > because RADIUS server vendors made it work anyway. Going to Draft Standard >> > means that a lot of people are using the protocol and it is good to >> > document the protocol as used. RADIUS is what it is. >> > >> > I think the current draft that is in last call now is fine and we have >> > enough disclaimers in the text. We also have the ROAMOPS RFC's. >> > >> > Let's put RADIUS to bed. We owe it to the community. >> > >> > >> > >> > At 07:31 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: >> > > > Actually, the v2 draft doesn't include any Protocol changes; it just >> > > > clarifies and explains proxy better, and adds a few values, and >> improves >> > > > the examples. >> > > > >> > > > Its not really even v2; that's just the naming convention the Internet >> > > > Drafts directory wanted to use for the advance from proposed to draft >> > > > standard. >> > > > >> > > > Everything in the draft showed good interoperability at the Washington >> > > > Bake-off two years ago. Some people implemented Proxy incorrectly, >> > > > but everyone who implemented it according to the spec interoperated. >> > > > >> > > > Note that the interoperability report includes some features added >> > > > in the extensions draft, which is on an informational track, not >> > > > standards, primarily for LAT and Appletalk support, which many NAS >> > > > vendors aren't going to be doing. >> > > > >> > > > Are there any specific items that you're concerned about? >> > > >> > >actually, the following really scares me (I've sent an e-mail some >> time back >> > >in regards to this particular item): > >> > >" A forwarding server may either perform its forwarding function in a >> > > pass through manner, where it sends retransmissions on as soon as it >> > > gets them, or it may take responsibility for retransmissions, for >> > > example in cases where the network link between forwarding and remote >> > > server has very different characteristics than the link between NAS >> > > and forwarding server. >> > > >> > > Extreme care should be used when implementing a proxy server that >> > > takes responsibility for retransmissions so that its retransmission >> > > policy is robust and scalable." >> > > >> > >This defines a new type of proxy that wasn't supported (as far as I can >> > tell) >in RFC2138. Here are my issues: >> > > >> > >1. How does the server *know* the network link characteristics. >> Furthermore, >> > >The difference in link speed may be a few hops away, and the protocol >> > doesn't >provide any round trip calculation which makes this *nearly* >> > impossible. >Furthermore, given the nature of the RADIUS protocol, I really >> > don't see how >one *could* really determine the round trip time in a proxy >> > environment. > >> > >2. The lack of retransmission logic in the protocol is just another >> way for >> > >people to do Really Bad Implementations (TM), which will hamper the >> network. >> > >The DHCP people had to remove their text from their I-D at the request of >> > the >IESG, and theirs was much better defined than this draft. >> > > >> > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, >> how does >> > >one syncronize the events? > >> > >4. Certain attributes in the RADIUS protocol must be updated prior to >> > >retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST >> > be >updated each time something within the packet must be updated. So, who >> > updates >these attributes, and how is the identifier field maintained. >> > > >> > >5. The warning above makes it clear that even the authors of the I-D think >> > >this is a pretty dangerous area. So, why leave it in the draft? >> > > >> > >So, the above rambling are just some things that come to mind. I have a >> > really >really hard time with leaving the text in the draft. >> > > >> > >PatC >> > > >> > >- >> > >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 Tue Dec 7 10:59:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24087 for ; Tue, 7 Dec 1999 10:59:15 -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 HAA15532; Tue, 7 Dec 1999 07:48:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04151 for ietf-radius-outgoing; Tue, 7 Dec 1999 07:50:14 -0800 (PST) Message-Id: <4.2.2.19991207075012.00a33f00@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 07 Dec 1999 07:52:13 -0800 To: From: Matt Holdrege Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call Cc: , In-Reply-To: <199912071247.EAA22594@ha1mpk-mail.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege Well, since my biggest fear is that this will yet again delay the publishing of the very important Radius drafts the community is waiting for, let me ask the chair and/or the AD's if removing the sentence would require another WG last call? At 04:40 AM 12/7/99 -0800, Patrice Calhoun wrote: >Matt, > >Alhough the WG is nearly dead, there are many new companies actually >implementing RADIUS for use *other* than dial-in PPP (and some actually >do develop it for what it was intended for). Anyways, my point here is >that there are many new implementations coming on board, and documenting >something half-ass (couldn't find any other language that really represented >my feeling about this issue), doesn't help anyone. > >I would really be interested in finding out what an implementor does when >he reads these two paragraphs. > >"Here is something you can do. We REALLY discourage you from doing it, and >if you do, please do it right". > >What do you expect an implementor to do? How does he know whether he did >it right? There are no guidelines, no rules, nothing. A very vague statement. >Given the nature of the protocol, and the issues that I listed, this can >be VERY tricky to implement, and to get it right it's even harder. > >Since people have done it, using their own imaginations, let's leave it out >and let the future implementors use their own imaginations as well. > >PatC > >If RADIUS were a new protocol that we had just churned out of an active > >working group, I would agree with you. But we are simply documenting > >something from a nearly dead working group that very much needs documenting. > > > >So I would turn your argument around and say, "what harm is it to leave > >those two paragraphs in?" We aren't trying to describe anything new. The > >harm in trying to remove it is that we may have to go to WG last call again > >and delay the whole process. I don't think there is enough harm here to do > >that. > > > > > >At 09:21 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: > >>Matt, > >> > >>I agree that we owe it to the community, but this *particular* change > in the > >>new draft really concerns me. I would like to see it taken out of the > draft, > >>before it is moved to last call. I really don't think that the new sentence > >>adds ANY benefit, in fact it simply casts a shadow of doubt on how proxies > >>really should work. > >> > >>As you say, servers do it today, and they follow RFC2138. So remove the two > >>paragraphs, and let servers do what they want. It really isn't as if > the draft > >>proposes HOW a server can do it, so what *is* the benefit of having > these two > >>paragraphs? > >> > >>PatC > >> > >> > Pat, > >> > > >> > You know as well (or better) as the rest of us about the limitations of > >> > RADIUS in a proxy environment. But nevertheless, a great many SP's are > >> > using it in a proxy environment and have been for some time. The > protocol > >> > described in RFC 2138 has been applied to many scenarios that were never > >> > considered at the time it originally was approved by the WG and one of > >> them > >> > is proxy. > >> > > >> > It does no good (IMHO) to worry about whether RFC 2138 allowed it or > not, > >> > because RADIUS server vendors made it work anyway. Going to Draft > Standard > >> > means that a lot of people are using the protocol and it is good to > >> > document the protocol as used. RADIUS is what it is. > >> > > >> > I think the current draft that is in last call now is fine and we have > >> > enough disclaimers in the text. We also have the ROAMOPS RFC's. > >> > > >> > Let's put RADIUS to bed. We owe it to the community. > >> > > >> > > >> > > >> > At 07:31 AM 12/6/99 -0800, pcalhoun@eng.sun.com wrote: > >> > > > Actually, the v2 draft doesn't include any Protocol changes; it just > >> > > > clarifies and explains proxy better, and adds a few values, and > >> improves > >> > > > the examples. > >> > > > > >> > > > Its not really even v2; that's just the naming convention the > Internet > >> > > > Drafts directory wanted to use for the advance from proposed to > draft > >> > > > standard. > >> > > > > >> > > > Everything in the draft showed good interoperability at the > Washington > >> > > > Bake-off two years ago. Some people implemented Proxy incorrectly, > >> > > > but everyone who implemented it according to the spec interoperated. > >> > > > > >> > > > Note that the interoperability report includes some features added > >> > > > in the extensions draft, which is on an informational track, not > >> > > > standards, primarily for LAT and Appletalk support, which many NAS > >> > > > vendors aren't going to be doing. > >> > > > > >> > > > Are there any specific items that you're concerned about? > >> > > > >> > >actually, the following really scares me (I've sent an e-mail some > >> time back > >> > >in regards to this particular item): > > >> > >" A forwarding server may either perform its forwarding function in a > >> > > pass through manner, where it sends retransmissions on as soon > as it > >> > > gets them, or it may take responsibility for retransmissions, for > >> > > example in cases where the network link between forwarding and > remote > >> > > server has very different characteristics than the link between NAS > >> > > and forwarding server. > >> > > > >> > > Extreme care should be used when implementing a proxy server that > >> > > takes responsibility for retransmissions so that its retransmission > >> > > policy is robust and scalable." > >> > > > >> > >This defines a new type of proxy that wasn't supported (as far as I can > >> > tell) >in RFC2138. Here are my issues: > >> > > > >> > >1. How does the server *know* the network link characteristics. > >> Furthermore, > >> > >The difference in link speed may be a few hops away, and the protocol > >> > doesn't >provide any round trip calculation which makes this *nearly* > >> > impossible. >Furthermore, given the nature of the RADIUS protocol, I > really > >> > don't see how >one *could* really determine the round trip time in a > proxy > >> > environment. > > >> > >2. The lack of retransmission logic in the protocol is just another > >> way for > >> > >people to do Really Bad Implementations (TM), which will hamper the > >> network. > >> > >The DHCP people had to remove their text from their I-D at the > request of > >> > the >IESG, and theirs was much better defined than this draft. > >> > > > >> > >3. The fact that each RADIUS node in the chain MAY/WILL retransmit, > >> how does > >> > >one syncronize the events? > > >> > >4. Certain attributes in the RADIUS protocol must be updated prior to > >> > >retransmissions (e.g. Acct-Session-Time). Furthermore, the > identifier MUST > >> > be >updated each time something within the packet must be updated. > So, who > >> > updates >these attributes, and how is the identifier field maintained. > >> > > > >> > >5. The warning above makes it clear that even the authors of the > I-D think > >> > >this is a pretty dangerous area. So, why leave it in the draft? > >> > > > >> > >So, the above rambling are just some things that come to mind. I have a > >> > really >really hard time with leaving the text in the draft. > >> > > > >> > >PatC > >> > > > >> > >- > >> > >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 Tue Dec 7 11:01:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24974 for ; Tue, 7 Dec 1999 11:00: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 HAA15707; Tue, 7 Dec 1999 07:55:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04441 for ietf-radius-outgoing; Tue, 7 Dec 1999 07:58:00 -0800 (PST) Message-Id: <199912071557.KAA06864@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: ietf-radius@livingston.com Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call In-Reply-To: Message from Pat.Calhoun@eng.sun.com (Patrice Calhoun) of "Tue, 07 Dec 1999 04:40:11 PST." <199912071247.EAA22594@ha1mpk-mail.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 10:57:06 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson Carl, My sense as a RADIUS operator/user is that its best to offer whatever clues we can in the RFCs and try to reduce the need for "implementor imagination". My recent experience is that implementor clue density is dropping just as fast as operator clue density. In the old Internet, the clue density was high enough that reasonable things would happen. In the new Internet, the sum(clue) has remained a constant while the number of participants keeps growing rapidly. I find Pat's argument "Since people have done it using their own imaginations, let's leave it out and let the future implementors use their own imaginations as well" truly frightening as an operator. Proxy Servers are deployed and are useful in certain circumstances. I would advocate keeping the proxy server documented in the RFC. I don't care whether that is packaged as at present or whether it gets moved into a clearly non-normative appendix. Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 7 11:30:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09039 for ; Tue, 7 Dec 1999 11:30:46 -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 IAA16364; Tue, 7 Dec 1999 08:24:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA05559 for ietf-radius-outgoing; Tue, 7 Dec 1999 08:24:01 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199912071623.IAA09257@ha1mpk-mail.eng.sun.com> Date: Tue, 7 Dec 1999 08:15:51 -0800 To: "Ran Atkinson" , Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit > >Carl, > > My sense as a RADIUS operator/user is that its best to offer >whatever clues we can in the RFCs and try to reduce the need for >"implementor imagination". My recent experience is that implementor clue >density is dropping just as fast as operator clue density. > > In the old Internet, the clue density was high enough that >reasonable things would happen. In the new Internet, the sum(clue) has >remained a constant while the number of participants keeps growing rapidly. > > I find Pat's argument "Since people have done it using their >own imaginations, let's leave it out and let the future implementors >use their own imaginations as well" truly frightening as an operator. hmmm.. and the current text isn't? My reasoning for asking that the text (specifically those two paragraphs, not all of the proxy section) be removed, is that it REALLY only adds confusion. Certainly you can't say that the text in the draft provides enough of a base that developers wouldn't have to use their imagination! Now, if we, as a WG, decide that we want to define exactly how this can be achieved, then we could, but again, this would take a REALLY LONG TIME (TM). > > Proxy Servers are deployed and are useful in certain circumstances. >I would advocate keeping the proxy server documented in the RFC. I >don't care whether that is packaged as at present or whether it gets moved >into a clearly non-normative appendix. See above comment. I am not requesting that all proxy server text be removed. Only the text that doesn't add anything useful, with the exception of confusion. PatC > >Ran >rja@corp.home.net > > >- >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 Tue Dec 7 11:45:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16178 for ; Tue, 7 Dec 1999 11:45: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 IAA16666; Tue, 7 Dec 1999 08:40:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA06466 for ietf-radius-outgoing; Tue, 7 Dec 1999 08:42:58 -0800 (PST) Message-Id: <199912071641.LAA07029@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: pcalhoun@eng.sun.com cc: "Ran Atkinson" , ietf-radius@livingston.com, rja@corp.home.net Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call In-Reply-To: Message from Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) of "Tue, 07 Dec 1999 08:15:51 PST." <199912071623.IAA09257@ha1mpk-mail.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 11:41:55 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson % hmmm.. and the current text isn't? Correct. The current text isn't. % My reasoning for asking that the % text (specifically those two paragraphs, not all of the proxy section) % be removed, is that it REALLY only adds confusion. Disagree. It reduces confusion. % Certainly you can't say that the text in the draft provides enough % of a base that developers wouldn't have to use their imagination! It significantly increases the probability of something sensible being implemented, IMHO. % Now, if we, as a WG, decide that we want to define exactly how this can % be achieved, then we could, but again, this would take a REALLY LONG TIME I understand that you have a different perspective than I do about retaining the current text. I don't think anyone has proposed reconstituting the working group. Best wishes, Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 7 11:59:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22732 for ; Tue, 7 Dec 1999 11:59:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA16981; Tue, 7 Dec 1999 08:53:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA07051 for ietf-radius-outgoing; Tue, 7 Dec 1999 08:55:35 -0800 (PST) Message-ID: <004501bf40d3$90e0ec40$0a03a8c0@VAIO> From: "Darran Potter" To: "Carl Rigney" , References: <199912062327.PAA22487@server.livingston.com> Subject: Re: (radius) Proxy Date: Tue, 7 Dec 1999 16:53:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit CiscoSecure NT doesnt manage re-transmissions... it does ignore duplicate requests sent to it. So it depends on the NAS/up-stream radius server as to what can happen. IMHO. there are an infinite number of things a forwarding server could be made to do.. many of which would probably be bad. We wouldnt want to see them all listed. Hence unless there is good reason to include the paragraphs about re-transmissions I would remove them. I personally dont think it adds anything to the RFC by its inclusion. Darran dpotter@cisco.com ----- Original Message ----- From: Carl Rigney To: Sent: Monday, December 06, 1999 11:27 PM Subject: (radius) Proxy > I'm interested in hearing from people who've actually implemented Proxy > RADIUS or have operational experience with it. Was the language in the > current draft (which passed working group last call in May with no > objections then) useful to you? Can you make concrete suggestions as > to how to make it more useful to future implementers? Have people > found any interoperability problems other than just cases where other > implementers didn't implement proxy or deliberately ignored the way > it's documented to work? > > Having implemented proxy support myself, in Livingston's RADIUS server > 2.1, the current text captures the best state of my knowledge as to the > things to best look out for. > > As for forwarding servers manipulating the contents of access-accepts, > I recall us hashing that out at length nearly a year ago, and reaching > consensus that implementations WERE going to do it, so we might as well > make implementers aware that that sort of thing might happen. > > -- > Carl Rigney > RADIUS WG Chair > cdr@livingston.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 Tue Dec 7 12:11:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28321 for ; Tue, 7 Dec 1999 12:11:29 -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 JAA17169; Tue, 7 Dec 1999 09:00:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA07358 for ietf-radius-outgoing; Tue, 7 Dec 1999 09:02:28 -0800 (PST) Date: Tue, 7 Dec 1999 12:00:04 -0500 (EST) From: "Steven P. Crain" To: Patrice Calhoun cc: ietf-radius@livingston.com Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call In-Reply-To: <199912071623.IAA09257@ha1mpk-mail.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Tue, 7 Dec 1999, Patrice Calhoun wrote: > > In the old Internet, the clue density was high enough that > >reasonable things would happen. In the new Internet, the sum(clue) has > >remained a constant while the number of participants keeps growing rapidly. > > > > I find Pat's argument "Since people have done it using their > >own imaginations, let's leave it out and let the future implementors > >use their own imaginations as well" truly frightening as an operator. > > hmmm.. and the current text isn't? My reasoning for asking that the > text (specifically those two paragraphs, not all of the proxy section) > be removed, is that it REALLY only adds confusion. > > Certainly you can't say that the text in the draft provides enough > of a base that developers wouldn't have to use their imagination! How would the following text work as a compromise: A forwarding server SHOULD perform its forwarding function in a pass through manner, where it sends retransmissions on as soon as it gets them. This, of course, means that we are recommending the pass-through retransmission strategy, and it is implicit that there are other permissible strategies which certainly require a good reason before you select them, and probably require careful design to work well. The only problem I can see with my propsed text is that as clue density drops implementors seem to grep the RFC for MUST and only read those lines ;-(. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections Better is open rebuke than hidden love. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 7 12:58:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21951 for ; Tue, 7 Dec 1999 12:58:11 -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 JAA18441; Tue, 7 Dec 1999 09:50:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA10177 for ietf-radius-outgoing; Tue, 7 Dec 1999 09:49:54 -0800 (PST) From: Gopal Dommety Message-Id: <199912071745.JAA23053@omega.cisco.com> Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call To: Pat.Calhoun@eng.sun.com Date: Tue, 7 Dec 1999 09:45:57 -0800 (PST) Cc: rja@corp.home.net, ietf-radius@livingston.com In-Reply-To: <199912071623.IAA09257@ha1mpk-mail.eng.sun.com> from "Patrice Calhoun" at Dec 7, 99 08:15:51 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Gopal Dommety Content-Transfer-Encoding: 7bit Carl, I think having the two paragraphs about retransmissions is GOOD. It leaves scope for implementation and does not restrict the usage. There are several implementaitons that do it today. An Example of one such RADIUS server is Cisco's Access Registrar. Personally, I think this scope is important in Proxy environments. Please leave scope for people to use imagination and innovation, for that is Internet is where it is today. Thanks. Gopal Cisco Systems > > > > > >Carl, > > > > My sense as a RADIUS operator/user is that its best to offer > >whatever clues we can in the RFCs and try to reduce the need for > >"implementor imagination". My recent experience is that implementor clue > >density is dropping just as fast as operator clue density. > > > > In the old Internet, the clue density was high enough that > >reasonable things would happen. In the new Internet, the sum(clue) has > >remained a constant while the number of participants keeps growing rapidly. > > > > I find Pat's argument "Since people have done it using their > >own imaginations, let's leave it out and let the future implementors > >use their own imaginations as well" truly frightening as an operator. > > hmmm.. and the current text isn't? My reasoning for asking that the > text (specifically those two paragraphs, not all of the proxy section) > be removed, is that it REALLY only adds confusion. > > Certainly you can't say that the text in the draft provides enough > of a base that developers wouldn't have to use their imagination! > > Now, if we, as a WG, decide that we want to define exactly how this can > be achieved, then we could, but again, this would take a REALLY LONG TIME (TM). > > > > > Proxy Servers are deployed and are useful in certain circumstances. > >I would advocate keeping the proxy server documented in the RFC. I > >don't care whether that is packaged as at present or whether it gets moved > >into a clearly non-normative appendix. > > See above comment. I am not requesting that all proxy server text be > removed. Only the text that doesn't add anything useful, with the exception > of confusion. > > PatC > > > > > >Ran > >rja@corp.home.net > > > > > >- > >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. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 7 13:21:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03786 for ; Tue, 7 Dec 1999 13:21:08 -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 KAA18994; Tue, 7 Dec 1999 10:14:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA11978 for ietf-radius-outgoing; Tue, 7 Dec 1999 10:15:27 -0800 (PST) Message-ID: <384D4DEE.D2D33676@merit.edu> Date: Tue, 07 Dec 1999 13:12:00 -0500 From: John Vollbrecht Organization: Merit Network Inc X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" Cc: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) 6 RADIUS Drafts off to IESG/IETF Last Call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: John Vollbrecht Content-Transfer-Encoding: 7bit I agree with Pat that this wording about proxy is not good. RFC 2607 "procy Chaining and Policy Implementation in Roaming" discusses the whole proxy with radius issue, and there was significant discussion of this in the Roamops WG. The conclusion was different that what is described here. In RFC 2607 the forwarding behaviour for an Authorization request is described as Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1 without first having received a Reply packet initiated by the Home Server. The two exceptions are when the proxy is enforcing policy as described in section 5.1 and when the proxy is acting as an accounting store (as in store and forward), as described in section 5.2 Section 5.1 describes the store and forward case for ACCOUNTING (not Access) Requests. Section 5.2 describes the case where the proxy is rejecting the request and doesn't need to forward it. I think this wording in the RADIUS draft will give implementers the wrong idea about what is a good implementation. I would also like to see it removed. -- John "pcalhoun@eng.sun.com" wrote: > > Actually, the v2 draft doesn't include any Protocol changes; it just > > clarifies and explains proxy better, and adds a few values, and improves > > the examples. > > > > Its not really even v2; that's just the naming convention the InternetExcept > for the two cases described below, a proxy server such as > > > Drafts directory wanted to use for the advance from proposed to draft > > standard. > > > > Everything in the draft showed good interoperability at the Washington > > Bake-off two years ago. Some people implemented Proxy incorrectly, > > but everyone who implemented it according to the spec interoperated. > > > > Note that the interoperability report includes some features added > > in the extensions draft, which is on an informational track, not > > standards, primarily for LAT and Appletalk support, which many NAS > > vendors aren't going to be doing. > > > > Are there any specific items that you're concerned about? > > actually, the following really scares me (I've sent an e-mail some time back > in regards to this particular item): > > " A forwarding server may either perform its forwarding function in a > pass through manner, where it sends retransmissions on as soon as it > gets them, or it may take responsibility for retransmissions, for > example in cases where the network link between forwarding and remote > server has very different characteristics than the link between NAS > and forwarding server. > > Extreme care should be used when implementing a proxy server that > takes responsibility for retransmissions so that its retransmission > policy is robust and scalable." > > This defines a new type of proxy that wasn't supported (as far as I can tell) > in RFC2138. Here are my issues: > > 1. How does the server *know* the network link characteristics. Furthermore, > The difference in link speed may be a few hops away, and the protocol doesn't > provide any round trip calculation which makes this *nearly* impossible. > Furthermore, given the nature of the RADIUS protocol, I really don't see how > one *could* really determine the round trip time in a proxy environment. > > 2. The lack of retransmission logic in the protocol is just another way for > people to do Really Bad Implementations (TM), which will hamper the network. > The DHCP people had to remove their text from their I-D at the request of the > IESG, and theirs was much better defined than this draft. > > 3. The fact that each RADIUS node in the chain MAY/WILL retransmit, how does > one syncronize the events? > > 4. Certain attributes in the RADIUS protocol must be updated prior to > retransmissions (e.g. Acct-Session-Time). Furthermore, the identifier MUST be > updated each time something within the packet must be updated. So, who updates > these attributes, and how is the identifier field maintained. > > 5. The warning above makes it clear that even the authors of the I-D think > this is a pretty dangerous area. So, why leave it in the draft? > > So, the above rambling are just some things that come to mind. I have a really > really hard time with leaving the text in the draft. > > PatC > > - > 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 Tue Dec 7 16:13:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27427 for ; Tue, 7 Dec 1999 16: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 NAA22599; Tue, 7 Dec 1999 13:08:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA21706 for ietf-radius-outgoing; Tue, 7 Dec 1999 13:08:58 -0800 (PST) Date: Tue, 7 Dec 1999 21:05:39 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Proxy In-Reply-To: <199912062327.PAA22487@server.livingston.com> 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 Carl, We have heavily developed and deployed a proxy RADIUS infrastructure. While I found it interesting to see mention of a proxy in the current text, I'm not sure that the verbage was useful at all in architecting the service. My primary concern would be that these passages do not do an adequate job in presenting an all-inclusive understanding of what exactly a RADIUS proxy is, what it does, or how it should (inter)operate and that having this wording in the RFC will tend to pollute (or worse, confuse) potential RADIUS architects and developers. I feel that the RFC in this situation should either fully explain and elaborate on the subject or should point to an external reference that does the same. Regards, Barry Barry L James | Never doubt that a small group of IP Systems Engineering | 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 Dec 9 11:02:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02538 for ; Thu, 9 Dec 1999 11: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 HAA01758; Thu, 9 Dec 1999 07:57:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA08849 for ietf-radius-outgoing; Thu, 9 Dec 1999 07:51:38 -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) the two contentious proxy paragraphs Message-Id: Date: Thu, 09 Dec 1999 07:51:33 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit [ mail to/from the radius list is not functioning very well, e.g. despite that i am subscribed, i get no messages, mine are not in the archive (which is where i have to read the list, ... . this is my third attempt to ask this question ] do these two contentious paragraphs o define a feature not in the proposed standard document o give guidance, whether clear or not, to implementors of a feature already in the ps document o confuse the reader sufficiently that they are likely to cause worse implementations than with the paragraphs elided if you choose the last one, you must also send suggested wording that is clearer. excuse me for not quoting 300 lines of previous email . randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 10:18:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24771 for ; Fri, 10 Dec 1999 10:18:23 -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 HAA25179; Fri, 10 Dec 1999 07:13:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA05083 for ietf-radius-outgoing; Fri, 10 Dec 1999 07:13:56 -0800 (PST) From: Patrice Calhoun Message-Id: <199912101513.HAA11986@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 07:05:19 -0800 To: Cc: , , Subject: (radius) Comments on Tunnel Draft X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit Although I find the document very useful, and think that it should be moved to proposed standard, I do have a problem with one attribute defined in the said draft. The attribute is called the Tunnel-Password. This attribute has been the subject of quite a bit of controversy in the past, and I am quite surprised that it wasn't removed. The problem that I have with it is that in roaming environments, the intermediate nodes have access to the plain text password. This "encryption" is hop-by-hop, and in roaming environments traverses "untrusted" hosts. The real purpose for the Tunnel-Password is to secure L2TP, but the L2TP draft does state that if one does want a secure tunnel (and one should), IP Security MUST be used. There is a whole I-D that discusses how L2TP and IP Security are used together. Therefore, this attribute has questionable value. Furthermore, since the draft doesn't actually state that this attribute is ONLY for L2TP tunnels, there are people out there wanting to use this attribute for other reasons, such as passing around IKE pre-shared keys in roaming environments. In principle I don't have a problem with AAA protocols generating the keys. However, due to the nature of the RADIUS protocol, and the security weaknesses in roaming networks, I would prefer to see support for the Tunnel-Password removed. Flame on! PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 10:24:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24947 for ; Fri, 10 Dec 1999 10:24: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 HAA25598; Fri, 10 Dec 1999 07:19:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA05370 for ietf-radius-outgoing; Fri, 10 Dec 1999 07:21:43 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Patrice Calhoun Cc: Subject: (radius) Re: Comments on Tunnel Draft References: <199912101513.HAA11986@nasnfs.eng.sun.com> Message-Id: Date: Fri, 10 Dec 1999 07:21:38 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit is the tunnel password feature actually in use? if so, it will be hard to justify removing it from the doc. though it sounds as if a large warning would be well advised. if it is not actually used, or is used in an extemely minor place/way, then removing it might be appropriate. if it is removed, a note might go in as a placeholder. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 11:09:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26078 for ; Fri, 10 Dec 1999 11:09:13 -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 IAA26609; Fri, 10 Dec 1999 08:02:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA06778 for ietf-radius-outgoing; Fri, 10 Dec 1999 08:00:36 -0800 (PST) Message-ID: <00fe01bf4327$63e4fc80$0a03a8c0@VAIO> From: "Darran Potter" To: "Randy Bush" , "Patrice Calhoun" Cc: References: <199912101513.HAA11986@nasnfs.eng.sun.com> Subject: Re: (radius) Re: Comments on Tunnel Draft Date: Fri, 10 Dec 1999 15:58:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit Both UNIX and NT versions of CiscoSecure support the Tunnel-Password. On the NT side, at least, we have clients who use it as a key part of their business. IOS has has support for a while too. We also interoperate with Ascend customers who use it. I'd say removal at this stage would probably upset a lot of people. Darran dpotter@cisco.com ----- Original Message ----- From: Randy Bush To: Patrice Calhoun Cc: Sent: Friday, December 10, 1999 3:21 PM Subject: (radius) Re: Comments on Tunnel Draft > is the tunnel password feature actually in use? if so, it will be hard to > justify removing it from the doc. though it sounds as if a large warning > would be well advised. > > if it is not actually used, or is used in an extemely minor place/way, then > removing it might be appropriate. if it is removed, a note might go in as > a placeholder. > > randy > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 11:46:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27042 for ; Fri, 10 Dec 1999 11:46:16 -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 IAA27978; Fri, 10 Dec 1999 08:41:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA08903 for ietf-radius-outgoing; Fri, 10 Dec 1999 08:43:41 -0800 (PST) Message-ID: <010a01bf432b$a5d7eef0$527646ab@DMCNAMEEPC> From: "Dave McNamee" To: "Darran Potter" , "Randy Bush" , "Patrice Calhoun" Cc: References: <199912101513.HAA11986@nasnfs.eng.sun.com> <00fe01bf4327$63e4fc80$0a03a8c0@VAIO> Subject: Re: (radius) Re: Comments on Tunnel Draft Date: Fri, 10 Dec 1999 08:28:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.207 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.207 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dave McNamee" Content-Transfer-Encoding: 7bit Cisco Access Registrar has just completed development of support for this as well, at the request of several SP customers. Dave dmcnamee@cisco.com ----- Original Message ----- From: Darran Potter To: Randy Bush ; Patrice Calhoun Cc: Sent: Friday, December 10, 1999 7:58 AM Subject: Re: (radius) Re: Comments on Tunnel Draft > Both UNIX and NT versions of CiscoSecure support the Tunnel-Password. On the > NT side, at least, we have clients who use it as > a key part of their business. IOS has has support for a while too. > > We also interoperate with Ascend customers who use it. > > I'd say removal at this stage would probably upset a lot of people. > > Darran > dpotter@cisco.com > > > ----- Original Message ----- > From: Randy Bush > To: Patrice Calhoun > Cc: > Sent: Friday, December 10, 1999 3:21 PM > Subject: (radius) Re: Comments on Tunnel Draft > > > > is the tunnel password feature actually in use? if so, it will be hard to > > justify removing it from the doc. though it sounds as if a large warning > > would be well advised. > > > > if it is not actually used, or is used in an extemely minor place/way, > then > > removing it might be appropriate. if it is removed, a note might go in as > > a placeholder. > > > > randy > > - > > 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. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 11:48:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27076 for ; Fri, 10 Dec 1999 11:48: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 IAA27844; Fri, 10 Dec 1999 08:38:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA08681 for ietf-radius-outgoing; Fri, 10 Dec 1999 08:39:43 -0800 (PST) Message-Id: <199912101638.LAA20963@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: "Darran Potter" cc: ietf-radius@livingston.com Subject: Re: (radius) Re: Comments on Tunnel Draft In-Reply-To: Message from "Darran Potter" of "Fri, 10 Dec 1999 15:58:20 GMT." <00fe01bf4327$63e4fc80$0a03a8c0@VAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 11:38:45 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson Based on Darran's note, I'd suggest: - Formally deprecate Tunnel-Password with text explaining how it means that one gets ZERO effective security, but keep it documented. Actually recommend that folks either not implement it or provide a configuration knob to disable it. This means existing users aren't completely hosed and that we've done our part to make it clear that the usage is insecure as heck and should go away in future. Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:02:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27540 for ; Fri, 10 Dec 1999 12:02:22 -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 IAA28637; Fri, 10 Dec 1999 08:52:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA09551 for ietf-radius-outgoing; Fri, 10 Dec 1999 08:54:51 -0800 (PST) Message-ID: <012f01bf432e$f6fa0400$0a03a8c0@VAIO> From: "Darran Potter" To: "Ran Atkinson" Cc: References: <199912101638.LAA20963@dragonfly.corp.home.net> Subject: Re: (radius) Re: Comments on Tunnel Draft Date: Fri, 10 Dec 1999 16:52:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit Isnt the objection really about the Tunnel-Password in a proxy environment? ..and even then only when some of the proxies are not yours? I think the RFC already has a pretty good paragrah under security considerations. For many places doing VPN this attribute is KEY. I cant see how you can deprecate it... Its like "lets do away with User-Password since PAP isnt as safe as chap." darran dpotter@cisco.com ----- Original Message ----- From: Ran Atkinson To: Darran Potter Cc: Sent: Friday, December 10, 1999 4:38 PM Subject: Re: (radius) Re: Comments on Tunnel Draft > > Based on Darran's note, I'd suggest: > - Formally deprecate Tunnel-Password with text explaining > how it means that one gets ZERO effective security, > but keep it documented. Actually recommend that folks > either not implement it or provide a configuration knob > to disable it. > > This means existing users aren't completely hosed and that we've > done our part to make it clear that the usage is insecure as heck > and should go away in future. > > Ran > rja@corp.home.net > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:08:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27757 for ; Fri, 10 Dec 1999 12:08: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 JAA28958; Fri, 10 Dec 1999 09:03:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA10207 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:06:07 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Fri, 10 Dec 1999 11:50 EST Subject: Re: (radius) Re: Comments on Tunnel Draft Content-Type: text/plain Message-ID: <385132ab0.ff7@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff There has been much discussion of Tunnel-Password, and RADIUS proxying in general. That both User-Password and Tunnel-Password will be visible to proxies is well known. I believe deprecating Tunnel-Password is overkill - not everybody uses proxies, proxies may in fact be within a single organization or otherwise trusted, or the attribute may be added by the proxy closest to the NAS. There is no necessary relationship between the tunnel destination and the RADIUS server. Using Tunnel-Password to distribute an IKE secret is clearly a misuse, but nothing in the draft suggests this use. In addition to the implementations already cited, both 3Com and AT&T support and use Tunnel-Password. I would support adding a warning that the attribute will be visible to proxies, but nothing beyond that. Barney Wolff > Date: Fri, 10 Dec 1999 11:38:45 -0500 > From: Ran Atkinson > > Based on Darran's note, I'd suggest: > - Formally deprecate Tunnel-Password with text explaining > how it means that one gets ZERO effective security, > but keep it documented. Actually recommend that folks > either not implement it or provide a configuration knob > to disable it. > > This means existing users aren't completely hosed and that we've > done our part to make it clear that the usage is insecure as heck > and should go away in future. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:13:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27935 for ; Fri, 10 Dec 1999 12:13:29 -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 JAA29439; Fri, 10 Dec 1999 09:08:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA10448 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:10:43 -0800 (PST) Message-Id: <4.2.2.19991210120024.00d17420@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Dec 1999 12:06:59 -0500 To: ietf-radius From: "David Mitton" Subject: Re: (radius) Re: Comments on Tunnel Draft In-Reply-To: References: <199912101513.HAA11986@nasnfs.eng.sun.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" BayDVS Tunneling and our L2TP support depend on this feature too. Dave. At 07:21 AM 12/10/99 -0800, you wrote: >is the tunnel password feature actually in use? if so, it will be hard to >justify removing it from the doc. though it sounds as if a large warning >would be well advised. > >if it is not actually used, or is used in an extemely minor place/way, then >removing it might be appropriate. if it is removed, a note might go in as >a placeholder. > >randy >- >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 Fri Dec 10 12:13:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27947 for ; Fri, 10 Dec 1999 12:13: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 JAA29455; Fri, 10 Dec 1999 09:08:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA10483 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:11:02 -0800 (PST) Message-Id: <199912101709.MAA21199@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: "Darran Potter" cc: "Ran Atkinson" , ietf-radius@livingston.com Subject: Re: (radius) Re: Comments on Tunnel Draft In-Reply-To: Message from "Darran Potter" of "Fri, 10 Dec 1999 16:52:31 GMT." <012f01bf432e$f6fa0400$0a03a8c0@VAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 12:09:55 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson Darran, You don't seem to follow the meaning of "deprecated". A deprecated variable is still _defined_, so folks foolish enough to use it may do so. However, folks are explicitly discouraged (not prohibited) from implementing/using it for the reasons stated. This variable is basically insecure in all conditions that I can think of, so it should be deprecated. It will continue to be used, regardless of how insecure it is, so it needs to continue to be defined. Mind, there are other bits of RADIUS that are also insecure. The whole use of "authentication" in the context of RADIUS is actually pretty amusing (a kind of schadenfreude, for those who know Deutsch). Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:18:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28050 for ; Fri, 10 Dec 1999 12:18:29 -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 JAA29801; Fri, 10 Dec 1999 09:13:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA10784 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:15:33 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ran Atkinson Cc: ietf-radius@livingston.com Subject: Re: (radius) Re: Comments on Tunnel Draft References: <012f01bf432e$f6fa0400$0a03a8c0@VAIO> <199912101709.MAA21199@dragonfly.corp.home.net> Message-Id: Date: Fri, 10 Dec 1999 09:15:26 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > A deprecated variable is still _defined_, so folks foolish enough > to use it may do so. However, folks are explicitly discouraged (not > prohibited) from implementing/using it for the reasons stated. more interestingly, i think you want it to mean "don't make new uses of this." randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:25:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28213 for ; Fri, 10 Dec 1999 12:25:15 -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 JAA00199; Fri, 10 Dec 1999 09:20:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA11149 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:22:34 -0800 (PST) Message-ID: <015701bf4332$d420ac00$0a03a8c0@VAIO> From: "Darran Potter" To: "Ran Atkinson" Cc: "Ran Atkinson" , References: <199912101709.MAA21199@dragonfly.corp.home.net> Subject: Re: (radius) Re: Comments on Tunnel Draft Date: Fri, 10 Dec 1999 17:20:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit one thinks one is being baited. I think several other major "foolish" vendors have also implemented this attribute... most likely because they had big accounts shouting for it. Deprecation usually implies something better. Where is it? How many clients currently want it? Thats where Cisco's motivation comes from. Darran ----- Original Message ----- From: Ran Atkinson To: Darran Potter Cc: Ran Atkinson ; Sent: Friday, December 10, 1999 5:09 PM Subject: Re: (radius) Re: Comments on Tunnel Draft > > Darran, > > You don't seem to follow the meaning of "deprecated". > > A deprecated variable is still _defined_, so folks foolish enough > to use it may do so. However, folks are explicitly discouraged (not > prohibited) from implementing/using it for the reasons stated. > > This variable is basically insecure in all conditions that I can > think of, so it should be deprecated. It will continue to be used, > regardless of how insecure it is, so it needs to continue to be defined. > > Mind, there are other bits of RADIUS that are also insecure. > The whole use of "authentication" in the context of RADIUS is actually > pretty amusing (a kind of schadenfreude, for those who know Deutsch). > > Ran > rja@corp.home.net > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:27:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28249 for ; Fri, 10 Dec 1999 12:26: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 JAA00245; Fri, 10 Dec 1999 09:20:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA11202 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:23:03 -0800 (PST) From: Patrice Calhoun Message-Id: <199912101722.JAA13120@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 09:14:27 -0800 To: "Barney Wolff" , Subject: Re: (radius) Re: Comments on Tunnel Draft X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit >There has been much discussion of Tunnel-Password, and RADIUS proxying >in general. That both User-Password and Tunnel-Password will be >visible to proxies is well known. I believe deprecating Tunnel-Password >is overkill - not everybody uses proxies, proxies may in fact be >within a single organization or otherwise trusted, or the attribute >may be added by the proxy closest to the NAS. There is no necessary >relationship between the tunnel destination and the RADIUS server. I guess I don't get it. It sounds like L2TP is being run over a non-trusted network since the key is used to encrypt L2TP AVPs. However, running L2TP over a non-trusted network is a Bad Thing (TM). There are simply so may denial of attacks, and theft of tunnels that can occur that I don't see why this particular attribute will solve L2TP over non-secure networks. I understand the reason why some people that have current implementations are reluctant to remove it, but keep in mind that the security ADs will probably have a field day with this one :( > >Using Tunnel-Password to distribute an IKE secret is clearly a misuse, >but nothing in the draft suggests this use. Well, one of the Tunnel-Types is IP Security. So, if one reads the draft, one SHOULD assume that the Tunnel-Password can be used for pretty much any of the Tunnel-Types, including IKE or even ESP and AH! PatC > >In addition to the implementations already cited, both 3Com and AT&T >support and use Tunnel-Password. > >I would support adding a warning that the attribute will be visible >to proxies, but nothing beyond that. > >Barney Wolff > >> Date: Fri, 10 Dec 1999 11:38:45 -0500 >> From: Ran Atkinson >> >> Based on Darran's note, I'd suggest: >> - Formally deprecate Tunnel-Password with text explaining >> how it means that one gets ZERO effective security, >> but keep it documented. Actually recommend that folks >> either not implement it or provide a configuration knob >> to disable it. >> >> This means existing users aren't completely hosed and that we've >> done our part to make it clear that the usage is insecure as heck >> and should go away in future. >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 12:44:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28772 for ; Fri, 10 Dec 1999 12:44: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 JAA01185; Fri, 10 Dec 1999 09:39:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA12249 for ietf-radius-outgoing; Fri, 10 Dec 1999 09:41:03 -0800 (PST) From: Patrice Calhoun Message-Id: <199912101740.JAA13363@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 09:32:05 -0800 To: "Darran Potter" Cc: Subject: Re: (radius) Re: Comments on Tunnel Draft X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit >one thinks one is being baited. > >I think several other major "foolish" vendors have also implemented this >attribute... most likely because they had big accounts shouting >for it. > >Deprecation usually implies something better. Where is it? http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-05.txt. If there are too many people that have actually implemented the draft, and these same vendors also sell this to their customers as a "security" feature, I agree that removing it altogether will be very difficult. just to be clear, I think that the draft is needed, and should move ahead. I just had a problem with this attribute. If it isn't as clear cut as simply removing the attribute because L2TP is not being secured using IP security, then move the draft ahead. I still think it's a bad idea, but I won't pursue this avenue any longer. PatC >How many >clients currently want it? Thats where Cisco's motivation comes from. > >Darran > >----- Original Message ----- >From: Ran Atkinson >To: Darran Potter >Cc: Ran Atkinson ; >Sent: Friday, December 10, 1999 5:09 PM >Subject: Re: (radius) Re: Comments on Tunnel Draft > > >> >> Darran, >> >> You don't seem to follow the meaning of "deprecated". >> >> A deprecated variable is still _defined_, so folks foolish enough >> to use it may do so. However, folks are explicitly discouraged (not >> prohibited) from implementing/using it for the reasons stated. >> >> This variable is basically insecure in all conditions that I can >> think of, so it should be deprecated. It will continue to be used, >> regardless of how insecure it is, so it needs to continue to be defined. >> >> Mind, there are other bits of RADIUS that are also insecure. >> The whole use of "authentication" in the context of RADIUS is actually >> pretty amusing (a kind of schadenfreude, for those who know Deutsch). >> >> Ran >> rja@corp.home.net >> >> >> - >> 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. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 13:03:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29286 for ; Fri, 10 Dec 1999 13:03:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA01571; Fri, 10 Dec 1999 09:58:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA13515 for ietf-radius-outgoing; Fri, 10 Dec 1999 10:00:27 -0800 (PST) From: Barney Wolff To: Date: Fri, 10 Dec 1999 12:40 EST Subject: Re: (radius) Re: Comments on Tunnel Draft Content-Type: text/plain Message-ID: <38513f640.126a@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: Patrice Calhoun > Date: Fri, 10 Dec 1999 09:14:27 -0800 > > I guess I don't get it. It sounds like L2TP is being run over a > non-trusted network since the key is used to encrypt L2TP AVPs. However, > running L2TP over a non-trusted network is a Bad Thing (TM). There are > simply so may denial of attacks, and theft of tunnels that can occur > that I don't see why this particular attribute will solve L2TP over > non-secure networks. In order for an attacker who cannot sniff packets to destroy or steal a tunnel, he must get all of the following right: 2 IP addresses 2 random UDP ports (assuming ports are chosen sensibly) 1 tunnel id Ns within the window Yes, if the attacker can see as well as inject packets nothing short of IPSEC will do. I will point out that an active attacker can put quite a load on an IPSEC host, even though the attack will not break its security. Tunnel-Password's use in adding some minimal assurance of partner identity is my primary need for it. There are major networks that are source-addr-spoofable but not sniffable, and in some cases we have to partner with them. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 14:21:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01258 for ; Fri, 10 Dec 1999 14:21: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 LAA03528; Fri, 10 Dec 1999 11:16:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA18667 for ietf-radius-outgoing; Fri, 10 Dec 1999 11:17:11 -0800 (PST) Date: Fri, 10 Dec 1999 19:13:50 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: Patrice Calhoun cc: ietf-radius@livingston.com, randy@psg.com Subject: Re: (radius) Comments on Tunnel Draft In-Reply-To: <199912101513.HAA11986@nasnfs.eng.sun.com> 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 Does it make any sense to have a tag that tells the intermediate Proxies (if there are any) that they are to simply pass the AVP along without validating the data? Then only the nearest-LAC-RADIUS would have the trusted relationship with the end-point RADIUS/LNS/whatever and do the voodoo there? I can see issues with this (one being how does a RADIUS server know it's the nearest-LAC-RADIUS - maybe it can look at the NAS-Identifier or IP and if the remote server is the same then it can possibly assume it's the nearest-LAC-RADIUS) but I never fully understood why any intermediate proxies needed to know anything about LAC->LNS tunnel passwords. Barry Barry L James | Never doubt that a small group of IP Systems Engineering | 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 Dec 10 14:37:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01515 for ; Fri, 10 Dec 1999 14:36:58 -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 LAA03901; Fri, 10 Dec 1999 11:31:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA19898 for ietf-radius-outgoing; Fri, 10 Dec 1999 11:33:49 -0800 (PST) From: Patrice Calhoun Message-Id: <199912101933.LAA14497@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 11:25:04 -0800 To: "Barry James" , "Patrice Calhoun" Cc: , Subject: Re: (radius) Comments on Tunnel Draft X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit Unfortunately, RADIUS has a hop-by-hop security model, so what you are proposing here wouldn't work :( PatC >Does it make any sense to have a tag that tells the intermediate Proxies >(if there are any) that they are to simply pass the AVP along without >validating the data? Then only the nearest-LAC-RADIUS would have the >trusted relationship with the end-point RADIUS/LNS/whatever and do the >voodoo there? I can see issues with this (one being how does a RADIUS >server know it's the nearest-LAC-RADIUS - maybe it can look at the >NAS-Identifier or IP and if the remote server is the same then it can >possibly assume it's the nearest-LAC-RADIUS) but I never fully understood >why any intermediate proxies needed to know anything about LAC->LNS tunnel >passwords. > >Barry > >Barry L James | Never doubt that a small group of >IP Systems Engineering | 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 Dec 10 14:42:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01573 for ; Fri, 10 Dec 1999 14:42:24 -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 LAA04154; Fri, 10 Dec 1999 11:37:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA20350 for ietf-radius-outgoing; Fri, 10 Dec 1999 11:39:44 -0800 (PST) Message-Id: <3.0.5.32.19991210113936.0097f8d0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Dec 1999 11:39:36 -0800 To: ietf-radius@livingston.com From: Ignacio Goyret Subject: Re: (radius) Re: Comments on Tunnel Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret Trying a second time, to see if the mailing list filter let's me through. >Date: Fri, 10 Dec 1999 08:41:50 -0800 >To: "Darran Potter" >From: Ignacio Goyret >Subject: Re: (radius) Re: Comments on Tunnel Draft >Cc: "Randy Bush" , "Patrice Calhoun" , > >Ascend (now Lucent) supports Tunnel-Password in all recent versions of >TAOS (MAX and TNT). It is not used for IPSEC or IKE. >-Ignacio > > >At 03:58 PM 12/10/99 -0000, Darran Potter wrote: >>Both UNIX and NT versions of CiscoSecure support the Tunnel-Password. On the >>NT side, at least, we have clients who use it as >>a key part of their business. IOS has has support for a while too. >> >>We also interoperate with Ascend customers who use it. >> >>I'd say removal at this stage would probably upset a lot of people. A lot of our customers would be extremely unhappy, to say the least. >> >>Darran >>dpotter@cisco.com >> >> >>----- Original Message ----- >>From: Randy Bush >>To: Patrice Calhoun >>Cc: >>Sent: Friday, December 10, 1999 3:21 PM >>Subject: (radius) Re: Comments on Tunnel Draft >> >> >>> is the tunnel password feature actually in use? if so, it will be hard to >>> justify removing it from the doc. though it sounds as if a large warning >>> would be well advised. >>> >>> if it is not actually used, or is used in an extemely minor place/way, >>then >>> removing it might be appropriate. if it is removed, a note might go in as >>> a placeholder. >>> >>> randy >>> - >>> 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. >> - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 14:43:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01599 for ; Fri, 10 Dec 1999 14:43: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 LAA04265; Fri, 10 Dec 1999 11:38:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA20452 for ietf-radius-outgoing; Fri, 10 Dec 1999 11:40:25 -0800 (PST) Message-Id: <3.0.5.32.19991210114015.00981b80@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Dec 1999 11:40:15 -0800 To: ietf-radius@livingston.com From: Ignacio Goyret Subject: Re: (radius) Re: Comments on Tunnel Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 11:38 AM 12/10/99 -0500, Ran Atkinson wrote: > >Based on Darran's note, I'd suggest: > - Formally deprecate Tunnel-Password with text explaining > how it means that one gets ZERO effective security, > but keep it documented. Actually recommend that folks > either not implement it or provide a configuration knob > to disable it. > >This means existing users aren't completely hosed and that we've >done our part to make it clear that the usage is insecure as heck >and should go away in future. > >Ran >rja@corp.home.net On the same tone, I presume you are also planning to "deprecate" the Password attribute. After all, it is just as insecure. There are lots of implementations depending on that attribute. If you remove that attribute, you will force the creation of proprietary, non-interoperable solutions to a problem that has already been solved. Many, many customers are going to be quite upset. If you like, add a "Security considerations" section with all the warnings you want, but don't remove a very useful attribute unless you propose a good alternative. -Ignacio ---------- "When the only tool you have is a hammer, all the problems look like nails." - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 14:44:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01614 for ; Fri, 10 Dec 1999 14:44:28 -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 LAA04383; Fri, 10 Dec 1999 11:38:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA20527 for ietf-radius-outgoing; Fri, 10 Dec 1999 11:41:16 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Fri, 10 Dec 1999 14:30 EST Subject: Re: (radius) Comments on Tunnel Draft Content-Type: text/plain Message-ID: <385157070.14d6@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff If the NAS and server knew about each other and shared a secret, there would be no need for proxies. But in the normal proxy case, they don't, so there is no easy way to encrypt Tunnel-Password or User-Password server-to-NAS. However, I've always been slightly amused by the notion of untrusted proxies. Under what circumstance would both the NAS and the ultimate server be trusted, but the proxies not? Everything that Radius does is visible to the NAS and the server, and the NAS sees the caller's data, too. Genuine security is end-to-end, meaning caller's PC to target host. But I don't believe that there has been a collective decision that nothing but end-to-end IPSEC is useful. Barney Wolff > Date: Fri, 10 Dec 1999 19:13:50 +0000 (GMT) > From: Barry James > > Does it make any sense to have a tag that tells the intermediate Proxies > (if there are any) that they are to simply pass the AVP along without > validating the data? Then only the nearest-LAC-RADIUS would have the > trusted relationship with the end-point RADIUS/LNS/whatever and do the > voodoo there? I can see issues with this (one being how does a RADIUS > server know it's the nearest-LAC-RADIUS - maybe it can look at the > NAS-Identifier or IP and if the remote server is the same then it can > possibly assume it's the nearest-LAC-RADIUS) but I never fully understood > why any intermediate proxies needed to know anything about LAC->LNS tunnel > passwords. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 15:14:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02397 for ; Fri, 10 Dec 1999 15:14:58 -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 MAA05102; Fri, 10 Dec 1999 12:09:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA22602 for ietf-radius-outgoing; Fri, 10 Dec 1999 12:11:38 -0800 (PST) Message-Id: <199912102010.PAA22452@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: Ignacio Goyret cc: ietf-radius@livingston.com, rja@corp.home.net Subject: Re: (radius) Re: Comments on Tunnel Draft In-Reply-To: Message from Ignacio Goyret of "Fri, 10 Dec 1999 11:40:15 PST." <3.0.5.32.19991210114015.00981b80@scamp.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Dec 1999 15:10:35 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson Ignacio, Please go back and actually READ what I wrote. You reply made it crystal clear you were having trouble reading what I actually wrote. Thank you very much, Ran - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 15:55:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02953 for ; Fri, 10 Dec 1999 15:55:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA06633; Fri, 10 Dec 1999 12:50:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA24926 for ietf-radius-outgoing; Fri, 10 Dec 1999 12:52:25 -0800 (PST) From: Gopal Dommety Message-Id: <199912102048.MAA07869@omega.cisco.com> Subject: Re: (radius) Comments on Tunnel Draft To: barney@databus.com Date: Fri, 10 Dec 1999 12:48:50 -0800 (PST) Cc: ietf-radius@livingston.com In-Reply-To: <385157070.14d6@databus.databus.com> from "Barney Wolff" at Dec 10, 99 02:30:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Gopal Dommety Content-Transfer-Encoding: 7bit Just to reinforce and continue of Barney's thought... 1. There could be trusted proxies (is is ard to imagine them?). In which case hop-by-hop security might be acceptable to most. 2. If you want end-to-end security, then try to get it from PC to the target host (have a AAA client on the PC). Or do key exchange via other mechanisms. 3. If you don't do it end-to-end, what ever you do, one will always have an entity that has access to the information. What if that entity is untrusted? we can go on forever... So, let us be realistic. People are implementing and using this feature. Most of them understand the issues of hop-by-hop security and also understand the alternatives. If it helps have a statement stating the risk of using this in an hop-by-hop environment. Thanks Gopal > > If the NAS and server knew about each other and shared a secret, there > would be no need for proxies. But in the normal proxy case, they don't, > so there is no easy way to encrypt Tunnel-Password or User-Password > server-to-NAS. > > However, I've always been slightly amused by the notion of untrusted > proxies. Under what circumstance would both the NAS and the ultimate > server be trusted, but the proxies not? Everything that Radius does > is visible to the NAS and the server, and the NAS sees the caller's > data, too. Genuine security is end-to-end, meaning caller's PC to > target host. But I don't believe that there has been a collective > decision that nothing but end-to-end IPSEC is useful. > > Barney Wolff > > > Date: Fri, 10 Dec 1999 19:13:50 +0000 (GMT) > > From: Barry James > > > > Does it make any sense to have a tag that tells the intermediate Proxies > > (if there are any) that they are to simply pass the AVP along without > > validating the data? Then only the nearest-LAC-RADIUS would have the > > trusted relationship with the end-point RADIUS/LNS/whatever and do the > > voodoo there? I can see issues with this (one being how does a RADIUS > > server know it's the nearest-LAC-RADIUS - maybe it can look at the > > NAS-Identifier or IP and if the remote server is the same then it can > > possibly assume it's the nearest-LAC-RADIUS) but I never fully understood > > why any intermediate proxies needed to know anything about LAC->LNS tunnel > > passwords. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 16:14:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03232 for ; Fri, 10 Dec 1999 16:14:32 -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 NAA07288; Fri, 10 Dec 1999 13:09:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA26073 for ietf-radius-outgoing; Fri, 10 Dec 1999 13:11:48 -0800 (PST) Message-Id: <3.0.5.32.19991210131141.0086ce00@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Dec 1999 13:11:41 -0800 To: Gopal Dommety From: Ignacio Goyret Subject: Re: (radius) Comments on Tunnel Draft Cc: barney@databus.com, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 12:48 PM 12/10/99 -0800, Gopal Dommety wrote: >So, let us be realistic. People are implementing and using this >feature. Most of them understand the issues of hop-by-hop security >and also understand the alternatives. If it helps have a statement >stating the risk of using this in an hop-by-hop environment. I agree whole-heartedly. Add a security risk statement and let the people decide what their security policies should be. -Ignacio - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 16:18:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03272 for ; Fri, 10 Dec 1999 16:18: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 NAA07442; Fri, 10 Dec 1999 13:13:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA26254 for ietf-radius-outgoing; Fri, 10 Dec 1999 13:15:25 -0800 (PST) From: Patrice Calhoun Message-Id: <199912102114.NAA15359@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 13:06:23 -0800 To: "Gopal Dommety" Cc: Subject: Re: (radius) Comments on Tunnel Draft X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit > > >Just to reinforce and continue of Barney's thought... > > >1. There could be trusted proxies (is is ard to imagine them?). In >which case hop-by-hop security might be acceptable to most. You know, I trust my admin. She takes care of most of my paperwork and travel plans. Do I provide her with my passwords? There are different levels of trust here. > >2. If you want end-to-end security, then try to get it from PC to the >target host (have a AAA client on the PC). Or do key exchange via >other mechanisms. I would be quite interested in understanding how you would do end to end by having an AAA client on the PC. I wonder how many providers out there would permit end-to-end authentication, and allow the PC to generate accounting information too. So, EAP is the REAL solution here, but we aren't talking about end-to-end authentication, but rather distribution of keys as part of the authorization phase. Now, if you want to enforce end-to-end, simply enfoce voluntary tunneling as opposed to compulsory. I'm not making a statement that compulsory shouldn't be allowed, btw, just responding to Gopal's comments. As I stated earlier, I like this draft, modulo that attribute. > >3. If you don't do it end-to-end, what ever you do, one will always >have an entity that has access to the information. What if that entity >is untrusted? we can go on forever... Well, if you are going to provide compulsory tunneling, then that is the risk you must be willing to take. > >So, let us be realistic. People are implementing and using this >feature. Most of them understand the issues of hop-by-hop security >and also understand the alternatives. If it helps have a statement >stating the risk of using this in an hop-by-hop environment. From some responses to this mailing list, I'm not sure that everyone does in fact understand hop-by-hop security. PatC > > >Thanks >Gopal > > > >> >> If the NAS and server knew about each other and shared a secret, there >> would be no need for proxies. But in the normal proxy case, they don't, >> so there is no easy way to encrypt Tunnel-Password or User-Password >> server-to-NAS. >> >> However, I've always been slightly amused by the notion of untrusted >> proxies. Under what circumstance would both the NAS and the ultimate >> server be trusted, but the proxies not? Everything that Radius does >> is visible to the NAS and the server, and the NAS sees the caller's >> data, too. Genuine security is end-to-end, meaning caller's PC to >> target host. But I don't believe that there has been a collective >> decision that nothing but end-to-end IPSEC is useful. >> >> Barney Wolff >> >> > Date: Fri, 10 Dec 1999 19:13:50 +0000 (GMT) >> > From: Barry James >> > >> > Does it make any sense to have a tag that tells the intermediate Proxies >> > (if there are any) that they are to simply pass the AVP along without >> > validating the data? Then only the nearest-LAC-RADIUS would have the >> > trusted relationship with the end-point RADIUS/LNS/whatever and do the >> > voodoo there? I can see issues with this (one being how does a RADIUS >> > server know it's the nearest-LAC-RADIUS - maybe it can look at the >> > NAS-Identifier or IP and if the remote server is the same then it can >> > possibly assume it's the nearest-LAC-RADIUS) but I never fully understood >> > why any intermediate proxies needed to know anything about LAC->LNS tunnel >> > passwords. >> - >> 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. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 16:47:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03722 for ; Fri, 10 Dec 1999 16:47:29 -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 NAA08112; Fri, 10 Dec 1999 13:42:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA28065 for ietf-radius-outgoing; Fri, 10 Dec 1999 13:44:57 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Fri, 10 Dec 1999 16:26 EST Subject: (radius) Re: tunnel-password brouhaha Content-Type: text/plain Message-ID: <385173fd0.1712@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff I'd like to comment on Pat's implication that Tunnel-Password contains "my" password - as though a nasty proxy that steals it has something of enduring value. We're talking Radius here. The Radius server (or more generally, the node inserting Tunnel-Password in the Access-Accept) knows the NAS from the Access-Request, and knows the tunnel destination, which it is telling the NAS. So it SHOULD generate an ephemeral password and communicate it to the tunnel destination. The password is then useful only from that specific NAS and only for a limited time. If your tunnel server has a long-term password which it accepts from all initiators, you're already in such trouble that Tunnel-Password won't hurt you any more. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 16:54:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03910 for ; Fri, 10 Dec 1999 16:54:29 -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 NAA08339; Fri, 10 Dec 1999 13:49:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA28706 for ietf-radius-outgoing; Fri, 10 Dec 1999 13:51:36 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ignacio Goyret Cc: ietf-radius@livingston.com Subject: Re: (radius) Comments on Tunnel Draft References: <3.0.5.32.19991210131141.0086ce00@scamp.eng.ascend.com> Message-Id: Date: Fri, 10 Dec 1999 13:51:29 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > I agree whole-heartedly. Add a security risk statement and let the > people decide what their security policies should be. given the conversation so far, that seems a reasonable solution. "Note that this uses text passwords sent over the net in the clear. This is a well-known security exposure." randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 17:53:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04653 for ; Fri, 10 Dec 1999 17:53:03 -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 OAA09571; Fri, 10 Dec 1999 14:47:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA02636 for ietf-radius-outgoing; Fri, 10 Dec 1999 14:48:44 -0800 (PST) From: Patrice Calhoun Message-Id: <199912102248.OAA16119@nasnfs.eng.sun.com> Date: Fri, 10 Dec 1999 14:39:52 -0800 To: "Barney Wolff" , Subject: Re: (radius) Re: tunnel-password brouhaha X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit Perhaps my reading of the document was incorrect, but it was my assumption that the Tunnel-Password was a long lived secret. Let's make the assumption that the LNS does NOT have a long lived secret that is made available in the Tunnel-Password attribute. A user dials into a LAC and a request is issued to the home RADIUS server. If the server generates a short lived key (used for tunneling), which is returned back to the LAC, how would the LNS get the key? There is no spi, or key identifier, that the LNS can send to the now stateful RADIUS server. So, as far as I can tell, the existing scheme assumes a long lived secret that the LNS has, which is going to be issued to pretty much any LAC that has a valid user connect to. Is this incorrect? PatC >I'd like to comment on Pat's implication that Tunnel-Password contains >"my" password - as though a nasty proxy that steals it has something of >enduring value. > >We're talking Radius here. The Radius server (or more generally, the >node inserting Tunnel-Password in the Access-Accept) knows the NAS from >the Access-Request, and knows the tunnel destination, which it is >telling the NAS. So it SHOULD generate an ephemeral password and >communicate it to the tunnel destination. The password is then useful >only from that specific NAS and only for a limited time. > >If your tunnel server has a long-term password which it accepts from all >initiators, you're already in such trouble that Tunnel-Password won't >hurt you any more. > >Barney Wolff >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 10 19:05:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05462 for ; Fri, 10 Dec 1999 19:05: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 QAA11268; Fri, 10 Dec 1999 16:00:48 -0800 (PST) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id QAA07113 for ietf-radius-outgoing; Fri, 10 Dec 1999 16:02:08 -0800 (PST) From: Barney Wolff To: Date: Fri, 10 Dec 1999 18:32 EST Subject: Re: (radius) Re: tunnel-password brouhaha Content-Type: text/plain Message-ID: <385194290.1934@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: Patrice Calhoun > Date: Fri, 10 Dec 1999 14:39:52 -0800 > > Let's make the assumption that the LNS does NOT have a long lived secret that > is made available in the Tunnel-Password attribute. A user dials into a LAC > and a request is issued to the home RADIUS server. If the server generates > a short lived key (used for tunneling), which is returned back to the LAC, > how would the LNS get the key? There is no spi, or key identifier, that the > LNS can send to the now stateful RADIUS server. The Radius server and the LNS are certainly under the same administration, or else how does the server know a password for the LNS? Secure communication between them can either be assumed or assured with IPSEC or something like it. (In the case I'm working on now, the LNS is in the same host as a Radius proxy, so communication between them is not difficult.) > So, as far as I can tell, the existing scheme assumes a long lived secret > that the LNS has, which is going to be issued to pretty much any LAC that > has a valid user connect to. > > Is this incorrect? Radius itself, at least in its example implementation, does NOT use a single secret, but has a client table. I don't believe the draft makes any assumption about the promiscuity or lifetime of the tunnel-password. (Obviously, the password lasts as long as the particular tunnel.) After all, if the secret is long-lasting and used by all LACs, it can be distributed by courier (if you're a cockeyed optimist) or just published, if you're a realist. For Heaven's sake, if you don't trust a proxy, why would you trust the NAS to keep a secret? Let's not conflate "hop-by-hop security model" with "every router gets to see it in the clear." Crossing an untrusted network is very different from stopping off in an untrusted proxy. Does anybody actually have a threat mechanism by which Radius can be attacked by a malicious router through which the packets pass? So far as I know, the router can block, modify or forge packets, but cannot get a bogus Accept to be taken by the NAS, or decrypt the Tunnel-Password in it. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 10:02:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08401 for ; Mon, 13 Dec 1999 10:02:08 -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 GAA22575; Mon, 13 Dec 1999 06:56:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA04273 for ietf-radius-outgoing; Mon, 13 Dec 1999 06:54:50 -0800 (PST) Message-Id: <4.2.2.19991213094612.00e46860@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 13 Dec 1999 09:51:38 -0500 To: ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) Comments on Tunnel Draft Cc: Randy Bush In-Reply-To: References: <3.0.5.32.19991210131141.0086ce00@scamp.eng.ascend.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" At 01:51 PM 12/10/99 -0800, Randy Bush wrote: > > I agree whole-heartedly. Add a security risk statement and let the > > people decide what their security policies should be. > >given the conversation so far, that seems a reasonable solution. > >"Note that this uses text passwords sent over the net in the clear. This is >a well-known security exposure." > >randy >- Except, this would be totally incorrect. The draft does not specify that they are "text" nor are they "in-the-clear". The password content can be anything that fits the field (presumably the peers know what they are using) and the field is encrypted using a technique as strong as the main RADIUS password encryption (because it's effectively equivalent). The only security exposure is administrative. This attribute should only be used with clients that you trust to set up tunnel service on your behalf. 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 Mon Dec 13 10:03:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08434 for ; Mon, 13 Dec 1999 10:03: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 GAA22578; Mon, 13 Dec 1999 06:56:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA04317 for ietf-radius-outgoing; Mon, 13 Dec 1999 06:56: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) Comments on Tunnel Draft References: <3.0.5.32.19991210131141.0086ce00@scamp.eng.ascend.com> <4.2.2.19991213094612.00e46860@ZBL6C008.corpeast.baynetworks.com> Message-Id: Date: Mon, 13 Dec 1999 06:53:34 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit >> "Note that this uses text passwords sent over the net in the clear. This is >> a well-known security exposure." > Except, this would be totally incorrect. apologies. you are quite correct. > The only security exposure is administrative. > This attribute should only be used with clients that you trust to set up > tunnel service on your behalf. a much better statement. but it might explain why a bit. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 10:37:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09516 for ; Mon, 13 Dec 1999 10:37: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 HAA23453; Mon, 13 Dec 1999 07:32:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA05783 for ietf-radius-outgoing; Mon, 13 Dec 1999 07:33:09 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "pcalhoun@eng.sun.com" Cc: David Mitton , ietf-radius@livingston.com Subject: Re: (radius) Comments on Tunnel Draft References: Message-Id: Date: Mon, 13 Dec 1999 07:18:38 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit >>> The only security exposure is administrative. >>> This attribute should only be used with clients that you trust to set up >>> tunnel service on your behalf. >> a much better statement. but it might explain why a bit. > I would be willing to accept such a statement, but I would also like to > quantify this by stating that the password made available by the RADIUS > server is likely to be a long-lived password that the LNS is willing to > share with any LAC that has a valid user. > > Of course, if my assumption is incorrect, please do let me know, but this > is my reading of the draft (in between the lines, of course :). would someone please propose correct, concise, and short/simple wording so we can move on? if we can get past this and get a new draft tomorrow in the directory on wednesday, i have a good chance to get it past the iesg on thursday. there have been no other technical comments that i have seen. david, you had the best wording so far. please help. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 12:20:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12342 for ; Mon, 13 Dec 1999 12:20:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA26096; Mon, 13 Dec 1999 09:15:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA11122 for ietf-radius-outgoing; Mon, 13 Dec 1999 09:14:40 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 13 Dec 1999 12:08 EST Subject: (radius) tunnel-password language Content-Type: text/plain Message-ID: <3855292c0.39fd@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff How about: Tunnel-Password is exposed to the NAS and any RADIUS proxies between the server and the NAS. Therefore it SHOULD be ephemeral or unique to the pair of tunnel endpoints, unless the server has great trust in the NAS and every proxy. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 19:49:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21536 for ; Mon, 13 Dec 1999 19:49: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 QAA06507; Mon, 13 Dec 1999 16:44:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA12386 for ietf-radius-outgoing; Mon, 13 Dec 1999 16:46:06 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 13 Dec 1999 19:37 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <385592f80.4362@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Pat, there is nothing in either RADIUS or L2TP that forbids or makes harder than necessary using ephemeral keys. Sure, there is nothing explcit that governs communication between the RADIUS server and the tunnel destination - just as there is nothing explicit that governs communication between the RADIUS server and some external DBMS that holds the user data. What do you see that forbids it? Barney > Date: Mon, 13 Dec 1999 12:52:49 -0800 (PST) > From: "pcalhoun@eng.sun.com" > > > > Tunnel-Password is exposed to the NAS and any RADIUS proxies between > > the server and the NAS. Therefore it SHOULD be ephemeral or unique > > to the pair of tunnel endpoints, unless the server has great trust > > in the NAS and every proxy. > > > But the orotocol doesn't allow that. You cannot support ephemeral keys using > RADIUS and L2TP. > > PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 20:01:40 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21731 for ; Mon, 13 Dec 1999 20:01:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id QAA06923; Mon, 13 Dec 1999 16:56:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA13184 for ietf-radius-outgoing; Mon, 13 Dec 1999 16:59:04 -0800 (PST) From: Patrice Calhoun Message-Id: <199912140058.QAA10037@nasnfs.eng.sun.com> Date: Mon, 13 Dec 1999 16:50:03 -0800 To: "Barney Wolff" , Subject: Re: (radius) tunnel-password language X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit >Pat, there is nothing in either RADIUS or L2TP that forbids or makes >harder than necessary using ephemeral keys. Sure, there is nothing >explcit that governs communication between the RADIUS server and the >tunnel destination - just as there is nothing explicit that governs >communication between the RADIUS server and some external DBMS that >holds the user data. What do you see that forbids it? My understanding, and hopefully I am missing something obvious, is the following: 1. user dials into LAC 2. LAC issues a request to home RADIUS server, and a key is returned 3. LAC establishes an L2TP tunnel with LNS, using the above key. Now, how does the LNS retrieve the key from the RADIUS server? Here are some options: 1. RADIUS server is stateful, and retains the session key in memory so that the LNS can issue a request to the RADIUS server to get the key needed to decypt. I think that this has many problems, especially since one of many RADIUS servers may issue the key, and there is no way for the LNS to know which local server created the key. If the L2TP protocol was able to carry the KDC identifier, then this problem might go away. 2. Have RADIUS return the key encrypted in two ways, one that the LAC can understand, and one that the LNS can decrypt. The LAC issues the LNS encrypted key during tunnel establishment. So my understanding is that unless one of the two above were done (and I am sure that there are other, possible more elegant ways), there is no way for ephemeral keys to be supported. Please let me know if I did miss something, PatC > >Barney > >> Date: Mon, 13 Dec 1999 12:52:49 -0800 (PST) >> From: "pcalhoun@eng.sun.com" >> > >> > Tunnel-Password is exposed to the NAS and any RADIUS proxies between >> > the server and the NAS. Therefore it SHOULD be ephemeral or unique >> > to the pair of tunnel endpoints, unless the server has great trust >> > in the NAS and every proxy. >> > >> But the orotocol doesn't allow that. You cannot support ephemeral keys using >> RADIUS and L2TP. >> >> PatC >- >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 Dec 13 20:18:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21957 for ; Mon, 13 Dec 1999 20:18:10 -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 RAA07418; Mon, 13 Dec 1999 17:13:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA14102 for ietf-radius-outgoing; Mon, 13 Dec 1999 17:15:19 -0800 (PST) From: Barney Wolff To: Date: Mon, 13 Dec 1999 20:08 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <385599d10.4426@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff The way I am doing it is: 1. NAS makes RADIUS request, which gets to the server. 2. Server asks LNS for an ephemeral secret for the NAS-IP. 3. Server returns secret to NAS as Tunnel-Password. 4. NAS/LAC establishes tunnel with LNS using the secret that the LNS is expecting. As I've tried to point out, this is no different in principle from a RADIUS server than needs to query an external database to validate the user, and neither RADIUS nor L2TP has anything to say against it. Barney > From: Patrice Calhoun > Date: Mon, 13 Dec 1999 16:50:03 -0800 > > So my understanding is that unless one of the two above were done (and I am > sure that there are other, possible more elegant ways), there is no way for > ephemeral keys to be supported. > > Please let me know if I did miss something, > > PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 20:39:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22146 for ; Mon, 13 Dec 1999 20:39: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 RAA07888; Mon, 13 Dec 1999 17:34:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA15026 for ietf-radius-outgoing; Mon, 13 Dec 1999 17:34:16 -0800 (PST) From: Patrice Calhoun Message-Id: <199912140133.RAA10369@nasnfs.eng.sun.com> Date: Mon, 13 Dec 1999 17:25:09 -0800 To: "Barney Wolff" , Subject: Re: (radius) tunnel-password language X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit ..and fwiw, customers cannot expect interoperability in this case, which MAY be more important then a server's database interface. If a customer uses the same vendor's RADIUS server and LNS, then he/she is ok. Otherwise, ephemeral keys are not supported. Whereas, a customer buys the RADIUS server and gets the backend database he/she gets with the server. Right? PatC >The way I am doing it is: > >1. NAS makes RADIUS request, which gets to the server. >2. Server asks LNS for an ephemeral secret for the NAS-IP. >3. Server returns secret to NAS as Tunnel-Password. >4. NAS/LAC establishes tunnel with LNS using the secret that the LNS > is expecting. > >As I've tried to point out, this is no different in principle from >a RADIUS server than needs to query an external database to validate >the user, and neither RADIUS nor L2TP has anything to say against it. > >Barney > >> From: Patrice Calhoun >> Date: Mon, 13 Dec 1999 16:50:03 -0800 >> >> So my understanding is that unless one of the two above were done (and I am >> sure that there are other, possible more elegant ways), there is no way for >> ephemeral keys to be supported. >> >> Please let me know if I did miss something, >> >> PatC >- >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 Dec 13 21:30:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22556 for ; Mon, 13 Dec 1999 21:30:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id SAA08677; Mon, 13 Dec 1999 18:25:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA16945 for ietf-radius-outgoing; Mon, 13 Dec 1999 18:24:51 -0800 (PST) Message-Id: <3.0.5.32.19991213182435.0109fb20@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Dec 1999 18:24:35 -0800 To: Patrice Calhoun From: Ignacio Goyret Subject: Re: (radius) tunnel-password language Cc: "Barney Wolff" , In-Reply-To: <199912140058.QAA10037@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret Pat, Barney, I think the important part of Pat's problem may be with the use of the word 'key' in the L2TP context. There is no L2TP key. It is just a password, and it is no different than a regular user password. If you allow a RADIUS to server to send a user password to a NAS, there is nothing wrong with allowing that same RADIUS server to tell the NAS the password it must use to access a particular L2TP server. The L2TP control channel has a mechanism to 'hide' AVPs. This mechanism is not stronger than CHAP. Customers that choose to 'hide' AVPs know (or should be told) that hiding is not encrypting. Hiding is intended to limit the amount of stuff that humans can read directly off a network trace, and nothing more. It is not intended to provide encryption nor full security. As the L2TP RFC clearly indicates, if you want full security including encryption (for example, because you don't trust your proxy RADIUS servers), then you better use IPSEC. Does this help? -Ignacio At 04:50 PM 12/13/99 -0800, Patrice Calhoun wrote: >My understanding, and hopefully I am missing something obvious, is the >following: > >1. user dials into LAC >2. LAC issues a request to home RADIUS server, and a key is returned >3. LAC establishes an L2TP tunnel with LNS, using the above key. Remember, there is no 'key' in L2TP: there is just a password to access the L2TP service on the remote's tunnel endpoint. There is no encryption. >Now, how does the LNS retrieve the key from the RADIUS server? Here are >some options: > >1. RADIUS server is stateful, and retains the session key in memory so >that the LNS can issue a request to the RADIUS server to get the key needed >to decypt. I think that this has many problems, especially since one of many >RADIUS servers may issue the key, and there is no way for the LNS to know >which local server created the key. If the L2TP protocol was able to carry >the KDC identifier, then this problem might go away. > >2. Have RADIUS return the key encrypted in two ways, one that the LAC >can understand, and one that the LNS can decrypt. The LAC issues the LNS >encrypted key during tunnel establishment. > >So my understanding is that unless one of the two above were done (and I am >sure that there are other, possible more elegant ways), there is no way for >ephemeral keys to be supported. > >Please let me know if I did miss something, > >PatC >> >>Barney >> >>> Date: Mon, 13 Dec 1999 12:52:49 -0800 (PST) >>> From: "pcalhoun@eng.sun.com" >>> > >>> > Tunnel-Password is exposed to the NAS and any RADIUS proxies between >>> > the server and the NAS. Therefore it SHOULD be ephemeral or unique >>> > to the pair of tunnel endpoints, unless the server has great trust >>> > in the NAS and every proxy. >>> > >>> But the orotocol doesn't allow that. You cannot support ephemeral keys using >>> RADIUS and L2TP. >>> >>> PatC >>- >>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. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 21:38:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22706 for ; Mon, 13 Dec 1999 21:38:08 -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 SAA08917; Mon, 13 Dec 1999 18:33:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA17260 for ietf-radius-outgoing; Mon, 13 Dec 1999 18:32:45 -0800 (PST) Message-Id: <3.0.5.32.19991213183228.00831650@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Dec 1999 18:32:28 -0800 To: Patrice Calhoun , "Barney Wolff" From: Ignacio Goyret Subject: Re: (radius) tunnel-password language Cc: In-Reply-To: <3.0.5.32.19991213182435.0109fb20@scamp.eng.ascend.com> References: <199912140058.QAA10037@nasnfs.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 06:24 PM 12/13/99 -0800, Ignacio Goyret wrote: >Pat, Barney, >I think the important part of Pat's problem may be with the use of the >word 'key' in the L2TP context. There is no L2TP key. It is just a password, >and it is no different than a regular user password. If you allow a RADIUS >to server to send a user password to a NAS, there is nothing wrong with Err, I meant to say "...If you allow a NAS to send a user password to a RADIUS server, ..." :-) >allowing that same RADIUS server to tell the NAS the password it must use >to access a particular L2TP server. > >The L2TP control channel has a mechanism to 'hide' AVPs. This mechanism is >not stronger than CHAP. Customers that choose to 'hide' AVPs know (or should >be told) that hiding is not encrypting. Hiding is intended to limit the >amount of stuff that humans can read directly off a network trace, and nothing >more. It is not intended to provide encryption nor full security. > >As the L2TP RFC clearly indicates, if you want full security including encryption >(for example, because you don't trust your proxy RADIUS servers), then you better >use IPSEC. > >Does this help? >-Ignacio > > >At 04:50 PM 12/13/99 -0800, Patrice Calhoun wrote: >>My understanding, and hopefully I am missing something obvious, is the >>following: >> >>1. user dials into LAC >>2. LAC issues a request to home RADIUS server, and a key is returned >>3. LAC establishes an L2TP tunnel with LNS, using the above key. > >Remember, there is no 'key' in L2TP: there is just a password to access >the L2TP service on the remote's tunnel endpoint. There is no encryption. > > >>Now, how does the LNS retrieve the key from the RADIUS server? Here are >>some options: >> >>1. RADIUS server is stateful, and retains the session key in memory so >>that the LNS can issue a request to the RADIUS server to get the key needed >>to decypt. I think that this has many problems, especially since one of many >>RADIUS servers may issue the key, and there is no way for the LNS to know >>which local server created the key. If the L2TP protocol was able to carry >>the KDC identifier, then this problem might go away. >> >>2. Have RADIUS return the key encrypted in two ways, one that the LAC >>can understand, and one that the LNS can decrypt. The LAC issues the LNS >>encrypted key during tunnel establishment. >> >>So my understanding is that unless one of the two above were done (and I am >>sure that there are other, possible more elegant ways), there is no way for >>ephemeral keys to be supported. >> >>Please let me know if I did miss something, >> >>PatC >>> >>>Barney >>> >>>> Date: Mon, 13 Dec 1999 12:52:49 -0800 (PST) >>>> From: "pcalhoun@eng.sun.com" >>>> > >>>> > Tunnel-Password is exposed to the NAS and any RADIUS proxies between >>>> > the server and the NAS. Therefore it SHOULD be ephemeral or unique >>>> > to the pair of tunnel endpoints, unless the server has great trust >>>> > in the NAS and every proxy. >>>> > >>>> But the orotocol doesn't allow that. You cannot support ephemeral keys using >>>> RADIUS and L2TP. >>>> >>>> PatC >>>- >>>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. >> >- >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 Dec 13 21:59:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23755 for ; Mon, 13 Dec 1999 21:59:32 -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 SAA09339; Mon, 13 Dec 1999 18:54:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA18101 for ietf-radius-outgoing; Mon, 13 Dec 1999 18:56:58 -0800 (PST) From: Barney Wolff To: Date: Mon, 13 Dec 1999 21:49 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <3855b1a50.455f@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Pat, you're hard to put down, but I've got you now! I configure my network so the LNS is the RADIUS proxy. The LNS gets the Access-Request, sends it on to the server with the user database. When the LNS gets the Access-Accept, it adds the ephemeral secret and sends the Access-Accept back to the NAS. My LNS can work with any RADIUS server and any NAS. Now can we put some language in the draft and move on? Regards, Barney > From: Patrice Calhoun > Date: Mon, 13 Dec 1999 17:25:09 -0800 > > ..and fwiw, customers cannot expect interoperability in this case, which > MAY be more important then a server's database interface. If a customer > uses the same vendor's RADIUS server and LNS, then he/she is ok. Otherwise, > ephemeral keys are not supported. > > Whereas, a customer buys the RADIUS server and gets the backend database > he/she gets with the server. > > Right? > > PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 13 22:15:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23904 for ; Mon, 13 Dec 1999 22:15:44 -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 TAA09755; Mon, 13 Dec 1999 19:10:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id TAA18663 for ietf-radius-outgoing; Mon, 13 Dec 1999 19:13:13 -0800 (PST) From: Barney Wolff To: Date: Mon, 13 Dec 1999 21:58 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <3855b5670.45bc@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Ignacio, you are now the second person to claim (the first privately) that RADIUS (and equivalently, L2TP) hiding is not serious encryption. But nobody has come forward with any attack on the encryption mechanism in either protocol. Until someone does, and the attack looks credible, this amounts to FUD with no visible basis. If I know someone is sniffing RADIUS, I'd much rather use PAP than CHAP, because at least with PAP the "hiding" of the user password depends on a shared secret under my control. With CHAP, a sniffed Access-Request allows a dictionary attack on the user's password, which may not be well-chosen. And that dictionary attack will be far faster than the traditional one on /etc/passwd, because MD5 is so much faster than crypt(). Regards, Barney > Date: Mon, 13 Dec 1999 18:24:35 -0800 > From: Ignacio Goyret > > Pat, Barney, > I think the important part of Pat's problem may be with the use of the > word 'key' in the L2TP context. There is no L2TP key. It is just a password, > and it is no different than a regular user password. If you allow a RADIUS > to server to send a user password to a NAS, there is nothing wrong with > allowing that same RADIUS server to tell the NAS the password it must use > to access a particular L2TP server. > > The L2TP control channel has a mechanism to 'hide' AVPs. This mechanism is > not stronger than CHAP. Customers that choose to 'hide' AVPs know (or should > be told) that hiding is not encrypting. Hiding is intended to limit the > amount of stuff that humans can read directly off a network trace, and nothing > more. It is not intended to provide encryption nor full security. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 09:37:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18744 for ; Tue, 14 Dec 1999 09:37:53 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA16855; Tue, 14 Dec 1999 06:32:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA07303 for ietf-radius-outgoing; Tue, 14 Dec 1999 06:33:56 -0800 (PST) Message-Id: <199912141432.JAA03355@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: Barney Wolff cc: ietf-radius@livingston.com Subject: Re: (radius) tunnel-password language In-Reply-To: Message from Barney Wolff of "Mon, 13 Dec 1999 21:58:00 EST." <3855b5670.45bc@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 09:32:56 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson % Ignacio, you are now the second person to claim (the first privately) % that RADIUS (and equivalently, L2TP) hiding is not serious encryption. % But nobody has come forward with any attack on the encryption mechanism % in either protocol. Until someone does, and the attack looks credible, % this amounts to FUD with no visible basis. Barney, It would be irresponsible to publish the attack in a full-documentation manner at this point. Step one of working within the system is the effort that several folks are making here to get the risks more clearly and crisply documented. An average reader of the current RADIUS RFCs and I-Ds will not come away with the grasp that the system is fundamentally a "scrambler" rather than a real "security" mechanism. The claim that RADIUS does not provide effective privacy is not new and has been made repeatedly in public IETF fora -- in the context of proposals to use RADIUS for IPsec key management, to give one example of many. If an attack were published today, then every RADIUS server in operational use becomes vulnerable. Thus, it is not responsible behaviour (IMHO) to publish an attack in this kind of situation; it is most decidedly NOT FUD. Your turning a reasonable technical point that Ignacio (and others) have tried to make into an ad hominem comment about FUD was disappointing. Yours, Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 09:39:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18800 for ; Tue, 14 Dec 1999 09:39: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 GAA16972; Tue, 14 Dec 1999 06:34:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA07401 for ietf-radius-outgoing; Tue, 14 Dec 1999 06:37:26 -0800 (PST) Message-Id: <4.2.2.19991214092922.00cb8230@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Dec 1999 09:32:54 -0500 To: Barney Wolff , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) tunnel-password language In-Reply-To: <3855292c0.39fd@databus.databus.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" At 12:08 PM 12/13/99 -0500, Barney Wolff wrote: >How about: > >Tunnel-Password is exposed to the NAS and any RADIUS proxies between >the server and the NAS. Therefore it SHOULD be ephemeral or unique >to the pair of tunnel endpoints, unless the server has great trust >in the NAS and every proxy. > >Barney Wolff >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. This is good. I would also like to see added something before this statement to the effect of: Use of this attribute could have serious security implications. Please read the section below on "Security Considerations". That section already has spelled out the basic issues. 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 Tue Dec 14 12:02:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24147 for ; Tue, 14 Dec 1999 12:02: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 IAA20181; Tue, 14 Dec 1999 08:57:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA14629 for ietf-radius-outgoing; Tue, 14 Dec 1999 08:58:58 -0800 (PST) From: Barney Wolff To: Date: Tue, 14 Dec 1999 11:55 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <385676f30.4eda@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff To paraphrase a famous adage of computer science, there's nothing in RADIUS that can't be solved by introducing another level of proxy. :) Peace, Barney > From: Patrice Calhoun > Date: Tue, 14 Dec 1999 07:14:10 -0800 > > Of course, that means that all of the RADIUS servers outside of your > domain share a security association with all of your LNSes in your > network, which sounds unmanageable, and unscalable (sp?). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 12:02:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24146 for ; Tue, 14 Dec 1999 12:02: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 IAA20183; Tue, 14 Dec 1999 08:57:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA14512 for ietf-radius-outgoing; Tue, 14 Dec 1999 08:57:20 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 14 Dec 1999 11:23 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <385676840.4eb7@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Ran, if this attack is real, then whenever it is published there will be much emergency work to repair the breach. But until enough is published to indicate what needs to be changed, no such work can be started. Therefore, postponing revealing the attack does nothing to help anybody. And of course, it it's real it can be rediscovered by a bad guy, who will quietly vacuum up lots of user passwords until the attack becomes known. If you really believe there is benefit to keeping the attack quiet, what actions by owners or producers of RADIUS gear should be taking place while we wait? Other, of course, than just abandoning RADIUS, or running it over IPSEC? I know that the IPSEC WG was adamantly opposed to using RADIUS for IPSEC key distribution, and I would not wish to make any claim that RADIUS encryption is as bulletproof as IPSEC. But that's very different from claiming that there is an attack on it. I'm sorry, but the bald assertion that breaking RADIUS-style encryption is child's-play is not a "reasonable technical point" without a testable indication of *how* it's child's-play. Regards, Barney > To: Barney Wolff > Cc: ietf-radius@livingston.com > Subject: Re: (radius) tunnel-password language > Content-Length: 1388 > Date: Tue, 14 Dec 1999 09:32:56 -0500 > From: Ran Atkinson > > % Ignacio, you are now the second person to claim (the first privately) > % that RADIUS (and equivalently, L2TP) hiding is not serious encryption. > % But nobody has come forward with any attack on the encryption mechanism > % in either protocol. Until someone does, and the attack looks credible, > % this amounts to FUD with no visible basis. > > Barney, > > It would be irresponsible to publish the attack in a > full-documentation manner at this point. Step one of working > within the system is the effort that several folks are making here > to get the risks more clearly and crisply documented. An average reader > of the current RADIUS RFCs and I-Ds will not come away with the grasp > that the system is fundamentally a "scrambler" rather than a real > "security" mechanism. > > The claim that RADIUS does not provide effective privacy > is not new and has been made repeatedly in public IETF fora > -- in the context of proposals to use RADIUS for IPsec key management, > to give one example of many. > > If an attack were published today, then every RADIUS server in > operational use becomes vulnerable. Thus, it is not responsible > behaviour (IMHO) to publish an attack in this kind of situation; > it is most decidedly NOT FUD. > > Your turning a reasonable technical point that Ignacio (and > others) have tried to make into an ad hominem comment about > FUD was disappointing. > > Yours, > > Ran > rja@corp.home.net > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 12:28:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25016 for ; Tue, 14 Dec 1999 12:28:42 -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 JAA20895; Tue, 14 Dec 1999 09:23:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA16333 for ietf-radius-outgoing; Tue, 14 Dec 1999 09:25:50 -0800 (PST) Message-Id: <199912141724.MAA04325@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: Barney Wolff cc: ietf-radius@livingston.com Subject: Re: (radius) tunnel-password language In-Reply-To: Message from Barney Wolff of "Tue, 14 Dec 1999 11:23:00 EST." <385676840.4eb7@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 12:24:51 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson Barney, The root problem is the way RADIUS performs "encryption", as has been noted before in various IETF fora. Details of the attack ought NOT be noted here in public until things get fixed in the spec and in implementations (thus giving operators a fighting chance of closing the hole before a truck gets driven through their RADIUS-based systems). The current (pseudo-)cryptographic part of RADIUS needs to be replaced. Dropping in a real encryption algorithm into RADIUS, along with a shared key between endpoints would resolve/mitigate the non-proxy aspects of RADIUS confidentiality somewhat, for example. This is feasible without changing the protocol radically. It would involve changing running code in lots of implementations. I surely haven't advocated "just protect RADIUS with IPsec"; I haven't seen others suggest it here (perhaps I missed an email ?). Yours, Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 12:53:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25497 for ; Tue, 14 Dec 1999 12:53:16 -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 JAA21392; Tue, 14 Dec 1999 09:43:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA17519 for ietf-radius-outgoing; Tue, 14 Dec 1999 09:42:30 -0800 (PST) Message-Id: <199912141741.MAA04429@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: Ran Atkinson cc: ietf-radius@livingston.com Subject: (radius) Proposed Addition to Security Considerations In-Reply-To: Message from Ran Atkinson of "Tue, 14 Dec 1999 12:24:51 EST." <199912141724.MAA04325@dragonfly.corp.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Dec 1999 12:41:30 -0500 From: Ran Atkinson Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ran Atkinson I propose that we add the following text to Security Considerations: "The password scrambling 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 to passwords and other forms of keys transmitted using RADIUS. Users should evaluate their threat environment and consider whether additional security mechanisms (e.g. one-time passwords [RFC-2289]) should be employed within RADIUS to reduce the risk of break-in due to potential compromise of the RADIUS scrambling scheme." Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 14 12:55:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25537 for ; Tue, 14 Dec 1999 12:55:57 -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 JAA21666; Tue, 14 Dec 1999 09:50:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA18187 for ietf-radius-outgoing; Tue, 14 Dec 1999 09:50:06 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 14 Dec 1999 12:42 EST Subject: Re: (radius) tunnel-password language Content-Type: text/plain Message-ID: <385682fa0.5150@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Ok, I'm going to stop now (I'm sure others wish I had stopped long ago). If I interpret your message correctly, someone is going to generate an ID proposing a new encryption algorithm for RADIUS without saying what's wrong with the existing one, and the WG will adopt it with alacrity and gratitude. Then when everybody's updated, people beyond some inner circle will be told what the problem was. Yours in expectation, Barney > Date: Tue, 14 Dec 1999 12:24:51 -0500 > From: Ran Atkinson > > Details of the attack ought NOT be noted here in public until things > get fixed in the spec and in implementations (thus giving operators > a fighting chance of closing the hole before a truck gets driven > through their RADIUS-based systems). > > The current (pseudo-)cryptographic part of RADIUS needs to be > replaced. Dropping in a real encryption algorithm into RADIUS, along with > a shared key between endpoints would resolve/mitigate the non-proxy aspects > of RADIUS confidentiality somewhat, for example. This is feasible > without changing the protocol radically. It would involve changing > running code in lots of implementations. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 14:54:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08525 for ; Thu, 16 Dec 1999 14:54:50 -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 LAA08284; Thu, 16 Dec 1999 11:48:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA29683 for ietf-radius-outgoing; Thu, 16 Dec 1999 11: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) documents wedge over track confusion Message-Id: Date: Thu, 16 Dec 1999 11:45:34 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit some documents have wedged at the iesg. essentially we became confused which track they were or should be on. the confusion seems to be that some of the documents seem to specify protocol, use words like MUST etc., but have been called as informational. bernard tells me that this is because they rely on rfc2139 which is informational, and was so classified because the specified transport was feared not to be sufficiently reliable. an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended to replace 2139, and if it solves 2139's problems sufficiently to be standards track and therefore clear the logjam. i will append my notes as of last eve. randy o RADIUS Extensions [Informational] relies on 2139 which is infomational. but this one might be experimental because This memo suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental. but wg chair asked for info. o Implementation of L2TP Compulsory Tunneling via RADIUS [Informational] should be proposed standard, because it specifies protocol, uses MUST, etc., but was requested as informational. it says: This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. o RADIUS Accounting Modifications for Tunnel Protocol Support [Informational] relies on 2139 which is infomational, and i was told to ask as info and it sez info on the draft. but it looks like it specifies protocol. o RADIUS Accounting [Informational] Note: Requires draft-ietf-radius-tunnel-auth relies on 2139 so should be informational. but it looks like a proposed standard, though the wg chair asked for informational. it says: This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. -30- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 17:41:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11181 for ; Thu, 16 Dec 1999 17:41:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id OAA12040; Thu, 16 Dec 1999 14:36:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA10420 for ietf-radius-outgoing; Thu, 16 Dec 1999 14:38:20 -0800 (PST) From: Carl Rigney Date: Thu, 16 Dec 1999 14:35:41 -0800 (PST) Message-Id: <199912162235.OAA23895@artemis.livingston.com> To: randy@psg.com Subject: Re: (radius) documents wedge over track confusion Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney (Primarily to Randy Bush, but cc'ed to the mailing list for those interested.) > an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended > to replace 2139 It is intended to replace 2139. When RADIUS and RADIUS Accounting were submitted to the IESG long ago (to become 2058 and 2059) the IESG at that time asked that RADIUS Accounting be done as informational instead of proposed standard. Since the RADIUS Accounting client uses acknowledged buffered UDP (storing packets locally and retransmitting until acknowledged) it's been very reliable in practice. I'd be quite happy to have RADIUS Accounting enter the standards track, if the IESG would prefer that, or to remain informational. Thousands of ISPS have been using it for years to account for millions of users, so in practice it's been very solid. If the IESG is more comfortable classifying RADIUS Extensions as "Experimental" than "Informational" that's fine by me; Experimental better captures its nature. The intent is to describe some more attributes that are being used, but that not everyone is likely to want (The Appletalk Remote Access attributes are very useful to vendors that implement ARA, and not of interest to vendors that don't, for example). Note that nothing in the RADIUS draft depends on the Accounting draft, it just allocates numbers for accounting and provides a pointer to the other draft to define their usage. Likewise nothing in the Extensions draft depends on the tunneling drafts, it just mentions which attribute numbers are reserved for use by tunneling and provides a pointer to the draft defining them, because I thought it would be convenient for implementers to know where to go to find each attribute. If that tangles things up I could rip the pointers back out, but I'd prefer to leave the pointers in - cross-references are a good thing when future implementers try to figure out what's where. -- Carl Rigney cdr@livingston.com 925-737-2111 >From owner-ietf-radius Thu Dec 16 11:50:41 1999 >From: Randy Bush >To: ietf-radius@livingston.com >Subject: (radius) documents wedge over track confusion >Message-Id: >Date: Thu, 16 Dec 1999 11:45:34 -0800 >Sender: owner-ietf-radius@livingston.com > >some documents have wedged at the iesg. essentially we became confused >which track they were or should be on. > >the confusion seems to be that some of the documents seem to specify >protocol, use words like MUST etc., but have been called as informational. >bernard tells me that this is because they rely on rfc2139 which is >informational, and was so classified because the specified transport was >feared not to be sufficiently reliable. > >an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended >to replace 2139, and if it solves 2139's problems sufficiently to be >standards track and therefore clear the logjam. > >i will append my notes as of last eve. > >randy > > o RADIUS Extensions [Informational] > > >relies on 2139 which is infomational. > >but this one might be experimental because > >This memo suggests several additional Attributes that can be added to >RADIUS to perform various useful functions. These Attributes do not >have extensive field experience yet and should therefore be >considered experimental. > >but wg chair asked for info. > > o Implementation of L2TP Compulsory Tunneling via RADIUS > [Informational] > > >should be proposed standard, because it specifies protocol, uses MUST, etc., >but was requested as informational. it says: > >This document discusses implementation issues arising in the >provisioning of compulsory tunneling in dial-up networks using the L2TP >protocol. This provisioning can be accomplished via the integration of >RADIUS and tunneling protocols. Implementation issues encountered with >other tunneling protocols are left to separate documents. > > o RADIUS Accounting Modifications for Tunnel Protocol > Support [Informational] > > >relies on 2139 which is infomational, and i was told to ask as info and it >sez info on the draft. but it looks like it specifies protocol. > > o RADIUS Accounting [Informational] > > Note: Requires draft-ietf-radius-tunnel-auth > >relies on 2139 so should be informational. but it looks like a proposed >standard, though the wg chair asked for informational. it says: > >This document describes a protocol for carrying accounting information >between a Network Access Server and a shared Accounting Server. > >-30- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 18:08:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11519 for ; Thu, 16 Dec 1999 18:08:03 -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 PAA12757; Thu, 16 Dec 1999 15:02:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA11693 for ietf-radius-outgoing; Thu, 16 Dec 1999 15:00:28 -0800 (PST) From: Carl Rigney Date: Thu, 16 Dec 1999 14:57:46 -0800 (PST) Message-Id: <199912162257.OAA24224@artemis.livingston.com> To: barney@databus.com Subject: Re: (radius) Comments on Tunnel Draft Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney barney@databus.com writes: > Genuine security is end-to-end, meaning caller's PC to > target host. But I don't believe that there has been a collective > decision that nothing but end-to-end IPSEC is useful. Very well said. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 18:47:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11964 for ; Thu, 16 Dec 1999 18:47:32 -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 PAA13334; Thu, 16 Dec 1999 15:36:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA13910 for ietf-radius-outgoing; Thu, 16 Dec 1999 15:37:11 -0800 (PST) Message-Id: <4.2.2.19991216152909.00ace220@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Dec 1999 15:36:41 -0800 To: Randy Bush From: Matt Holdrege Subject: Re: (radius) documents wedge over track confusion Cc: ietf-radius@livingston.com 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: Matt Holdrege I think they should all be standards track. Both Radius and Radius accounting should be draft standard and the others should be proposed standard. I recall that the reason Radius accounting was made Informational was that previous AD's were very much concerned with the risks associated with billing systems relying on this RFC. But time has shown that a great many ISP's serving tens of millions of users are happily using RFC 2139 today. It has achieved widespread interoperability as well. I expect some will disagree and point at wording problems and/or threat theories, but reality should be our guide here. Both protocols are essentially at the same state as some other Full Standard protocols in terms of implementation and utilizations. Let's not quibble over political or publishing issues. Radius is what it is and nothing we do or the IESG does can change how it is used today. The alternative is that we have a delta between what the IETF publishes and what happens on the real Internet. That is not a good thing. At 11:45 AM 12/16/99 -0800, Randy Bush wrote: >some documents have wedged at the iesg. essentially we became confused >which track they were or should be on. > >the confusion seems to be that some of the documents seem to specify >protocol, use words like MUST etc., but have been called as informational. >bernard tells me that this is because they rely on rfc2139 which is >informational, and was so classified because the specified transport was >feared not to be sufficiently reliable. > >an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended >to replace 2139, and if it solves 2139's problems sufficiently to be >standards track and therefore clear the logjam. > >i will append my notes as of last eve. > >randy > > > > o RADIUS Extensions [Informational] > > >relies on 2139 which is infomational. > >but this one might be experimental because > >This memo suggests several additional Attributes that can be added to >RADIUS to perform various useful functions. These Attributes do not >have extensive field experience yet and should therefore be >considered experimental. > >but wg chair asked for info. > > > o Implementation of L2TP Compulsory Tunneling via RADIUS > [Informational] > > >should be proposed standard, because it specifies protocol, uses MUST, etc., >but was requested as informational. it says: > >This document discusses implementation issues arising in the >provisioning of compulsory tunneling in dial-up networks using the L2TP >protocol. This provisioning can be accomplished via the integration of >RADIUS and tunneling protocols. Implementation issues encountered with >other tunneling protocols are left to separate documents. > > > o RADIUS Accounting Modifications for Tunnel Protocol > Support [Informational] > > >relies on 2139 which is infomational, and i was told to ask as info and it >sez info on the draft. but it looks like it specifies protocol. > > > o RADIUS Accounting [Informational] > > Note: Requires draft-ietf-radius-tunnel-auth > >relies on 2139 so should be informational. but it looks like a proposed >standard, though the wg chair asked for informational. it says: > >This document describes a protocol for carrying accounting information >between a Network Access Server and a shared Accounting Server. > >-30- >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 18:55:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12133 for ; Thu, 16 Dec 1999 18:55: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 PAA13613; Thu, 16 Dec 1999 15:49:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA14704 for ietf-radius-outgoing; Thu, 16 Dec 1999 15:50:50 -0800 (PST) Message-Id: <4.2.2.19991216154953.00af0710@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Dec 1999 15:50:31 -0800 To: randy@psg.com From: Matt Holdrege Subject: Re: (radius) documents wedge over track confusion Cc: ietf-radius@livingston.com In-Reply-To: <4.2.2.19991216152909.00ace220@porky> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege Oops I missed the Radius extensions draft. I agree that should be Experimental. At 03:36 PM 12/16/99 -0800, Matt Holdrege wrote: >I think they should all be standards track. Both Radius and Radius >accounting should be draft standard and the others should be proposed standard. > >I recall that the reason Radius accounting was made Informational was that >previous AD's were very much concerned with the risks associated with >billing systems relying on this RFC. But time has shown that a great many >ISP's serving tens of millions of users are happily using RFC 2139 today. >It has achieved widespread interoperability as well. > >I expect some will disagree and point at wording problems and/or threat >theories, but reality should be our guide here. Both protocols are >essentially at the same state as some other Full Standard protocols in >terms of implementation and utilizations. > >Let's not quibble over political or publishing issues. Radius is what it >is and nothing we do or the IESG does can change how it is used today. The >alternative is that we have a delta between what the IETF publishes and >what happens on the real Internet. That is not a good thing. > > >At 11:45 AM 12/16/99 -0800, Randy Bush wrote: >>some documents have wedged at the iesg. essentially we became confused >>which track they were or should be on. >> >>the confusion seems to be that some of the documents seem to specify >>protocol, use words like MUST etc., but have been called as informational. >>bernard tells me that this is because they rely on rfc2139 which is >>informational, and was so classified because the specified transport was >>feared not to be sufficiently reliable. >> >>an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended >>to replace 2139, and if it solves 2139's problems sufficiently to be >>standards track and therefore clear the logjam. >> >>i will append my notes as of last eve. >> >>randy >> >> >> >> o RADIUS Extensions [Informational] >> >> >>relies on 2139 which is infomational. >> >>but this one might be experimental because >> >>This memo suggests several additional Attributes that can be added to >>RADIUS to perform various useful functions. These Attributes do not >>have extensive field experience yet and should therefore be >>considered experimental. >> >>but wg chair asked for info. >> >> >> o Implementation of L2TP Compulsory Tunneling via RADIUS >> [Informational] >> >> >>should be proposed standard, because it specifies protocol, uses MUST, etc., >>but was requested as informational. it says: >> >>This document discusses implementation issues arising in the >>provisioning of compulsory tunneling in dial-up networks using the L2TP >>protocol. This provisioning can be accomplished via the integration of >>RADIUS and tunneling protocols. Implementation issues encountered with >>other tunneling protocols are left to separate documents. >> >> >> o RADIUS Accounting Modifications for Tunnel Protocol >> Support [Informational] >> >> >>relies on 2139 which is infomational, and i was told to ask as info and it >>sez info on the draft. but it looks like it specifies protocol. >> >> >> o RADIUS Accounting [Informational] >> >> Note: Requires draft-ietf-radius-tunnel-auth >> >>relies on 2139 so should be informational. but it looks like a proposed >>standard, though the wg chair asked for informational. it says: >> >>This document describes a protocol for carrying accounting information >>between a Network Access Server and a shared Accounting Server. >> >>-30- >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 19:03:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12252 for ; Thu, 16 Dec 1999 19:03:22 -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 PAA13827; Thu, 16 Dec 1999 15:57:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA15039 for ietf-radius-outgoing; Thu, 16 Dec 1999 15:57:02 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege , Dave McNamee Cc: ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: <4.2.2.19991216152909.00ace220@porky> <012f01bf481d$d6cc54f0$527646ab@DMCNAMEEPC> Message-Id: Date: Thu, 16 Dec 1999 15:56:09 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit it would sure be nice to have users, as opposed to vendors, telling us how happy the users are. and a statement such as > I expect some will disagree and point at ... threat theories, but reality > should be our guide here. is a very convincing argument. but i suspect you might not like that for which it convinces me and at least some other folk responsible for large networks. the network has *very* serious security problems, and they are not on the wane. we are trying to manage some drafts through the process. this should be done with prudence and as much technical excellence as we can muster. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 19:28:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12624 for ; Thu, 16 Dec 1999 19:28: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 QAA14564; Thu, 16 Dec 1999 16:22:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA16583 for ietf-radius-outgoing; Thu, 16 Dec 1999 16:24:10 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Thu, 16 Dec 1999 19:15 EST Subject: Re: (radius) documents wedge over track confusion Content-Type: text/plain Message-ID: <385982a20.ae8@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Well, I contract for a fairly large ISP, with annual dial revenue in the $several-hundred-million range. Every call journal comes out of the NAS via RADIUS. Every caller is authenticated via RADIUS. Nobody in five years has ever suggested that we use anything else. Ok? Barney Wolff > Date: Thu, 16 Dec 1999 15:56:09 -0800 > From: Randy Bush > it would sure be nice to have users, as opposed to vendors, telling us how > happy the users are. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 20:11:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13267 for ; Thu, 16 Dec 1999 20:11:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id RAA15862; Thu, 16 Dec 1999 17:06:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA18955 for ietf-radius-outgoing; Thu, 16 Dec 1999 17:07:35 -0800 (PST) Message-Id: <4.2.2.19991216170028.00aff220@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Dec 1999 17:07:06 -0800 To: Randy Bush From: Matt Holdrege Subject: Re: (radius) documents wedge over track confusion Cc: ietf-radius@livingston.com In-Reply-To: References: <4.2.2.19991216152909.00ace220@porky> <012f01bf481d$d6cc54f0$527646ab@DMCNAMEEPC> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 03:56 PM 12/16/99 -0800, Randy Bush wrote: >and a statement such as > > > I expect some will disagree and point at ... threat theories, but reality > > should be our guide here. > >is a very convincing argument. but i suspect you might not like that for >which it convinces me and at least some other folk responsible for large >networks. the network has *very* serious security problems, and they are >not on the wane. Sorry my statements were strong, but it's based on years of discussion on this topic. I guess I meant "happy with Radius" in that it works reasonably well. Especially in comparison with a lot of other things an ISP has to deal with. RADIUS is not perfect, but we WERE NOT ALLOWED to continue working on it or any successor to help make things better. So we are stuck with what we have. That's why I said RADIUS is what it is and we should document it so. As for securing messages, we all have access to IPsec now, right? IPsec may not be integrated into today's products as much as we would prefer, but it can be done. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Dec 16 20:23:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13382 for ; Thu, 16 Dec 1999 20:23:08 -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 QAA15203; Thu, 16 Dec 1999 16:40:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA17531 for ietf-radius-outgoing; Thu, 16 Dec 1999 16:41:27 -0800 (PST) From: Carl Rigney Date: Thu, 16 Dec 1999 16:38:17 -0800 (PST) Message-Id: <199912170038.QAA25046@artemis.livingston.com> To: matt@ascend.com Subject: Re: (radius) documents wedge over track confusion Cc: ietf-radius@livingston.com, randy@psg.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney At 03:36 PM 12/16/99 -0800, Matt Holdrege wrote: >I think they should all be standards track. Both Radius and Radius >accounting should be draft standard and the others should be proposed standard. >Radius extensions draft.... should be Experimental. That would all be fine by me. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 17 00:54:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18181 for ; Fri, 17 Dec 1999 00:54:32 -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 VAA20057; Thu, 16 Dec 1999 21:49:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA28261 for ietf-radius-outgoing; Thu, 16 Dec 1999 21:50:18 -0800 (PST) From: "Bernard Aboba" To: "'Randy Bush'" , , Subject: RE: (radius) documents wedge over track confusion Date: Thu, 16 Dec 1999 21:48:24 -0800 Message-ID: <007001bf4852$55c8bbc0$2d8939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 draft-ietf-radius-accounting-v2-02.txt is indeed intended to replace RFC 2139. However, I do not believe that it addresses the issues which caused RFC 2139 to be classified as informational. Mike O'Dell is probably best qualified to articulate the reasoning behind the original classification. -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of Randy Bush Sent: Thursday, December 16, 1999 11:46 AM To: ietf-radius@livingston.com Subject: (radius) documents wedge over track confusion some documents have wedged at the iesg. essentially we became confused which track they were or should be on. the confusion seems to be that some of the documents seem to specify protocol, use words like MUST etc., but have been called as informational. bernard tells me that this is because they rely on rfc2139 which is informational, and was so classified because the specified transport was feared not to be sufficiently reliable. an iesg member asked if draft-ietf-radius-accounting-v2-02.txt is intended to replace 2139, and if it solves 2139's problems sufficiently to be standards track and therefore clear the logjam. i will append my notes as of last eve. randy o RADIUS Extensions [Informational] relies on 2139 which is infomational. but this one might be experimental because This memo suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental. but wg chair asked for info. o Implementation of L2TP Compulsory Tunneling via RADIUS [Informational] should be proposed standard, because it specifies protocol, uses MUST, etc., but was requested as informational. it says: This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. o RADIUS Accounting Modifications for Tunnel Protocol Support [Informational] relies on 2139 which is infomational, and i was told to ask as info and it sez info on the draft. but it looks like it specifies protocol. o RADIUS Accounting [Informational] Note: Requires draft-ietf-radius-tunnel-auth relies on 2139 so should be informational. but it looks like a proposed standard, though the wg chair asked for informational. it says: This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. -30- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Dec 17 02:51:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00505 for ; Fri, 17 Dec 1999 02:51:20 -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 XAA22690; Thu, 16 Dec 1999 23:46:26 -0800 (PST) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id XAA02184 for ietf-radius-outgoing; Thu, 16 Dec 1999 23:47:37 -0800 (PST) From: "Bernard Aboba" To: "'Matt Holdrege'" , "'Randy Bush'" Cc: Subject: RE: (radius) documents wedge over track confusion Date: Thu, 16 Dec 1999 23:46:08 -0800 Message-ID: <000201bf4862$c8883db0$2d8939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: <4.2.2.19991216152909.00ace220@porky> 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 >I recall that the reason Radius accounting was made Informational was that >previous AD's were very much concerned with the risks associated with >billing systems relying on this RFC. Not sure what is meant by "risks" here. There are security risks (which were also present with other accounting methods of the time, such as SNMP v2c) and there are financial risks (e.g. due to packet loss). I went back through the RADIUS mailing list archives, and could not find any messages that articulate the reasons for the IESG decision. >But time has shown that a great many ISP's serving tens of millions >of users are happily using RFC 2139 today. >It has achieved widespread interoperability as well. Time has shown that RFC 2139 is adequate for capacity planning as well as accounting in non-usage sensitive billing situations which comprise the bulk of today's dialup business. This does not necessarily mean that RFC 2139 is applicable to usage-sensitive billing scenarios where packet loss = revenue loss and a high degree of reliability is required. >The alternative is that we have a delta between what the IETF publishes and >what happens on the real Internet. That is not a good thing. There are widely deployed, interoperable protocols that are not IETF standards. I'm not sure that is bad per se, as long as there is good technical justification for the distinction. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 20 08:06:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02813 for ; Mon, 20 Dec 1999 08:06:29 -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 EAA25642; Mon, 20 Dec 1999 04:52:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id EAA23623 for ietf-radius-outgoing; Mon, 20 Dec 1999 04:52:02 -0800 (PST) Date: Mon, 20 Dec 1999 07:49:35 -0500 (EST) From: "Steven P. Crain" To: Randy Bush cc: Matt Holdrege , Dave McNamee , ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion 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: "Steven P. Crain" On Thu, 16 Dec 1999, Randy Bush wrote: > it would sure be nice to have users, as opposed to vendors, telling us how > happy the users are. OK, I'm a user. (Large New England regional ISP). We use radius accounting for our billing usage feed. We bill based on time online for each user. We have very little packet loss, and find that it works consistently and reliably with every vendor hardware we have used. We have some disappointments with its limitaions [1], but overall I really think it ought to be a standard, and not just informational. Note: [1] The most serious limitations from our perspective are that deployed radius accounting implementations we use do not implement interim updates and Acct-Giga*. We have to build vendor-specific workarounds for the former and just not have traffic-sensitive billing for the latter. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections Like a bird that strays from its nest is a man who strays from his home. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 20 15:44:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14610 for ; Mon, 20 Dec 1999 15:44: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 MAA04339; Mon, 20 Dec 1999 12:38:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA16236 for ietf-radius-outgoing; Mon, 20 Dec 1999 12:40:14 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: William "Chops" Westfield Cc: "Steven P. Crain" , Matt Holdrege , Dave McNamee , ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: Message-Id: Date: Mon, 20 Dec 1999 12:38:34 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > Phrased differently, billing is a statistical method of recouping costs. > Statistical errors in the data can be adequately corrected in the math. i anticipate a bit of a problem explaining this to the lawyers and accountants at the isp for which i work. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 20 16:15:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15554 for ; Mon, 20 Dec 1999 16:15: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 NAA05147; Mon, 20 Dec 1999 13:10:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA18078 for ietf-radius-outgoing; Mon, 20 Dec 1999 13:09:57 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 20 Dec 1999 16:07 EST Subject: Re: (radius) documents wedge over track confusion Content-Type: text/plain Message-ID: <385e9b1c0.4155@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff I would have said it differently: When the anticipated recouped revenue is exceeded by the anticipated additional cost, it's time to stop trying to avoid the loss of the last penny of revenue. Barney Wolff > From: Randy Bush > Date: Mon, 20 Dec 1999 12:38:34 -0800 > > > Phrased differently, billing is a statistical method of recouping costs. > > Statistical errors in the data can be adequately corrected in the math. > > i anticipate a bit of a problem explaining this to the lawyers and > accountants at the isp for which i work. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 20 18:57:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19220 for ; Mon, 20 Dec 1999 18:57:46 -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 PAA08222; Mon, 20 Dec 1999 15:52:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA28215 for ietf-radius-outgoing; Mon, 20 Dec 1999 15:54:27 -0800 (PST) Message-ID: <385EC126.576509EB@alteon.com> Date: Mon, 20 Dec 1999 15:52:06 -0800 From: Daniel Tai X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.7 sun4u) MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) looking for any RADIUS server vendors with SecurID support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Daniel Tai Content-Transfer-Encoding: 7bit Hi all, Just wonder is this the right group to ask. If not, please re-direct me to the correct group. Basically, I am looking for any vendors info about RADIUS servers with RSA SecurID support. Are they based on proprietary implementation or draft? Thanks, Daniel Tai dtai@alteon.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Dec 20 20:07:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19894 for ; Mon, 20 Dec 1999 20:07:44 -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 QAA09158; Mon, 20 Dec 1999 16:58:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA02029 for ietf-radius-outgoing; Mon, 20 Dec 1999 16:59:47 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: IETF Secrtaariat Cc: ietf-radius@livingston.com Subject: (radius) Re: radius drafts References: Message-Id: Date: Mon, 20 Dec 1999 16:59:34 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > I've been reading though all the email on Radius, and have not figured out > the best way to ascertain exactly what should be done... my original request was correct. draft-ietf-radius-ext-05.txt draft-ietf-radius-tunnel-imp-05.txt draft-ietf-radius-tunnel-acct-05.txt draft-ietf-radius-accounting-v2-02.txt are to progress as informational. except the wg has wedged on a small change needed in draft-ietf-radius-accounting-v2-02.txt and the wg has yet to submit an -03 draft with revised wording. i will send in the marines if it is not forthcoming by 00.01.09. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 07:46:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09990 for ; Tue, 21 Dec 1999 07:46: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 EAA14653; Tue, 21 Dec 1999 04:41:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id EAA23569 for ietf-radius-outgoing; Tue, 21 Dec 1999 04:43:16 -0800 (PST) Date: Tue, 21 Dec 1999 07:41:00 -0500 (EST) From: "Steven P. Crain" To: Randy Bush cc: William Chops Westfield , Matt Holdrege , Dave McNamee , ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion 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: "Steven P. Crain" On Mon, 20 Dec 1999, Randy Bush wrote: > > Phrased differently, billing is a statistical method of recouping costs. > > Statistical errors in the data can be adequately corrected in the math. > > i anticipate a bit of a problem explaining this to the lawyers and > accountants at the isp for which i work. I think his point is that one of your routine business expences is .00001% revenue loss from lost accounting packets, which is added into the overhead and accounted for in the rate you quote customers. And yes, I think the percentage I quote is reasonable relative to our company, or perhaps a little high. An average packet is only worth a tenth of a cent. At that rate we could easily absorb a 1% packet loss, which is *much* higher than we see in practice (about .001%). -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections Like a bird that strays from its nest is a man who strays from his home. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 09:22:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22867 for ; Tue, 21 Dec 1999 09:22: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 GAA15680; Tue, 21 Dec 1999 06:17:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA26134 for ietf-radius-outgoing; Tue, 21 Dec 1999 06:15:16 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Steven P. Crain" Cc: ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: Message-Id: Date: Tue, 21 Dec 1999 06:15:10 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit >>> Phrased differently, billing is a statistical method of recouping costs. >>> Statistical errors in the data can be adequately corrected in the math. >> i anticipate a bit of a problem explaining this to the lawyers and >> accountants at the isp for which i work. > I think his point is that one of your routine business expences is .00001% > revenue loss from lost accounting packets, which is added into the > overhead and accounted for in the rate you quote customers. and my point was how do i explain to the lawyers and accountants that they can have confidence that number is .00001% as opposed to 1%. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 10:07:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25423 for ; Tue, 21 Dec 1999 10:07:00 -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 HAA16656; Tue, 21 Dec 1999 07:01:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA27702 for ietf-radius-outgoing; Tue, 21 Dec 1999 07:00:13 -0800 (PST) From: Patrice Calhoun Message-Id: <199912211459.GAA26077@nasnfs.eng.sun.com> Date: Tue, 21 Dec 1999 06:59:06 -0800 To: "Randy Bush" , "Steven P. Crain" Cc: Subject: Re: (radius) documents wedge over track confusion X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Patrice Calhoun Content-Transfer-Encoding: 7bit I really find this thread quite amusing. Nothing in the protocol even allows for one to identify packet loss, so how can you get ANY guarantees that you even KNOW what you've lost? Be it 0.00001 or 10%! PatC >>>> Phrased differently, billing is a statistical method of recouping costs. >>>> Statistical errors in the data can be adequately corrected in the math. >>> i anticipate a bit of a problem explaining this to the lawyers and >>> accountants at the isp for which i work. >> I think his point is that one of your routine business expences is .00001% >> revenue loss from lost accounting packets, which is added into the >> overhead and accounted for in the rate you quote customers. > >and my point was how do i explain to the lawyers and accountants that they >can have confidence that number is .00001% as opposed to 1%. > >randy >- >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 Tue Dec 21 10:28:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25808 for ; Tue, 21 Dec 1999 10:28:30 -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 HAA17093; Tue, 21 Dec 1999 07:23:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA28789 for ietf-radius-outgoing; Tue, 21 Dec 1999 07:24:05 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Patrice Calhoun Cc: ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: <199912211459.GAA26077@nasnfs.eng.sun.com> Message-Id: Date: Tue, 21 Dec 1999 07:22:43 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > I really find this thread quite amusing. Nothing in the protocol even > allows for one to identify packet loss, so how can you get ANY guarantees > that you even KNOW what you've lost? Be it 0.00001 or 10%! bingo! well, we know it can't be over 100% :-) randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 11:48:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23795 for ; Tue, 21 Dec 1999 11:48: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 IAA18506; Tue, 21 Dec 1999 08:42:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA02671 for ietf-radius-outgoing; Tue, 21 Dec 1999 08:44:13 -0800 (PST) Date: Tue, 21 Dec 1999 11:45:02 -0500 (EST) From: "Steven P. Crain" To: pcalhoun@eng.sun.com cc: Randy Bush , ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion In-Reply-To: <199912211459.GAA26077@nasnfs.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Tue, 21 Dec 1999, Patrice Calhoun wrote: > I really find this thread quite amusing. Nothing in the protocol even allows > for one to identify packet loss, so how can you get ANY guarantees that > you even KNOW what you've lost? Be it 0.00001 or 10%! [Misc note: the .00001 % was revenue loss, based on the specifics of how my company's revenue streams work out in practice.] You can't tell how much packet loss you have had strictly by using radius, of course. However, you can get a very good idea by careful analysis and comparison of other data sources. I have made comparisons using: * snmp based data * information from the various NAS consoles * syslog-based NAS logs * check of radius accounting logs for internal consistency (e.g. Stop packets with no corresponding Start or vice-versa) One could also use phone company records, logs from the RADIUS server, etc. Its harder to tell on an ongoing basis, but a quick check now and then should reveal any problems. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections Like a bird that strays from its nest is a man who strays from his home. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 11:53:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01103 for ; Tue, 21 Dec 1999 11:53: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 IAA18687; Tue, 21 Dec 1999 08:48:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA03027 for ietf-radius-outgoing; Tue, 21 Dec 1999 08:50:22 -0800 (PST) From: Barney Wolff To: Date: Tue, 21 Dec 1999 11:46 EST Subject: Re: (radius) documents wedge over track confusion Content-Type: text/plain Message-ID: <385fafbb0.4c33@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Oh. And here I thought the NAS would retry if it didn't get a response. Silly me - I thought we were discussing RADIUS. Barney > From: Patrice Calhoun > Date: Tue, 21 Dec 1999 06:59:06 -0800 > > I really find this thread quite amusing. Nothing in the protocol even allows > for one to identify packet loss, so how can you get ANY guarantees that > you even KNOW what you've lost? Be it 0.00001 or 10%! > > PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 14:42:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27045 for ; Tue, 21 Dec 1999 14:42:22 -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 LAA23949; Tue, 21 Dec 1999 11:29:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA14139 for ietf-radius-outgoing; Tue, 21 Dec 1999 11:31:11 -0800 (PST) Message-Id: <4.2.2.19991221113027.00b43ac0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Dec 1999 11:31:18 -0800 To: Randy Bush From: Matt Holdrege Subject: Re: (radius) documents wedge over track confusion Cc: "Steven P. Crain" , ietf-radius@livingston.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 06:15 AM 12/21/99 -0800, Randy Bush wrote: > >>> Phrased differently, billing is a statistical method of recouping costs. > >>> Statistical errors in the data can be adequately corrected in the math. > >> i anticipate a bit of a problem explaining this to the lawyers and > >> accountants at the isp for which i work. > > I think his point is that one of your routine business expences is .00001% > > revenue loss from lost accounting packets, which is added into the > > overhead and accounted for in the rate you quote customers. > >and my point was how do i explain to the lawyers and accountants that they >can have confidence that number is .00001% as opposed to 1%. Probably the same way you explain to them your predicted variance of human error in the billing process? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 14:42:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27067 for ; Tue, 21 Dec 1999 14:42:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id LAA24337; Tue, 21 Dec 1999 11:36:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA14845 for ietf-radius-outgoing; Tue, 21 Dec 1999 11:39:05 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: "Steven P. Crain" , ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: <4.2.2.19991221113027.00b43ac0@porky> Message-Id: Date: Tue, 21 Dec 1999 11:36:38 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit >> and my point was how do i explain to the lawyers and accountants that >> they can have confidence that number is .00001% as opposed to 1%. > Probably the same way you explain to them your predicted variance of human > error in the billing process? i don't have to do that. this is a new, to the lawyers and accountants, variance. and they just love new variances and welcome them with open hearts and minds. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 15:07:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27625 for ; Tue, 21 Dec 1999 15:07:22 -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 MAA25414; Tue, 21 Dec 1999 12:00:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA16376 for ietf-radius-outgoing; Tue, 21 Dec 1999 11:59:30 -0800 (PST) Message-Id: <4.2.2.19991221115513.00ad72d0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Dec 1999 11:59:33 -0800 To: Randy Bush From: Matt Holdrege Subject: Re: (radius) documents wedge over track confusion Cc: "Steven P. Crain" , ietf-radius@livingston.com In-Reply-To: References: <4.2.2.19991221113027.00b43ac0@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 11:36 AM 12/21/99 -0800, Randy Bush wrote: > >> and my point was how do i explain to the lawyers and accountants that > >> they can have confidence that number is .00001% as opposed to 1%. > > Probably the same way you explain to them your predicted variance of human > > error in the billing process? > >i don't have to do that. this is a new, to the lawyers and accountants, >variance. and they just love new variances and welcome them with open >hearts and minds. Sounds like a personal problem. :) It also sounds like we are getting way too far into the business practices realms which the IETF prefers to avoid for good reason. One of the reasons is that business practices and the laws associated with them vary greatly around the world. What bothers your lawyers may not trouble other ISP's lawyers. So while I and most everyone else agree that it would be nice to have non-repudiation and guaranteed delivery of billing data, we should also agree that it would be very difficult to do that in a proxy environment with RADIUS. Again, RADIUS is what it is and all we are doing here is documenting it. The current IESG direction (as far as we can tell) is to take our wishes, desires and requirements to the AAA WG. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 20:04:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16282 for ; Tue, 21 Dec 1999 20:04:03 -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 QAA04197; Tue, 21 Dec 1999 16:59:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id QAA04579 for ietf-radius-outgoing; Tue, 21 Dec 1999 16:58:03 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Holdrege Cc: ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: <4.2.2.19991221113027.00b43ac0@porky> <4.2.2.19991221115513.00ad72d0@porky> Message-Id: Date: Tue, 21 Dec 1999 16:56:33 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > So while I and most everyone else agree that it would be nice to have > non-repudiation and guaranteed delivery of billing data, we should also > agree that it would be very difficult to do that in a proxy environment > with RADIUS. yup. and all anybody is asking is that the document mention that there are problems. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 20:15:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16431 for ; Tue, 21 Dec 1999 20:15:29 -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 RAA04563; Tue, 21 Dec 1999 17:10:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id RAA05451 for ietf-radius-outgoing; Tue, 21 Dec 1999 17:12:34 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 21 Dec 1999 20:10 EST Subject: Re: (radius) documents wedge over track confusion Content-Type: text/plain Message-ID: <3860257a0.563f@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Would somebody please explain what problems would be cured by some other protocol, and how? This discussion has been alarmingly vague. Thanks, Barney > From: Randy Bush > Date: Tue, 21 Dec 1999 16:56:33 -0800 > > > So while I and most everyone else agree that it would be nice to have > > non-repudiation and guaranteed delivery of billing data, we should also > > agree that it would be very difficult to do that in a proxy environment > > with RADIUS. > > yup. and all anybody is asking is that the document mention that there are > problems. > > randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Dec 21 23:28:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20153 for ; Tue, 21 Dec 1999 23:28:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id UAA08395; Tue, 21 Dec 1999 20:23:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id UAA12264 for ietf-radius-outgoing; Tue, 21 Dec 1999 20:25:17 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Barney Wolff Cc: ietf-radius@livingston.com Subject: Re: (radius) documents wedge over track confusion References: <3860257a0.563f@databus.databus.com> Message-Id: Date: Tue, 21 Dec 1999 20:23:56 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > Would somebody please explain what problems would be cured by some > other protocol, and how? as carl said, we have another forum for that. we are just trying to get radius docs out the door, and have peers who believe that the one of the documents needs a caveat. randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Dec 22 03:25:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04409 for ; Wed, 22 Dec 1999 03:25: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 AAA10508; Wed, 22 Dec 1999 00:18:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id AAA19211 for ietf-radius-outgoing; Wed, 22 Dec 1999 00:20:54 -0800 (PST) From: Carl Rigney Date: Wed, 22 Dec 1999 00:18:14 -0800 (PST) Message-Id: <199912220818.AAA00893@artemis.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Update to draft-ietf-radius-radius Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Based on discussions so far there are a couple of paragraphs that need tweaking in the current RADIUS draft (tuning the proxy warning and adding a bit to security section pointing out that the MD5 chaining used for password hiding has not been as deeply analyzed as it could be). If anyone wants to suggest any changes to the language proposed so far please mail me your input by Monday the 27th, and I'll send out my draft of just those paragraphs early next week (so people can point out typoes or shocking lapses of grammar or logic, if any) and then get the new draft out by the end of the century [1], so things can move along. You don't need to send me anything that's already been sent to the mailing list, I have all that already. -- Carl Rigney RADIUS Editor 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 Dec 31 13:49:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04349 for ; Fri, 31 Dec 1999 13:49:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id KAA24035; Fri, 31 Dec 1999 10:38:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id KAA29547 for ietf-radius-outgoing; Fri, 31 Dec 1999 10:36:53 -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) progress of documents, or lack thereof Message-Id: Date: Thu, 30 Dec 1999 11:31:48 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit we discussed the radius documents on the iesg telechat today. o draft-ietf-radius-ext-05.txt why can the server not do mtu discovery? Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information. o draft-ietf-radius-tunnel-imp-05.txt pending other drafts, as they're a package o draft-ietf-radius-tunnel-acct-05.txt the revised draft with the agreed fixes to the security issue and the iana considerations was not received as it was promised that it would be. o draft-ietf-radius-accounting-v2-02.txt can not progress without draft-ietf-radius-tunnel-auth the iesg's next telechat is 00.01.13. could we please have o answer to mtu discovery question on draft-ietf-radius-ext-05.txt o draft-ietf-radius-tunnel-imp-05.txt security and iana revisions sufficiently beforehand so i can get them on the agenda? 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 Fri Dec 31 16:15:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05737 for ; Fri, 31 Dec 1999 16:15: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 NAA25323; Fri, 31 Dec 1999 13:08:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA01528 for ietf-radius-outgoing; Fri, 31 Dec 1999 13:09:00 -0800 (PST) From: "Bernard Aboba" To: "'Randy Bush'" , Subject: RE: (radius) progress of documents, or lack thereof Date: Fri, 31 Dec 1999 13:07:52 -0800 Message-ID: <008b01bf53d3$1bd0b210$2d8939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 > why can the server not do mtu discovery? Because RADIUS is only spoken between the RADIUS client and server, not between the RADIUS server and the PPP peer. The issue here is not the MTU between the RADIUS client and server but the MTU between the peer and the NAS. Even if the RADIUS server does MTU discovery to the RADIUS client, the resulting MTU could still be larger than can be handled between the PPP peer and the NAS. Since the PPP peer is not authenticated yet, and therefore does not have IP connectivity, it is not possible to do MTU discovery between the RADIUS server and the PPP peer in any case. > o draft-ietf-radius-tunnel-imp-05.txt security and iana revisions Are you sure you are referring to the -imp and not the -auth draft? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.