From owner-ietf-radius@livingston.com Mon Nov 1 13:22:08 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 NAA09191 for ; Mon, 1 Nov 1999 13:22: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 KAA05197; Mon, 1 Nov 1999 10:18:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA21811 for ietf-radius-outgoing; Mon, 1 Nov 1999 10:14:13 -0800 (PST) Message-Id: <4.2.0.58.19991101105824.00cb2a80@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 Nov 1999 11:01:06 -0500 To: Barry James , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP In-Reply-To: References: <199910261955.MAA18561@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: "David Mitton" I think it's a great idea. There's an existing implementation that does a similar thing: Ascend-Require-Auth (201) 0=no, 1=yes Your proposal allows the NAS to negotiate the authentication techniques. You may want to consider allowing the specification of several types. And don't forget EAP. Dave. At 09:39 PM 10/26/99 +0000, Barry James wrote: >Does it make any sense to have an attribute that will allow the >specification of authentication types before modem negotiation via the >call check mechanism? That is to say, one good use of the call check >mechanism is to have the NAS send the Access-Request with Service-Type = >Call Check and User-Name = and to have the RADIUS server send back >and Auth-Type specifying what type of authentication mechanism should be >used for this call. > >Most NAS gear support a default authentication type. For those users of >RADIUS that resell ports to ISPs or other customers and need to support >multiple customers dialing into a bank of NAS's it keeps us from having to >dedicate NAS gear to specific customers (ie one customer uses PAP and >another uses CHAP, etc). I think it would be very useful (we do it here >now) to be able to send back in the Access-Accept something like Auth-Type >= Auth-CHAP so that the NAS will initiate a CHAP negotiation with the >customer, while sending back an Auth-PAP will cause the NAS to initiate a >PAP negotiation. > >This model works well for port-resellers and others. A possible definition >might include: >Auth-None >Auth-Any >Auth-Default >Auth-PAP >Auth-CHAP >Auth-MS-CHAP > >Thoughts? > >Regards, >Barry > >Barry L James | Never doubt that a small group of >IP SWAT | thoughtful, committed citizens can >Level 3 Communications | change the world. Indeed, it's >http://www.level3.com | the only thing that ever has. >Member IEEE, AAAI | #include > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions 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 Nov 1 14:44: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 OAA27519 for ; Mon, 1 Nov 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 LAA07921; Mon, 1 Nov 1999 11:40:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA28395 for ietf-radius-outgoing; Mon, 1 Nov 1999 11:41:06 -0800 (PST) Date: Mon, 1 Nov 1999 19:37:43 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: David Mitton cc: ietf-radius@livingston.com Subject: Re: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP In-Reply-To: <4.2.0.58.19991101105824.00cb2a80@ZBL6C008.corpeast.baynetworks.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 Thanks Dave. Actually, in my current setup I use Ascend-Require-Auth and the Auth-Type attributes to do this now during (what I call) Tier-1 negotiation. I use the Ascend-Require-Auth to help in setting up outage policies such that if a customer's RADIUS server fails and they will be down for a period of time, we may set Ascend-Require-Auth to No, effectively setting an outage policy to "accept all on this DNIS," until their RADIUS server is functional again. Since Tier-1 negotiation only happens between the NAS and my proxies in the gateways a down customer premise (CP) RADIUS server doesn't affect this model. I also use a 2000ms timeout on Tier-1 negotiations. And by using this 2-tier authentication model, one can check global session limits (or whatever you want to do) *before* a call is accepted (that is, before the person dialing in hears modem tone) and by sending back an Access-Reject, the NAS may post a busy signal to the caller. In areas where all calls are toll calls (eg Europe) this is a real benefit to the customer. Thanks for your input! Regards, Barry On Mon, 1 Nov 1999, David Mitton wrote: > I think it's a great idea. > There's an existing implementation that does a similar thing: > Ascend-Require-Auth (201) 0=no, 1=yes > > Your proposal allows the NAS to negotiate the authentication > techniques. You may want to consider allowing the specification of several > types. And don't forget EAP. > > Dave. > > At 09:39 PM 10/26/99 +0000, Barry James wrote: > > >Does it make any sense to have an attribute that will allow the > >specification of authentication types before modem negotiation via the > >call check mechanism? That is to say, one good use of the call check > >mechanism is to have the NAS send the Access-Request with Service-Type = > >Call Check and User-Name = and to have the RADIUS server send back > >and Auth-Type specifying what type of authentication mechanism should be > >used for this call. > > > >Most NAS gear support a default authentication type. For those users of > >RADIUS that resell ports to ISPs or other customers and need to support > >multiple customers dialing into a bank of NAS's it keeps us from having to > >dedicate NAS gear to specific customers (ie one customer uses PAP and > >another uses CHAP, etc). I think it would be very useful (we do it here > >now) to be able to send back in the Access-Accept something like Auth-Type > >= Auth-CHAP so that the NAS will initiate a CHAP negotiation with the > >customer, while sending back an Auth-PAP will cause the NAS to initiate a > >PAP negotiation. > > > >This model works well for port-resellers and others. A possible definition > >might include: > >Auth-None > >Auth-Any > >Auth-Default > >Auth-PAP > >Auth-CHAP > >Auth-MS-CHAP > > > >Thoughts? > > > >Regards, > >Barry > > > >Barry L James | Never doubt that a small group of > >IP SWAT | thoughtful, committed citizens can > >Level 3 Communications | change the world. Indeed, it's > >http://www.level3.com | the only thing that ever has. > >Member IEEE, AAAI | #include > > > >- > >To unsubscribe, email 'majordomo@livingston.com' with > >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Consulting Engineer, Nortel Networks 978-288-4570 Direct > Carrier Packet Solutions 978-288-3030 FAX > Billerica, MA 01821 dmitton@nortelnetworks.com > Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's http://www.level3.com | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Nov 5 14:44:35 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 OAA10529 for ; Fri, 5 Nov 1999 14:44:34 -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 LAA24269; Fri, 5 Nov 1999 11:40:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA13203 for ietf-radius-outgoing; Fri, 5 Nov 1999 11:37:40 -0800 (PST) Message-Id: <199911051928.LAA18220@sigma.cisco.com> X-Sender: dgeller@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 05 Nov 1999 11:27:42 -0800 To: Barry James From: Dalia Geller Subject: Re: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP Cc: David Mitton , ietf-radius@livingston.com In-Reply-To: References: <4.2.0.58.19991101105824.00cb2a80@ZBL6C008.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dalia Geller Barry, in the event that the customer's Radius server is down, and you set : Ascend-Require-Auth to no in your proxy server, what authorization data do you apply to that call ? I.e.; ip address, etc. Do you define default authorization data in the customer profile for the DNIS number that you then apply to every call for that DNIS number (in the event that a 2nd authentication is not required) ? Thanks and regards, -Dalia At 07:37 PM 11/1/99 +0000, Barry James wrote: >Thanks Dave. Actually, in my current setup I use Ascend-Require-Auth and >the Auth-Type attributes to do this now during (what I call) Tier-1 >negotiation. I use the Ascend-Require-Auth to help in setting up outage >policies such that if a customer's RADIUS server fails and they will be >down for a period of time, we may set Ascend-Require-Auth to No, >effectively setting an outage policy to "accept all on this DNIS," until >their RADIUS server is functional again. > >Since Tier-1 negotiation only happens between the NAS and my proxies in >the gateways a down customer premise (CP) RADIUS server doesn't affect >this model. I also use a 2000ms timeout on Tier-1 negotiations. And by >using this 2-tier authentication model, one can check global session >limits (or whatever you want to do) *before* a call is accepted (that is, >before the person dialing in hears modem tone) and by sending back an >Access-Reject, the NAS may post a busy signal to the caller. In areas >where all calls are toll calls (eg Europe) this is a real benefit to the >customer. > >Thanks for your input! > >Regards, >Barry > >On Mon, 1 Nov 1999, David Mitton wrote: > >> I think it's a great idea. >> There's an existing implementation that does a similar thing: >> Ascend-Require-Auth (201) 0=no, 1=yes >> >> Your proposal allows the NAS to negotiate the authentication >> techniques. You may want to consider allowing the specification of several >> types. And don't forget EAP. >> >> Dave. >> >> At 09:39 PM 10/26/99 +0000, Barry James wrote: >> >> >Does it make any sense to have an attribute that will allow the >> >specification of authentication types before modem negotiation via the >> >call check mechanism? That is to say, one good use of the call check >> >mechanism is to have the NAS send the Access-Request with Service-Type = >> >Call Check and User-Name = and to have the RADIUS server send back >> >and Auth-Type specifying what type of authentication mechanism should be >> >used for this call. >> > >> >Most NAS gear support a default authentication type. For those users of >> >RADIUS that resell ports to ISPs or other customers and need to support >> >multiple customers dialing into a bank of NAS's it keeps us from having to >> >dedicate NAS gear to specific customers (ie one customer uses PAP and >> >another uses CHAP, etc). I think it would be very useful (we do it here >> >now) to be able to send back in the Access-Accept something like Auth-Type >> >= Auth-CHAP so that the NAS will initiate a CHAP negotiation with the >> >customer, while sending back an Auth-PAP will cause the NAS to initiate a >> >PAP negotiation. >> > >> >This model works well for port-resellers and others. A possible definition >> >might include: >> >Auth-None >> >Auth-Any >> >Auth-Default >> >Auth-PAP >> >Auth-CHAP >> >Auth-MS-CHAP >> > >> >Thoughts? >> > >> >Regards, >> >Barry >> > >> >Barry L James | Never doubt that a small group of >> >IP SWAT | thoughtful, committed citizens can >> >Level 3 Communications | change the world. Indeed, it's >> >http://www.level3.com | the only thing that ever has. >> >Member IEEE, AAAI | #include >> > >> >- >> >To unsubscribe, email 'majordomo@livingston.com' with >> >'unsubscribe ietf-radius' in the body of the message. >> >> --------------------------------------------------------------- >> David Mitton ESN: 248-4570 >> Consulting Engineer, Nortel Networks 978-288-4570 Direct >> Carrier Packet Solutions 978-288-3030 FAX >> Billerica, MA 01821 dmitton@nortelnetworks.com >> > >Barry L James | Never doubt that a small group of >IP SWAT | thoughtful, committed citizens can >Level 3 Communications | change the world. Indeed, it's >http://www.level3.com | the only thing that ever has. >Member IEEE, AAAI | #include > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Nov 5 17:11: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 RAA02392 for ; Fri, 5 Nov 1999 17:11:04 -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 OAA28836; Fri, 5 Nov 1999 14:06:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA22216 for ietf-radius-outgoing; Fri, 5 Nov 1999 14:07:18 -0800 (PST) Date: Fri, 5 Nov 1999 21:55:27 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: Dalia Geller cc: Barry James , David Mitton , ietf-radius@livingston.com Subject: Re: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP In-Reply-To: <199911051928.LAA18220@sigma.cisco.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 Dalia, Actually, we have two mechanisms to use for this. The first, and the one we actually use in production, is a configuration setting in the RADIUS server that directly reflects an object appropriately called "Outage Policy." This simply sets the RADIUS server in "Accept All" mode where any call placed to the customer's DNIS will cause the proxy to send an Access-Accept to the NAS (after internal parameters have been satisified and it only applies to the one customer, of course). However, in both cases, it's really a blind acceptance. That is to say, anyone dialing in on that DNIS will forgoe any proxying to CP RADIUS servers and the proxy will simply send an Access-Accept to the NAS. This is accomplished either through the first method mentioned above, which doesn't really care about Tier-1 transactions (except for some internal specifics) and takes place in Tier-2, or via the Tier-1 transaction which signals to the RADIUS server that this customer (mapped via the DNIS) wishes that all calls to a given DNIS be accepted. The default "Outage Policy" is to reject if a CP RADIUS is down. Both of these methods fall short of any good security (except obscurity), but they've been created in the event that a customer's RADIUS goes down but they do not want their nationwide customers to suffer while they restore service. In this thread, I'm not really suggesting implementing/introducing the *require-auth* attribute. It's the Auth-Type attribute with previously mentioned corresponding values that I feel would be a great benefit when vendors wish to implement the call check feature of the new draft. Regards, Barry On Fri, 5 Nov 1999, Dalia Geller wrote: > Barry, in the event that the customer's Radius server is down, and you set : > > Ascend-Require-Auth to no > > in your proxy server, what authorization data do you apply to that call ? > > I.e.; ip address, etc. Do you define default authorization data in the > customer profile for the DNIS number that you then apply to every call for > that DNIS number (in the event that a 2nd authentication is not required) ? > > Thanks and regards, > -Dalia > > At 07:37 PM 11/1/99 +0000, Barry James wrote: > >Thanks Dave. Actually, in my current setup I use Ascend-Require-Auth and > >the Auth-Type attributes to do this now during (what I call) Tier-1 > >negotiation. I use the Ascend-Require-Auth to help in setting up outage > >policies such that if a customer's RADIUS server fails and they will be > >down for a period of time, we may set Ascend-Require-Auth to No, > >effectively setting an outage policy to "accept all on this DNIS," until > >their RADIUS server is functional again. > > > >Since Tier-1 negotiation only happens between the NAS and my proxies in > >the gateways a down customer premise (CP) RADIUS server doesn't affect > >this model. I also use a 2000ms timeout on Tier-1 negotiations. And by > >using this 2-tier authentication model, one can check global session > >limits (or whatever you want to do) *before* a call is accepted (that is, > >before the person dialing in hears modem tone) and by sending back an > >Access-Reject, the NAS may post a busy signal to the caller. In areas > >where all calls are toll calls (eg Europe) this is a real benefit to the > >customer. > > > >Thanks for your input! > > > >Regards, > >Barry > > > >On Mon, 1 Nov 1999, David Mitton wrote: > > > >> I think it's a great idea. > >> There's an existing implementation that does a similar thing: > >> Ascend-Require-Auth (201) 0=no, 1=yes > >> > >> Your proposal allows the NAS to negotiate the authentication > >> techniques. You may want to consider allowing the specification of > several > >> types. And don't forget EAP. > >> > >> Dave. > >> > >> At 09:39 PM 10/26/99 +0000, Barry James wrote: > >> > >> >Does it make any sense to have an attribute that will allow the > >> >specification of authentication types before modem negotiation via the > >> >call check mechanism? That is to say, one good use of the call check > >> >mechanism is to have the NAS send the Access-Request with Service-Type = > >> >Call Check and User-Name = and to have the RADIUS server send back > >> >and Auth-Type specifying what type of authentication mechanism should be > >> >used for this call. > >> > > >> >Most NAS gear support a default authentication type. For those users of > >> >RADIUS that resell ports to ISPs or other customers and need to support > >> >multiple customers dialing into a bank of NAS's it keeps us from having to > >> >dedicate NAS gear to specific customers (ie one customer uses PAP and > >> >another uses CHAP, etc). I think it would be very useful (we do it here > >> >now) to be able to send back in the Access-Accept something like Auth-Type > >> >= Auth-CHAP so that the NAS will initiate a CHAP negotiation with the > >> >customer, while sending back an Auth-PAP will cause the NAS to initiate a > >> >PAP negotiation. > >> > > >> >This model works well for port-resellers and others. A possible definition > >> >might include: > >> >Auth-None > >> >Auth-Any > >> >Auth-Default > >> >Auth-PAP > >> >Auth-CHAP > >> >Auth-MS-CHAP > >> > > >> >Thoughts? > >> > > >> >Regards, > >> >Barry > >> > > >> >Barry L James | Never doubt that a small group of > >> >IP SWAT | thoughtful, committed citizens can > >> >Level 3 Communications | change the world. Indeed, it's > >> >http://www.level3.com | the only thing that ever has. > >> >Member IEEE, AAAI | #include > >> > > >> >- > >> >To unsubscribe, email 'majordomo@livingston.com' with > >> >'unsubscribe ietf-radius' in the body of the message. > >> > >> --------------------------------------------------------------- > >> David Mitton ESN: 248-4570 > >> Consulting Engineer, Nortel Networks 978-288-4570 Direct > >> Carrier Packet Solutions 978-288-3030 FAX > >> Billerica, MA 01821 dmitton@nortelnetworks.com > >> > > > >Barry L James | Never doubt that a small group of > >IP SWAT | thoughtful, committed citizens can > >Level 3 Communications | change the world. Indeed, it's > >http://www.level3.com | the only thing that ever has. > >Member IEEE, AAAI | #include > > > >- > >To unsubscribe, email 'majordomo@livingston.com' with > >'unsubscribe ietf-radius' in the body of the message. > > > Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's http://www.level3.com | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 8 21:17: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 VAA14915 for ; Mon, 8 Nov 1999 21:16:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id SAA20915; Mon, 8 Nov 1999 18:12:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA04149 for ietf-radius-outgoing; Mon, 8 Nov 1999 18:09:12 -0800 (PST) X-Authentication-Warning: firewall.chttl.com.tw: smap set sender to using -f Message-ID: <382780C0.C1A26828@chttl.com.tw> Date: Tue, 09 Nov 1999 10:02:40 +0800 From: =?iso-8859-1?Q?=DFN=B7=AC?= X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) questions about RFC 2138 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: =?iso-8859-1?Q?=DFN=B7=AC?= Content-Transfer-Encoding: 7bit Hello, I am new to the Radius protocol . After reading the RFC 2138, I have some questions about it. Can anyone help me or tell me where to find more information about these questions ? 1. When will the Radius server decide to send Access-Challenge to challenge the user ? 2. How many times can the Radius server challenge the user ? 3. How does the Radius server get the challenge (16 octetes random number )? 4. Where does the challenge be put in the Access-Challenge packet ? 5. If the PAP is used between the user and the Radius client, how do they operate with the challenge ( can the user still encrypt the challenge with the special devices such as smart card of software ? But PAP does not support to send the response, does it ?) Thanks a lot ! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 10 09:50: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 JAA12312 for ; Wed, 10 Nov 1999 09:50:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA23785; Wed, 10 Nov 1999 06:46:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA02247 for ietf-radius-outgoing; Wed, 10 Nov 1999 06:44:47 -0800 (PST) Message-ID: <007301bf2b8a$13665ce0$0103a8c0@ds9> From: "Darran Potter" To: Subject: (radius) Clarification regarding Signature Date: Wed, 10 Nov 1999 14:44:07 -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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit version 4 of the extensions draft says: "When present in an Access-Request packet, Signature is an HMAC-MD5 [7] checksum of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows. Signature = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)" Does this mean you replace the authenticator with the shared secret and then do the hash..... or, append the shared secret after the packet and do the hash on the combined "chunk". Thanks Darran - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 10 10:34: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 KAA05609 for ; Wed, 10 Nov 1999 10:34: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 HAA25002; Wed, 10 Nov 1999 07:31:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04411 for ietf-radius-outgoing; Wed, 10 Nov 1999 07:32:23 -0800 (PST) Message-Id: <4.2.0.58.19991110092215.00a1f6d0@zbl6c008.corpeast.baynetworks.com> X-Sender: dmitton@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 10 Nov 1999 10:29:31 -0500 To: =?iso-8859-1?Q?=DFN=B7=AC?= , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) questions about RFC 2138 In-Reply-To: <382780C0.C1A26828@chttl.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05609 At 10:02 AM 11/9/99 +0800, ßN·¬ wrote: >Hello, > >I am new to the Radius protocol . >After reading the RFC 2138, I have some questions about it. >Can anyone help me or tell me where to find more information about these >questions ? > >1. When will the Radius server decide to send Access-Challenge to >challenge the user ? When it feels it needs another response from the user to authenticate them. >2. How many times can the Radius server challenge the user ? As many times as it needs by it's implementation. RADIUS does not provide a limit. >3. How does the Radius server get the challenge (16 octetes random >number )? >4. Where does the challenge be put in the Access-Challenge packet ? The response to challenges are encoded in the User-Password field, as specified in paragraph 5, section 4.4 Access-Challenge >5. If the PAP is used between the user and the Radius client, how do >they operate with the challenge > ( can the user still encrypt the challenge with the special devices >such as smart card of software ? > But PAP does not support to send the response, does it ?) PAP merely specifies that the "password" information is not transformed in any way by the NAS. I don't think it cares what kind of information (ASCII, binary, etc) is used. PAP could deal with a challenge issue by retrying. It would clearly be dependent on the PPP client implementation. Dave. >Thanks a lot ! > > >- >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, IP Services 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 10 11:28: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 LAA01778 for ; Wed, 10 Nov 1999 11:28:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA26210; Wed, 10 Nov 1999 08:24:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA07375 for ietf-radius-outgoing; Wed, 10 Nov 1999 08:25:49 -0800 (PST) Date: Wed, 10 Nov 1999 11:25:33 -0500 From: Paul Krumviede Subject: Re: (radius) Clarification regarding Signature In-reply-to: <007301bf2b8a$13665ce0$0103a8c0@ds9> Originator-info: login-id=krumviede; server=localhost To: Darran Potter , ietf-radius@livingston.com Message-id: <1635295876.942233133@dhcp69-ds99.ds.ietf.innovationslab.net> MIME-version: 1.0 X-Mailer: Mulberry (Win32) [1.4.4, s/n P005-300888-005] Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Content-Transfer-Encoding: 7BIT --On Wednesday, November 10, 1999, 2:44 PM +0000 Darran Potter wrote: > version 4 of the extensions draft says: > > "When present in an Access-Request packet, Signature is an HMAC-MD5 > [7] checksum of the entire Access-Request packet, including Type, > ID, Length and authenticator, using the shared secret as the key, > as follows. > > Signature = HMAC-MD5 (Type, Identifier, Length, Request > Authenticator, Attributes)" > > Does this mean you replace the authenticator with the shared secret > and then do the hash..... or, append the shared secret after the packet > and do the hash on the combined "chunk". if this is hmac (as in RFC 2104), the shared secret is used as the key K, and thus is used in place of the authenticator or not appended. K is only referenced in the expansion of HMAC-MD5: md5(K xor opad, md5(K xor ipad, text)) where ipad and opad are defined in RFC 2104. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 22 02:35:55 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 CAA26418 for ; Mon, 22 Nov 1999 02:35: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 XAA22049; Sun, 21 Nov 1999 23:31:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA09002 for ietf-radius-outgoing; Sun, 21 Nov 1999 23:30:34 -0800 (PST) Message-ID: <3838EFEC.B597C6A5@chttl.com.tw> Date: Mon, 22 Nov 1999 15:25:32 +0800 From: =?iso-8859-1?Q?=DFN=B7=AC?= X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-radius@livingston.com" Subject: (radius) Security question about Radius Content-Type: multipart/mixed; boundary="------------073DF1A3FC8E4221998541D3" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: =?iso-8859-1?Q?=DFN=B7=AC?= This is a multi-part message in MIME format. --------------073DF1A3FC8E4221998541D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Because the request message from NAS to the Radius server were not authenticated, the hacker might crash the server by sending many request, right? Can we do something to protect the server? Hsiao-Feng --------------073DF1A3FC8E4221998541D3 Content-Type: text/x-vcard; charset=us-ascii; name="yhf.vcf" Content-Description: Card for ßN·¬ Content-Disposition: attachment; filename="yhf.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Yeh;Hsiao-Feng tel;work:+886-3-4245064 x-mozilla-html:FALSE fn;quoted-printable:=B8=AD=DFN=B7=AC org:Chunghwa Telecom Co. TL. adr:;;;;;; version:2.1 email;internet:yhf@chttl.com.tw end:vcard --------------073DF1A3FC8E4221998541D3-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 22 09:38: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 JAA20213 for ; Mon, 22 Nov 1999 09:38: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 GAA26011; Mon, 22 Nov 1999 06:34:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA16461 for ietf-radius-outgoing; Mon, 22 Nov 1999 06:35:21 -0800 (PST) Message-Id: <4.2.0.58.19991122092829.03425a80@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 22 Nov 1999 09:33:26 -0500 To: =?iso-8859-1?Q?=DFN=B7=AC?= , "ietf-radius@livingston.com" From: "David Mitton" Subject: Re: (radius) Security question about Radius In-Reply-To: <3838EFEC.B597C6A5@chttl.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA20213 An authentication server should be written in a robust and defensive manner. There should be no message that causes it to crash. Flooding it with many messages, should simply cause messages in excess of a queue length or processing capability of the server to be discarded. This would be a potential Denial-Of-Service (DOS) attack, to which RADIUS is no more vulnerable than any other TCP/IP protocol. RADIUS doesn't require that you process messages from any given sender. Most implementations will not process a message from a system which is not configured in it's known clients file, with a shared secret. Dave. At 03:25 PM 11/22/99 +0800, ßN·¬ wrote: >Hello, > >Because the request message from NAS to the Radius server >were not authenticated, the hacker might crash the server by >sending many request, right? >Can we do something to protect the server? > >Hsiao-Feng > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 25 04: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 EAA03987 for ; Thu, 25 Nov 1999 04:18: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 BAA11594; Thu, 25 Nov 1999 01:14:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA20615 for ietf-radius-outgoing; Thu, 25 Nov 1999 01:13:27 -0800 (PST) Message-ID: <383CFC4D.DC3007B4@chttl.com.tw> Date: Thu, 25 Nov 1999 17:07:25 +0800 From: =?iso-8859-1?Q?=DFN=B7=AC?= X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) Diameter server operates with the Radius clients ? Content-Type: multipart/mixed; boundary="------------7E7E91DDECD2F87E1E491EB9" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: =?iso-8859-1?Q?=DFN=B7=AC?= This is a multi-part message in MIME format. --------------7E7E91DDECD2F87E1E491EB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Will a Diameter server operates with the Radius clients well ? Will there be any problems? Or it just depends on the vendor? Is it ok to post the question here? Or is there a mail-list about diameter? Hsiao-Feng --------------7E7E91DDECD2F87E1E491EB9 Content-Type: text/x-vcard; charset=us-ascii; name="yhf.vcf" Content-Description: Card for ßN·¬ Content-Disposition: attachment; filename="yhf.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Yeh;Hsiao-Feng tel;work:+886-3-4245064 x-mozilla-html:FALSE fn;quoted-printable:=B8=AD=DFN=B7=AC org:Chunghwa Telecom Co. TL. adr:;;;;;; version:2.1 email;internet:yhf@chttl.com.tw end:vcard --------------7E7E91DDECD2F87E1E491EB9-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 29 14:28: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 OAA02381 for ; Mon, 29 Nov 1999 14:28: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 LAA26185; Mon, 29 Nov 1999 11:22:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA01552 for ietf-radius-outgoing; Mon, 29 Nov 1999 11:19:57 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199911291919.LAA05515@ha1mpk-mail.eng.sun.com> Date: Mon, 29 Nov 1999 11:12:40 -0800 To: "=?iso-8859-1?Q?=DFN=B7=AC?=" , Subject: Re: (radius) Diameter server operates with the Radius clients ? 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 >Hello, > >Will a Diameter server operates with the Radius clients well ? >Will there be any problems? >Or it just depends on the vendor? This is an implementation issue. THe DIAMETER protocol is able to detect RADIUS from DIAMETER packets, even if they are received on the same UDP port. >Is it ok to post the question here? >Or is there a mail-list about diameter? I would recommend the DIAMETER mailing list. see www.diameter.org for more information (the site will be updated at the end of the week to include the new specs). PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.