From owner-ietf-ppp@merit.edu Sat Jun 2 21:22:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14548 for ; Sat, 2 Jun 2001 21:22:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FA359120E; Sat, 2 Jun 2001 21:22:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F9899120F; Sat, 2 Jun 2001 21:22:00 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EC459120E for ; Sat, 2 Jun 2001 21:21:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A5DC5DDC4; Sat, 2 Jun 2001 21:22:15 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by segue.merit.edu (Postfix) with ESMTP id 2820B5DD95 for ; Sat, 2 Jun 2001 21:22:15 -0400 (EDT) Received: by lists.samba.org (Postfix, from userid 1020) id B07AB4531; Sat, 2 Jun 2001 18:21:49 -0700 (PDT) From: Paul Mackerras MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15129.37260.74204.739886@argo.ozlabs.ibm.com> Date: Sun, 3 Jun 2001 11:23:24 +1000 (EST) To: ietf-ppp@merit.edu Subject: CMU copyright on pppd bits X-Mailer: VM 6.75 under Emacs 20.4.1 Reply-To: paulus@samba.org Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit It has recently been drawn to my attention that much of the pppd package that I maintain has a copyright notice on it that doesn't permit modification. Here is an example: /* * Copyright (c) 1989 Carnegie Mellon University. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by Carnegie Mellon University. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ This is extremely embarrassing for me, if I can't get these notices changed I will have to stop maintaining and distributing pppd. Most of the files with this kind of notice are copyright Carnegie Mellon University. Is there anyone from CMU on this list? If so, can you tell me who to approach to get the notice changed? Paul. From owner-ietf-ppp@merit.edu Sat Jun 2 23:20:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16871 for ; Sat, 2 Jun 2001 23:20:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B90F9135B; Sat, 2 Jun 2001 23:20:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2693F9135C; Sat, 2 Jun 2001 23:20:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68D9791353 for ; Sat, 2 Jun 2001 23:20:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A84D5DDA7; Sat, 2 Jun 2001 23:20:27 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (unknown [208.46.234.163]) by segue.merit.edu (Postfix) with ESMTP id 88A1E5DD95 for ; Sat, 2 Jun 2001 23:20:26 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sat, 2 Jun 2001 23:19:48 -0400 Message-Id: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Jun 2001 23:19:46 -0400 To: paulus@samba.org, ietf-ppp@merit.edu From: Karl Fox Subject: Re: CMU copyright on pppd bits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Paul, Yes, I once used that same software for similar purposes. I don't see, however, any restriction on modification. If you're referring to the requirement that a) CMU be acknowledged and b) CMU's name not be used to promote derivative products, then I'm pretty sure there's a middle ground. We put CMU's name in the acknowledgements section of our documentation, but we didn't go around saying, "Hey, this is CMU code, so you should buy it." I don't think you have anything to worry about. Karl At 09:23 PM 6/2/01, Paul Mackerras wrote: >It has recently been drawn to my attention that much of the pppd >package that I maintain has a copyright notice on it that doesn't >permit modification. Here is an example: > >/* > * Copyright (c) 1989 Carnegie Mellon University. > * All rights reserved. > * > * Redistribution and use in source and binary forms are permitted > * provided that the above copyright notice and this paragraph are > * duplicated in all such forms and that any documentation, > * advertising materials, and other materials related to such > * distribution and use acknowledge that the software was developed > * by Carnegie Mellon University. The name of the > * University may not be used to endorse or promote products derived > * from this software without specific prior written permission. > * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR > * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. > */ > >This is extremely embarrassing for me, if I can't get these notices >changed I will have to stop maintaining and distributing pppd. > >Most of the files with this kind of notice are copyright Carnegie >Mellon University. Is there anyone from CMU on this list? If so, can >you tell me who to approach to get the notice changed? > >Paul. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp@merit.edu Sun Jun 3 00:02:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17560 for ; Sun, 3 Jun 2001 00:02:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CA2491355; Sat, 2 Jun 2001 23:47:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BBE891356; Sat, 2 Jun 2001 23:47:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AA8B91355 for ; Sat, 2 Jun 2001 23:47:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 117BB5DDC8; Sat, 2 Jun 2001 23:48:01 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 691C35DDA7 for ; Sat, 2 Jun 2001 23:48:00 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.3/8.11.3) id f533lWH27275; Sat, 2 Jun 2001 23:47:32 -0400 (EDT) (envelope-from barney) Date: Sat, 2 Jun 2001 23:47:32 -0400 From: Barney Wolff To: Karl Fox Cc: paulus@samba.org, ietf-ppp@merit.edu Subject: Re: CMU copyright on pppd bits Message-ID: <20010602234732.A27249@tp.databus.com> References: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net>; from karl@xc.org on Sat, Jun 02, 2001 at 11:19:46PM -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Judging from the brouhaha about ipfilter, I think the problem is that with copyright anything that is not expressly permitted is forbidden. So perhaps an official statement from CMU is needed. IANAL. Barney Wolff From owner-ietf-ppp@merit.edu Sun Jun 3 02:14:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28913 for ; Sun, 3 Jun 2001 02:14:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25C5391358; Sat, 2 Jun 2001 23:59:16 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4E1D9135D; Sat, 2 Jun 2001 23:59:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CBC491358 for ; Sat, 2 Jun 2001 23:59:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE9625DDA7; Sat, 2 Jun 2001 23:59:27 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by segue.merit.edu (Postfix) with ESMTP id B537D5DD95 for ; Sat, 2 Jun 2001 23:59:27 -0400 (EDT) Received: by lists.samba.org (Postfix, from userid 1020) id 1CFB74779; Sat, 2 Jun 2001 20:58:58 -0700 (PDT) From: Paul Mackerras MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15129.46699.83474.864720@argo.ozlabs.ibm.com> Date: Sun, 3 Jun 2001 14:00:43 +1000 (EST) To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: CMU copyright on pppd bits In-Reply-To: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> References: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> X-Mailer: VM 6.75 under Emacs 20.4.1 Reply-To: paulus@samba.org Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Karl Fox writes: > Yes, I once used that same software for similar purposes. I don't see, > however, any restriction on modification. If you're referring to the There is no explicit restriction on modification, but there is no explicit permission to modify either. Copyright law doesn't generally give you the right to modify somebody else's copyrighted work without explicit permission. This issue has blown up because of Darren Reed, the author of the ipfilter package used in the free BSD systems, asserting that he has *not* given permission for modification and that in fact modification is forbidden without his explicit permission (which he is generally not giving). So now people are going through all the generally- available free software looking for software with copyright notices similar to the one Darren is using. And pppd is one such. Hence my concern. > I don't think you have anything to worry about. I'm not expecting a letter from CMU's lawyers, but it is something that I would like to get straightened out. While I don't mind people modifying pppd, and I don't believe CMU does either, I still would very much prefer to keep on the right side of the letter of the law. Paul. From owner-ietf-ppp@merit.edu Sun Jun 3 11:09:17 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09876 for ; Sun, 3 Jun 2001 11:09:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA9A991218; Sun, 3 Jun 2001 11:09:15 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B68999121A; Sun, 3 Jun 2001 11:09:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E09D91218 for ; Sun, 3 Jun 2001 11:09:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BC925DDC0; Sun, 3 Jun 2001 11:09:32 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from klos.com (klos.mv.com [207.22.43.251]) by segue.merit.edu (Postfix) with ESMTP id 518475DDBB for ; Sun, 3 Jun 2001 11:09:30 -0400 (EDT) Received: (from patrick@localhost) by klos.com (8.9.3/8.9.3) id LAA02013; Sun, 3 Jun 2001 11:09:22 -0400 Date: Sun, 3 Jun 2001 11:09:22 -0400 From: Patrick Klos Message-Id: <200106031509.LAA02013@klos.com> To: ietf-ppp@merit.edu, paulus@samba.org Subject: Re: CMU copyright on pppd bits Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu >It has recently been drawn to my attention that much of the pppd >package that I maintain has a copyright notice on it that doesn't >permit modification. Here is an example: > >/* > * Copyright (c) 1989 Carnegie Mellon University. > * All rights reserved. > * > * Redistribution and use in source and binary forms are permitted > * provided that the above copyright notice and this paragraph are > * duplicated in all such forms and that any documentation, > * advertising materials, and other materials related to such > * distribution and use acknowledge that the software was developed > * by Carnegie Mellon University. The name of the > * University may not be used to endorse or promote products derived > * from this software without specific prior written permission. > * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR > * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. > */ From the text of this notice, it's fair to assume that they expect people to "redistribute and use" this code, as well as "derive" other code from this code. By granting the right to "use" and "derive" software from this code, they have to expect that people will modify this code in some way, shape or form. The only restriction I see placed on any code derived from this code is that is must include this copyright notice indicating it was indeed derived from some CMU based code, and that you can't use the name of CMU as part of your marketing. It seems pretty straightforward to me. >This is extremely embarrassing for me, if I can't get these notices >changed I will have to stop maintaining and distributing pppd. Even if you felt this way, how much CMU code are you using in pppd? I can't imagine it would be a whole lot? Would it be easier to remove any code you derived from CMU code and remove the notices altogether? Patrick ============================================================================ Patrick Klos Email: patrick@klos.com Klos Technologies, Inc. Web: http://www.klos.com/ ============================================================================ From owner-ietf-ppp@merit.edu Sun Jun 3 18:52:07 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11535 for ; Sun, 3 Jun 2001 18:52:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A07609123D; Sun, 3 Jun 2001 18:51:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F0FA91240; Sun, 3 Jun 2001 18:51:52 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 617FF9123D for ; Sun, 3 Jun 2001 18:51:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B9E05DDA7; Sun, 3 Jun 2001 18:52:07 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (unknown [208.46.234.163]) by segue.merit.edu (Postfix) with ESMTP id 22E055DD94 for ; Sun, 3 Jun 2001 18:52:07 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sun, 3 Jun 2001 18:51:46 -0400 Message-Id: <4.3.2.7.2.20010603184753.053b36d0@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Jun 2001 18:51:44 -0400 To: paulus@samba.org From: Karl Fox Subject: Re: CMU copyright on pppd bits Cc: ietf-ppp@merit.edu In-Reply-To: <15129.46699.83474.864720@argo.ozlabs.ibm.com> References: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 12:00 AM 6/3/01, Paul Mackerras wrote: >This issue has blown up because of Darren Reed, the author of the >ipfilter package used in the free BSD systems, asserting that he has >*not* given permission for modification and that in fact modification >is forbidden without his explicit permission (which he is generally >not giving). This makes sense if his copyrighted software, as distributed, contains a statement disallowing modification. Otherwise, I doubt he has a leg to stand on. People get really twitchy when dealing with legal issues. I've never been able to identify with that; just using common sense and reading really, really carefully has always worked well for me. But what does this have to do with PPPEXT? Sorry about that. Karl Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp@merit.edu Sun Jun 3 19:59:50 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11850 for ; Sun, 3 Jun 2001 19:59:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 435249123E; Sun, 3 Jun 2001 19:37:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1557E9123F; Sun, 3 Jun 2001 19:37:05 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 959689123E for ; Sun, 3 Jun 2001 19:37:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECB865DDD6; Sun, 3 Jun 2001 19:37:21 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by segue.merit.edu (Postfix) with ESMTP id C6C375DDD5 for ; Sun, 3 Jun 2001 19:37:21 -0400 (EDT) Received: by lists.samba.org (Postfix, from userid 1020) id 5E8B6444B; Sun, 3 Jun 2001 16:31:02 -0700 (PDT) From: Paul Mackerras MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15130.51483.244511.106139@argo.ozlabs.ibm.com> Date: Mon, 4 Jun 2001 09:32:43 +1000 (EST) To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: CMU copyright on pppd bits In-Reply-To: <4.3.2.7.2.20010603184753.053b36d0@mail.via-net.net> References: <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> <4.3.2.7.2.20010603184753.053b36d0@mail.via-net.net> X-Mailer: VM 6.75 under Emacs 20.4.1 Reply-To: paulus@samba.org Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Karl Fox writes: > But what does this have to do with PPPEXT? Sorry about that. I was hoping that one of the original developers from CMU might be on this list. I'll shut up now. :) Paul. From owner-ietf-ppp@merit.edu Sun Jun 3 22:59:42 2001 Received: from trapdoor.merit.edu ([198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14901 for ; Sun, 3 Jun 2001 22:59:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0949791246; Sun, 3 Jun 2001 22:59:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C96A291247; Sun, 3 Jun 2001 22:59:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A096491246 for ; Sun, 3 Jun 2001 22:59:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32CF55DDD0; Sun, 3 Jun 2001 22:59:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (unknown [208.46.234.163]) by segue.merit.edu (Postfix) with ESMTP id 70B2C5DDAB for ; Sun, 3 Jun 2001 22:59:30 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sun, 3 Jun 2001 22:58:58 -0400 Message-Id: <4.3.2.7.2.20010603225802.055ba650@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Jun 2001 22:58:55 -0400 To: Craig Fox , paulus@samba.org From: Karl Fox Subject: Re: CMU copyright on pppd bits Cc: ietf-ppp@merit.edu, drew.perkins@onfiber.com In-Reply-To: <4.3.2.7.2.20010603203542.00ce3a10@mira-sjcm-2.cisco.com> References: <15130.51483.244511.106139@argo.ozlabs.ibm.com> <4.3.2.7.2.20010603184753.053b36d0@mail.via-net.net> <4.3.2.7.2.20010602231937.00e5d100@mail.via-net.net> <4.3.2.7.2.20010603184753.053b36d0@mail.via-net.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:56 PM 6/3/01, Craig Fox wrote: >Over the possible objections of Karl, I wish you would report on what >you learn. No, I don't object at all. I just put that comment in to satisfy those folks who tend to object to noisy mailing lists. Karl Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp@merit.edu Mon Jun 4 08:37:33 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05276 for ; Mon, 4 Jun 2001 08:37:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BD6A9125E; Mon, 4 Jun 2001 08:37:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDC729125F; Mon, 4 Jun 2001 08:37:27 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E39E49125E for ; Mon, 4 Jun 2001 08:37:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EE385DDD8; Mon, 4 Jun 2001 08:37:46 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 69E4A5DDA6 for ; Mon, 4 Jun 2001 08:37:45 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f54CbQO10377; Mon, 4 Jun 2001 14:37:26 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f54CbP415673; Mon, 4 Jun 2001 15:37:25 +0300 (EET DST) Message-ID: <3B1B8105.5CA7AF8F@lmf.ericsson.se> Date: Mon, 04 Jun 2001 15:37:25 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Cc: henry.haverinen@nokia.com, jari@arkko.com Subject: New EAP scheme for 3G AKA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello, I'd like to announce that Henry Haverinen and myself have produced an Internet-Draft that specifies how to run the 3G authentication scheme "AKA" within EAP: http://search.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-00.txt The abstract states "This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the UMTS AKA authentication mechanism. AKA is based on symmetric keys, and runs in a UMTS Subscriber Identity Module, a smart card like device. AKA provides also backward compatibility to GSM authentication, making it possible to use EAP AKA for authenticating both GSM and UMTS subscribers." Comments on this draft would be wellcome. We'd also like to hold a presentation on this draft in the London IETF. Finally, we'd like this working group to consider this draft for a Standards Track status, for the following reasons: - The draft is able to handle both GSM and UTMS authentication. - The large number of existing and future GSM/UMTS clients (500-1000M) makes many applications likely. - Possibilities for GSM-UMTS-WLAN-HIPERLAN interworking scenarios would benefit from an authentication scheme for which substantial deployment and billing infra- structure already exists. - First 3GPP indications point to an interest to use this scheme as a part of their infrastructure. (- The 3GPP2 has also adopted AKA though I can't say exactly in which manner they intend to use it, and whether the EAP AKA scheme would be useful to them.) Jari From owner-ietf-ppp@merit.edu Mon Jun 4 13:06:26 2001 Received: from trapdoor.merit.edu (postfix@[198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13067 for ; Mon, 4 Jun 2001 13:06:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB88F9126E; Mon, 4 Jun 2001 13:06:19 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B4D891270; Mon, 4 Jun 2001 13:06:19 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F6719126E for ; Mon, 4 Jun 2001 13:06:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46E3E5DDB9; Mon, 4 Jun 2001 13:06:38 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id EFCBC5DD9F for ; Mon, 4 Jun 2001 13:06:37 -0400 (EDT) Received: from karl-w98l.xc.org (208.46.234.163 [208.46.234.163]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MDWPVKJD; Sat, 2 Jun 2001 19:50:53 -0600 Message-Id: <4.3.2.7.2.20010602214901.00ba2e20@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Jun 2001 21:50:17 -0400 To: paulus@samba.org, ietf-ppp@merit.edu From: Karl Fox Subject: Re: CMU copyright on pppd bits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Paul, Yes, I once used that same software for similar purposes. I don't see, however, any restriction on modification. If you're referring to the requirement that a) CMU be acknowledged and b) CMU's name not be used to promote derivative products, then I'm pretty sure there's a middle ground. We put CMU's name in the acknowledgements section of our documentation, but we didn't go around saying, "Hey, this is CMU code, so you should buy it." I don't think you have anything to worry about. Karl At 09:23 PM 6/2/01, Paul Mackerras wrote: >It has recently been drawn to my attention that much of the pppd >package that I maintain has a copyright notice on it that doesn't >permit modification. Here is an example: > >/* > * Copyright (c) 1989 Carnegie Mellon University. > * All rights reserved. > * > * Redistribution and use in source and binary forms are permitted > * provided that the above copyright notice and this paragraph are > * duplicated in all such forms and that any documentation, > * advertising materials, and other materials related to such > * distribution and use acknowledge that the software was developed > * by Carnegie Mellon University. The name of the > * University may not be used to endorse or promote products derived > * from this software without specific prior written permission. > * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR > * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. > */ > >This is extremely embarrassing for me, if I can't get these notices >changed I will have to stop maintaining and distributing pppd. > >Most of the files with this kind of notice are copyright Carnegie >Mellon University. Is there anyone from CMU on this list? If so, can >you tell me who to approach to get the notice changed? > >Paul. Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp@merit.edu Tue Jun 5 21:03:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02366 for ; Tue, 5 Jun 2001 21:03:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 508C2912E2; Tue, 5 Jun 2001 21:01:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21F97912E3; Tue, 5 Jun 2001 21:01:55 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09FFC912E2 for ; Tue, 5 Jun 2001 21:01:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EEFF5DDE1; Tue, 5 Jun 2001 21:02:16 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CC9CE5DDB6 for ; Tue, 5 Jun 2001 21:02:15 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25046; Tue, 5 Jun 2001 19:01:57 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14249; Tue, 5 Jun 2001 21:01:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5612gM09193; Tue, 5 Jun 2001 21:02:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.33074.526928.183163@gargle.gargle.HOWL> Date: Tue, 5 Jun 2001 21:02:42 -0400 (EDT) From: James Carlson To: Zachary Uram Cc: "John R. Martz" , ietf-ppp@merit.edu Subject: Re: MTU and other stuff In-Reply-To: Zachary Uram's message of 1 June 2001 17:41:44 References: <14638.54113.478233.783827@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Zachary Uram writes: > If I have DSL (xDSL) modem doing PPP what is correct MTU size If you're using PPPoE (I assume you are), then the MTU can be no larger than 1492. > and > how do I set this in Linux? That's not appropriate for this mailing list. Try linux-ppp@vger.kernel.org instead. > What is "black hole timeout"?? Probably a Linux thing. You'll need to go to some mailing list related to Linux for such questions. This isn't the right list. > How do I calculate: > > 1) my lag to a given dest. addres (is this some formular of > current download rate/current upload rate?) > 2) my min/max bandwidth in a given period time > 3) min/max latency Similarly off-topic. There are all sorts of performance-related tools out there; some ok, some not. You'll have to do some digging on your own. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 6 13:05:01 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05689 for ; Wed, 6 Jun 2001 13:05:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 730B491301; Wed, 6 Jun 2001 13:04:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A7D091302; Wed, 6 Jun 2001 13:04:44 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E1C91301 for ; Wed, 6 Jun 2001 13:04:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3F3C5DDAC; Wed, 6 Jun 2001 13:05:06 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by segue.merit.edu (Postfix) with SMTP id B8CA65DE01 for ; Wed, 6 Jun 2001 13:05:06 -0400 (EDT) Date: Wed, 6 Jun 2001 13:04:47 -0400 From: sean@plan9.bell-labs.com To: ietf-ppp@merit.edu Subject: ppp compression MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010606170506.B8CA65DE01@segue.merit.edu> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello, We have developed a new technique that improves the performance of PPP's CCP compression protocol when packets are lost or corrupted. This technique can be used with many compression algorithms and does not require changes to CCP. We are considering writing an draft RFC describing this idea, but first we wanted to get this list's opinion if there would be interest in this. Previous approaches to packet compression either assume the packets arrive reliably and reset the compression state when an error has occurred, like PPP's CCP "streaming compression", or don't use inter-packet compression, like IPComp's "stateless compression". Streaming compression has poor performance when packets are lost, but achieves greater compression, and has better performance when most packets are correctly received. In our method, the sender knows which packets have been received and only uses these for compressing future packets. In this way, when a packet is received it can be decompressed, even if other packets have been lost. The receiver updates the sender by piggybacking acknowledgements in packets traveling in the reverse direction; the acks are only used to inform the compressor of successfully received packets, not for retransmission. Our method combines the error resiliency of stateless compression with inter-packet compression. It performs comparably to streaming compression with low error rates, and comparably to stateless compression with high error rates. We have a prototype PPP CCP implementation of our algorithm, and experimental results comparing TCP performance when run over PPP with varying error rates, using our algorithm and stateless and streaming compression methods. A slightly out of date paper is available at http://www.cs.bell-labs.com/who/seanq/pub.html#comp. This paper doesn't include the PPP and TCP results, but gives more details about the technique. Sean Dorward and Sean Quinlan sean@research.bell-labs.com, seanq@research.bell-labs.com From owner-ietf-ppp@merit.edu Wed Jun 6 15:26:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08179 for ; Wed, 6 Jun 2001 15:26:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71695913C3; Wed, 6 Jun 2001 15:25:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EB10913CC; Wed, 6 Jun 2001 15:25:56 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11C49913C3 for ; Wed, 6 Jun 2001 15:25:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEC485DE11; Wed, 6 Jun 2001 15:26:15 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7315F5DD8D for ; Wed, 6 Jun 2001 15:26:15 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24785; Wed, 6 Jun 2001 13:25:53 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05233; Wed, 6 Jun 2001 15:25:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f56JQdl09880; Wed, 6 Jun 2001 15:26:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15134.33775.127317.261125@gargle.gargle.HOWL> Date: Wed, 6 Jun 2001 15:26:39 -0400 (EDT) From: James Carlson To: sean@plan9.bell-labs.com Cc: ietf-ppp@merit.edu Subject: Re: ppp compression In-Reply-To: sean@plan9.bell-labs.com's message of 6 June 2001 13:04:47 References: <20010606170506.B8CA65DE01@segue.merit.edu> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit sean@plan9.bell-labs.com writes: > In our method, the sender knows which packets have been received and > only uses these for compressing future packets. In this way, when a > packet is received it can be decompressed, even if other packets > have been lost. The receiver updates the sender by piggybacking > acknowledgements in packets traveling in the reverse direction; > the acks are only used to inform the compressor of successfully > received packets, not for retransmission. I've just read through your paper quickly. It's a useful idea, but I was a little surprised to see no mention at all of the ROHC work that's been done. I seem to recall that several similar schemes were proposed there (GEHCO, perhaps) and that all of these have IPR issues. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 6 17:53:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09668 for ; Wed, 6 Jun 2001 17:53:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A93091317; Wed, 6 Jun 2001 17:50:19 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5DFC9131A; Wed, 6 Jun 2001 17:50:18 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8BAF91317 for ; Wed, 6 Jun 2001 17:50:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED9085DE01; Wed, 6 Jun 2001 17:50:37 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with SMTP id 92A525DD8D for ; Wed, 6 Jun 2001 17:50:37 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Jun 6 17:48:31 EDT 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Wed Jun 6 17:49:02 EDT 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id 85ADA5701F; Wed, 6 Jun 2001 16:48:47 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: James Carlson Cc: sean@plan9.bell-labs.com, ietf-ppp@merit.edu Subject: Re: ppp compression In-Reply-To: <15134.33775.127317.261125@gargle.gargle.HOWL> References: <20010606170506.B8CA65DE01@segue.merit.edu> <15134.33775.127317.261125@gargle.gargle.HOWL> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010606214847.85ADA5701F@king.research.bell-labs.com> Date: Wed, 6 Jun 2001 16:48:47 -0500 (CDT) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson (JC) writes: JC> I've just read through your paper quickly. It's a useful idea, but I JC> was a little surprised to see no mention at all of the ROHC work JC> that's been done. I seem to recall that several similar schemes were JC> proposed there (GEHCO, perhaps) and that all of these have IPR issues. Just for the record, GEHCO has no IPR associated with it. The basic idea is simple, and we were not the first to propose it. -Pete From owner-ietf-ppp@merit.edu Thu Jun 7 07:11:28 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03544 for ; Thu, 7 Jun 2001 07:11:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C3B091341; Thu, 7 Jun 2001 07:08:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0704691343; Thu, 7 Jun 2001 07:08:00 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46B6491341 for ; Thu, 7 Jun 2001 07:07:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7226D5DDB1; Thu, 7 Jun 2001 07:08:21 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 9EF365DDA9 for ; Thu, 7 Jun 2001 07:08:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03348; Thu, 7 Jun 2001 07:07:33 -0400 (EDT) Message-Id: <200106071107.HAA03348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-srp-02.txt Date: Thu, 07 Jun 2001 07:07:33 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP SRP-SHA1 Authentication Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-eap-srp-02.txt Pages : 15 Date : 06-Jun-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an Extensible Authentication Protocol (EAP) [2] framework to allow the use of multiple authentication mechanisms without fixing the mechanism to be used during initial link negotiation. This document defines an authentication mechanism for EAP called SRP-SHA1, and allows the use of the Secure Remote Password (SRP) [3] protocol as a PPP link authentication method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-srp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-srp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-srp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606101034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-srp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-srp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606101034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Jun 7 20:29:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16569 for ; Thu, 7 Jun 2001 20:29:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7E7B913C9; Thu, 7 Jun 2001 10:05:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2C0B913CD; Thu, 7 Jun 2001 10:05:11 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C5A1913C9 for ; Thu, 7 Jun 2001 10:05:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C4D075DE20; Thu, 7 Jun 2001 10:05:35 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by segue.merit.edu (Postfix) with ESMTP id 5D83B5DE24 for ; Thu, 7 Jun 2001 10:05:26 -0400 (EDT) Received: from vishnu.vishnu (unknown [203.197.193.57]) by del2.vsnl.net.in (Postfix) with ESMTP id EFEF13F584 for ; Thu, 7 Jun 2001 19:35:43 +0530 (IST) Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MLZP8KHZ; Thu, 7 Jun 2001 19:34:18 +0530 Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06072001-193057-239.MMD@vishnu; Thu, 7 Jun 2001 19:30:57 +0530 Delivered-To: sandy@amdale.com Received: (qmail 6451 invoked by uid 104); 7 Jun 2001 12:19:25 -0000 Delivered-To: amdale.com-sandeepj@AMDALE.COM Received: (qmail 6419 invoked by alias); 7 Jun 2001 12:19:25 -0000 Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 7 Jun 2001 12:19:25 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28853 for ietf-123-outbound.01@ietf.org; Thu, 7 Jun 2001 07:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA28738 for ; Thu, 7 Jun 2001 07:07:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03348; Thu, 7 Jun 2001 07:07:33 -0400 (EDT) Message-Id: <200106071107.HAA03348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-srp-02.txt Date: Thu, 07 Jun 2001 07:07:33 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP SRP-SHA1 Authentication Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-eap-srp-02.txt Pages : 15 Date : 06-Jun-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an Extensible Authentication Protocol (EAP) [2] framework to allow the use of multiple authentication mechanisms without fixing the mechanism to be used during initial link negotiation. This document defines an authentication mechanism for EAP called SRP-SHA1, and allows the use of the Secure Remote Password (SRP) [3] protocol as a PPP link authentication method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-srp-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-srp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-srp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606101034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-srp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-srp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606101034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Jun 7 23:45:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20940 for ; Thu, 7 Jun 2001 23:45:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D138E913F0; Thu, 7 Jun 2001 17:44:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FDE0913F1; Thu, 7 Jun 2001 17:44:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51C38913F0 for ; Thu, 7 Jun 2001 17:44:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BFDE5DD8D; Thu, 7 Jun 2001 17:44:34 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0A8945DDFA for ; Thu, 7 Jun 2001 17:44:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA65492; Thu, 7 Jun 2001 14:33:36 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 7 Jun 2001 14:33:36 -0700 (PDT) From: Bernard Aboba To: ietf-ppp@merit.edu Cc: aboba@internaut.com Subject: Comments on draft-ietf-pppext-eap-srp-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Overall, this version of the draft is much improved. Here are some additional comments based on the -02 draft: Page 1: "This document defines an authentication mechanism for EAP called SRP-SHA1 and allows the use of the Secure Remote Password (SRP) [3] protocol as a PPP link authentication method." [BA - EAP is now being used as a link authentication method for IEEE 802 and possibly Bluetooth. Suggest that we look at generalizing the text to cover these cases as well. For example in the above sentence "PPP" could be deleted, enabling use of EAP SRP for authentication of other links, too.] Section 2.1, page 4: "All SRP authentication is driven by the authenticator (server). The authenticatee (client) MUST NOT retransmit Response messages, but SHOULD terminate the link if a Request is not received within a reasonable time period. The authenticator SHOULD silently ignore unexpected Response messages. The authenticatee MUST respond using EAP Nak if any unknown Subtype or otherwise unacceptable message is received." I think this paragraph is at variance with text within RFC 2284. Recommendation is that an Alert message be added so as not to overload use of EAP Nak, and reference RFC 2284 sections so as to ensure sync. For example, RFC 2284, section 2.2.1 states: The Request packet is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAP packet with the Code field set to 1 (Request). Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response packet in reply to a Request packet. Responses MUST only be sent in reply to a received Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request." This seems to indicate that the authenticatee MUST transmit additional Request packets instead of silently ignoring unexpected Response messages. Also, RFC 2284, section 2.2.1 states: "However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. An initial specification of Types follows in a later section of this document." So the purpose of the NAK message is to indicate an unacceptable Request type, not to indicate an unknown Subtype or otherwise unacceptable message. Currently a Nak message is only able to indicate the alternative desired authentication Type, rather than indicating errors of other types. Section 2.1, page 4: "The Identifier SHOULD be changed for each Request message sent." This seems to conflicts with RFC 2284, section 2.2.1 which states: "The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend its Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request." Recommend that the document copy the RFC 2284 text or refer to it. Section 2.2, page 5: "A single octet specifying the type of hash algorithm to be used with SRP. For SHA-1 based SRP as described in this document, this value MUST be set to 1. An authenticatee that does not support the hash algorithm specified by the authenticator MUST reply with EAP Nak to disable EAP SRP authentication." Like the idea of supporting multiple hash algorithms. However, I think you're overloading use of EAP Nak here; it's really only used to negotiate alternative EAP methods, not as a general purpose error indication. I'd suggest defining an Alert message with EAP SRP that can be used to transmit error conditions of various sorts. However this wouldn't get you the negotiation capabilities that I think are needed (see below). Since the hash type can now be varied, that perhaps the protocol should be entited simply "EAP SRP" instead of "EAP SRP-SHA1"? Section 2.5, page 9: "The above described SHA1 hash to produce the long-term private key x, as described in [3], SHOULD be used by default in EAP SRP-SHA1. As an implementation open, however, the x value used above MAY instead be derived from any mutually-chosen hashing algorithm, provided that the security of that algorithm is acceptable to both authentication parties." Given that an EAP Nak cannot suggest an alternative hash algorithm, only a new EAP method, it's not clear how the hash algorithm can be mutually chosen if there are multiple choices available. Perhaps multiple hash types need to be advertised by the authenticator, with one chosen by the client in the Client Key Subtype-data? On a slightly separate note, perhaps it makes it makes sense to expand the size of the field to two octets so as to allow for a protected ciphersuite negotiation, which would include both the cipher and the hash. Note that this would require adding the selected ciphersuite to the final hash so as to protect against modification by man in the middle. Examples I think that some examples of how EAP SRP authentication will proceed in successful and unsuccessful cases would be helpful. Here are some examples that might be worth including: In the case where the EAP SRP mutual authentication is successful, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 1 (cipersuite?, salt, prime modulus, generator) EAP-Response/ EAP-Type=EAP SRP, Subtype 1 (ciphersuite?, A)-> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 2 (B) EAP-Response/ EAP-Type=EAP SRP, Subtype 2 (M1) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 3 (M2) EAP-Response/ EAP-Type=EAP SRP, Subtype 3 -> <- EAP-Success In the case where server authentication is unsuccessful, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 1 (cipersuite?, salt, prime modulus, generator) EAP-Response/ EAP-Type=EAP SRP, Subtype 1 (ciphersuite?, A)-> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 2 (B) EAP-Response/ EAP-Type=EAP SRP, Subtype 2 (M1) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 3 (M2) EAP-Response/ EAP-Type=EAP SRP, Subtype 3 -> <- EAP-Failure In the case where the client fails to authenticate to the server, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 1 (cipersuite?, salt, prime modulus, generator) EAP-Response/ EAP-Type=EAP SRP, Subtype 1 (ciphersuite?, A)-> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 2 (B) EAP-Response/ EAP-Type=EAP SRP, Subtype 2 (M1) -> <- EAP-Failure In the case where server authentication is unsuccessful, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 1 (cipersuite?, salt, prime modulus, generator) EAP-Response/ EAP-Type=EAP SRP, Subtype 1 (ciphersuite?, A)-> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 2 (B) EAP-Response/ EAP-Type=EAP SRP, Subtype 2 (M1) -> <- EAP-Request/ EAP-Type=EAP SRP, Subtype 3 (M2) EAP-Response/ EAP-Type=EAP SRP, Subtype 3 [Disconnect] -> <- EAP-Failure [Question: how is the Disconnect action expressed when EAP runs over IEEE 802 media?] From owner-ietf-ppp@merit.edu Tue Jun 12 04:50:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10996 for ; Tue, 12 Jun 2001 04:50:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C190F912C4; Tue, 12 Jun 2001 04:50:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 930BB912C5; Tue, 12 Jun 2001 04:50:11 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70EA6912C4 for ; Tue, 12 Jun 2001 04:50:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27CDC5DDEB; Tue, 12 Jun 2001 04:50:45 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by segue.merit.edu (Postfix) with ESMTP id 4AD2B5DD8F for ; Tue, 12 Jun 2001 04:50:44 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id f5C8oIv26858 for ; Tue, 12 Jun 2001 10:50:18 +0200 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA23373 for ; Tue, 12 Jun 2001 10:50:13 +0200 (MET DST) Received: from vies141a.sie.siemens.at(158.226.134.117) by scesie13 via smap (V2.0beta) id xma021445; Tue, 12 Jun 01 10:48:52 +0200 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 10:48:49 +0200 Message-ID: From: Klausberger Walter To: ietf-ppp@merit.edu Subject: PPP Accounting Date: Tue, 12 Jun 2001 10:48:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi all, As there is no RADIUS WG existing anymore, a question to all PPP experts here. - When should PPP Accounting start? (after or before IPCP negotiation) - What traffic should be counted (simply payload packets, PPP negotiation like LCP and IPCP, hello packets,...) I had some lengthy discussions with my colleagues and I need a general opinion. Some say that the whole authentication traffic should be counted. regards - Walter From owner-ietf-ppp@merit.edu Tue Jun 12 12:58:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19453 for ; Tue, 12 Jun 2001 12:58:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B224912DC; Tue, 12 Jun 2001 12:58:41 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA9B7912DD; Tue, 12 Jun 2001 12:58:40 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2A12912DC for ; Tue, 12 Jun 2001 12:58:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BE1C5DD9F; Tue, 12 Jun 2001 12:59:15 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9BDC35DD9E for ; Tue, 12 Jun 2001 12:59:14 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15173; Tue, 12 Jun 2001 09:58:36 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20039; Tue, 12 Jun 2001 12:57:33 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5CGwKS18920; Tue, 12 Jun 2001 12:58:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15142.18987.547616.716497@gargle.gargle.HOWL> Date: Tue, 12 Jun 2001 12:58:19 -0400 (EDT) From: James Carlson To: Bernard Aboba Cc: ietf-ppp@merit.edu Subject: Re: Comments on draft-ietf-pppext-eap-srp-02.txt In-Reply-To: Bernard Aboba's message of 7 June 2001 14:33:36 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bernard Aboba writes: > Overall, this version of the draft is much improved. Thanks ... > [BA - EAP is now being used as a link authentication method for IEEE 802 > and possibly Bluetooth. Suggest that we look at generalizing the text to > cover these cases as well. For example in the above sentence "PPP" could > be deleted, enabling use of EAP SRP for authentication of other links, > too.] OK. (Note that the underlying EAP document makes multiple explicit references to PPP as well.) > I think this paragraph is at variance with text within RFC 2284. Recommendation > is that an Alert message be added so as not to overload use of EAP Nak, > and reference RFC 2284 sections so as to ensure sync. While I recognize that the mechanism in EAP is extremely limited, I'm not so sure it's helpful to add a new EAP message type to carry this distinction. > For example, RFC 2284, section 2.2.1 states: [...] > > This seems to indicate that the authenticatee MUST transmit additional Request packets > instead of silently ignoring unexpected Response messages. I don't get that from the 2.2.1 text, and the two clauses in your statement are most certainly not in conflict. The only thing section 2.2.1 says is that the authenticator MUST continue *retransmitting* until it receives a valid Response message or the retry counter expires. Retransmit is defined only in the context of a timer -- not a Response of any type. It specifically does not say that reception of an unexpected Response should trigger any action. Going with the spirit of the protocol, it should be dropped. As an implementor, I would log the first unexpected Response but allow the timer to run. On a second unexpected Response, I would just send Failure and be done with it. > Also, RFC 2284, section 2.2.1 states: [...] > > So the purpose of the NAK message is to indicate an unacceptable Request type, not to > indicate an unknown Subtype or otherwise unacceptable message. Currently a Nak message > is only able to indicate the alternative desired authentication Type, > rather than indicating errors of other types. I added that hash type thing at the request of one of the reviewers of -00. On further thought, it's a bad thing. If someone really needs a different hash type, then that should just be defined as a new EAP Request Type, and reuse the basic framework in this draft. EAP doesn't support negotiation within the individual message Type, and I don't think I should teach it to do so. It'll just get too messy. > Section 2.1, page 4: > > "The Identifier SHOULD be changed for each Request message sent." > > This seems to conflicts with RFC 2284, section 2.2.1 which states: Right; my error. I'll fix that. > Section 2.2, page 5: [...] > Like the idea of supporting multiple hash algorithms. However, I > think you're overloading use of EAP Nak here; it's really only used to > negotiate alternative EAP methods, not as a general purpose error > indication. I'll withdraw that. It's a mistake. > Section 2.5, page 9: [...] > Given that an EAP Nak cannot suggest an alternative hash algorithm, only a > new EAP method, it's not clear how the hash algorithm can be mutually > chosen if there are multiple choices available. Perhaps multiple hash types need to be > advertised by the authenticator, with one chosen by the client in the Client > Key Subtype-data? If the two are not in agreement on the type of hash to be used, then there's no hope of authenticating through this mechanism. Authentication is a mutual thing -- you need to be pre-configured to accept some particular credentials, and this arrangement is outside of the domain of the protocol. I don't agree that negotiation is warranted here. > On a slightly separate note, perhaps it makes it makes sense to expand the > size of the field to two octets so as to allow for a protected > ciphersuite negotiation, which would include both the cipher and the > hash. Note that this would require adding the selected ciphersuite to the > final hash so as to protect against modification by man in the middle. Yes, if it were negotiated, I'd agree that it needs to be in the final hash. This very likely means that the ID and Type numbers should also be in the hash. I'll fix that. > Examples > > I think that some examples of how EAP SRP authentication will proceed in > successful and unsuccessful cases would be helpful. Here are some > examples that might be worth including: [...] I agree; I'll add those. Thanks! > In the case where the client fails to authenticate to the server, the > conversation will appear as follows: [...] > EAP-Response/ > EAP-Type=EAP SRP, > Subtype 2 > (M1) -> > <- EAP-Failure Actually, an implementation *could* continue with a fake Request Subtype 3 in order to avoid giving the peer too much information. (I'm not paranoid about this, but some implementors might be.) [...] > EAP-Response/ > EAP-Type=EAP SRP, > Subtype 3 > [Disconnect] -> > <- EAP-Failure > > [Question: how is the Disconnect action expressed > when EAP runs over IEEE 802 media?] The PCMCIA card is ejected from the system and falls on the floor, I'd guess. ;-} The EAP document says that you should accept LCP Terminate-Request as equivalent to authentication failure. Frankly, I neither know nor care much what the IEEE is doing with EAP. If they don't have the necessary supporting semantics to use the protocol as written, then they're likely to run into all sorts of problems. It'd probably be good if they ran these things by the working group ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 13 01:14:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02524 for ; Wed, 13 Jun 2001 01:14:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44A09912EF; Wed, 13 Jun 2001 01:14:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16248912FC; Wed, 13 Jun 2001 01:14:32 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC2B5912EF for ; Wed, 13 Jun 2001 01:14:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 75BCD5DDF0; Wed, 13 Jun 2001 01:15:06 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6BCB45DDB5 for ; Wed, 13 Jun 2001 01:15:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA01144; Tue, 12 Jun 2001 22:08:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 12 Jun 2001 22:08:59 -0700 (PDT) From: Bernard Aboba To: James Carlson Cc: ietf-ppp@merit.edu Subject: Re: Comments on draft-ietf-pppext-eap-srp-02.txt In-Reply-To: <15142.18987.547616.716497@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I had one other comment that I left off the original message. That is that I think that the prime modulus/generator groups should be expressed in terms of a "group number" rather than sending the actual values. For example, it would be possible to assign group numbers to the prime modulus/generator groups included in the SRP source code or the Appendix of the SASL-SRP draft. Even though prime moduli > 512 bits (or even 1024 bits) is recommended, I'd probably leave them all in. Sending a group number instead of the actual values makes it easier for the client to determine that the group is valid. This could be a fairly complex task if you allow arbitrary prime modulus/generator values to be sent. > I added that hash type thing at the request of one of the reviewers of > -00. On further thought, it's a bad thing. If someone really needs a > different hash type, then that should just be defined as a new EAP > Request Type, and reuse the basic framework in this draft. I think that makes sense. Either you go with a fixed hash type, or you need to enable negotiation. Not clear that negotiation is worth it for this particular function (hash to be used in EAP SRP). > This very likely means that the ID and Type numbers should also be in > the hash. I'll fix that. That would have the nice feature of protecting the EAP conversation. I think that is a good thing. > Actually, an implementation *could* continue with a fake Request > Subtype 3 in order to avoid giving the peer too much information. > (I'm not paranoid about this, but some implementors might be.) OK. Would be good to give that as an example, to guide implementors. > The EAP document says that you should accept LCP Terminate-Request as > equivalent to authentication failure. Actually, it says that implementations need to be prepared to handle loss of a Success or Failure message, since these messages aren't ACK'd. Accepting LCP Terminate-Request as an alternative indication of Failure or a Network Protocol packet as an alternative indication of Success is PPP's way of fulfilling that requirement. From owner-ietf-ppp@merit.edu Wed Jun 13 09:10:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22050 for ; Wed, 13 Jun 2001 09:10:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FAAE91211; Wed, 13 Jun 2001 09:10:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3BD391300; Wed, 13 Jun 2001 09:10:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E9D091211 for ; Wed, 13 Jun 2001 09:10:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 654815DDF3; Wed, 13 Jun 2001 09:11:32 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-202.aiinet.com [38.195.70.202]) by segue.merit.edu (Postfix) with ESMTP id C78E55DDBF for ; Wed, 13 Jun 2001 09:11:31 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 13 Jun 2001 09:10:53 -0400 Message-Id: <4.3.2.7.2.20010613090910.04d63f00@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Jun 2001 09:10:51 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: No PPPEXT meeting at London IETF Cc: Thomas Narten , Erik Nordmark Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu PPPEXT will not meet at the London IETF meeting. I look forward to seeing you all this winter at Salt Lake City. Karl Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp@merit.edu Wed Jun 13 10:32:18 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23993 for ; Wed, 13 Jun 2001 10:32:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E731391307; Wed, 13 Jun 2001 10:30:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE6309130C; Wed, 13 Jun 2001 10:30:52 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5494691307 for ; Wed, 13 Jun 2001 10:30:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66F6E5DD9B; Wed, 13 Jun 2001 10:31:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 3EAE75DD8C for ; Wed, 13 Jun 2001 10:31:21 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5DEUqN19523; Wed, 13 Jun 2001 16:30:52 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5DEUoE09432; Wed, 13 Jun 2001 17:30:51 +0300 (EET DST) Message-ID: <3B27791A.E25F24C7@lmf.ericsson.se> Date: Wed, 13 Jun 2001 17:30:50 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF References: <4.3.2.7.2.20010613090910.04d63f00@mail.via-net.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit >PPPEXT will not meet at the London IETF meeting. >I look forward to seeing you all this winter at >Salt Lake City. Well, I was kind of expecting to discuss the new EAP scheme, 3G AKA in London ... but perhaps we can progress such work on the mailing list? Is it necessary to meet to get something progress towards an RFC status or to get WG work item status for something? Any comments by the way from anybody on the below e-mail and draft? Jari --------e-mail from June 4th----------- Hello, I'd like to announce that Henry Haverinen and myself have produced an Internet-Draft that specifies how to run the 3G authentication scheme "AKA" within EAP: http://search.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-00.txt The abstract states "This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the UMTS AKA authentication mechanism. AKA is based on symmetric keys, and runs in a UMTS Subscriber Identity Module, a smart card like device. AKA provides also backward compatibility to GSM authentication, making it possible to use EAP AKA for authenticating both GSM and UMTS subscribers." Comments on this draft would be wellcome. We'd also like to hold a presentation on this draft in the London IETF. Finally, we'd like this working group to consider this draft for a Standards Track status, for the following reasons: - The draft is able to handle both GSM and UTMS authentication. - The large number of existing and future GSM/UMTS clients (500-1000M) makes many applications likely. - Possibilities for GSM-UMTS-WLAN-HIPERLAN interworking scenarios would benefit from an authentication scheme for which substantial deployment and billing infra- structure already exists. - First 3GPP indications point to an interest to use this scheme as a part of their infrastructure. (- The 3GPP2 has also adopted AKA though I can't say exactly in which manner they intend to use it, and whether the EAP AKA scheme would be useful to them.) Jari From owner-ietf-ppp@merit.edu Wed Jun 13 10:58:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24505 for ; Wed, 13 Jun 2001 10:58:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B09DD912EB; Wed, 13 Jun 2001 10:58:33 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73DC691309; Wed, 13 Jun 2001 10:58:33 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59D8F912EB for ; Wed, 13 Jun 2001 10:58:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 736905DDB1; Wed, 13 Jun 2001 10:59:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E37575DD9B for ; Wed, 13 Jun 2001 10:59:08 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16832; Wed, 13 Jun 2001 07:58:38 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15435; Wed, 13 Jun 2001 10:58:34 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5DExM822523; Wed, 13 Jun 2001 10:59:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15143.32714.258349.4528@gargle.gargle.HOWL> Date: Wed, 13 Jun 2001 10:59:22 -0400 (EDT) From: James Carlson To: Jari Arkko Cc: Karl Fox , ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF In-Reply-To: Jari Arkko's message of 13 June 2001 17:30:50 References: <4.3.2.7.2.20010613090910.04d63f00@mail.via-net.net> <3B27791A.E25F24C7@lmf.ericsson.se> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jari Arkko writes: > Well, I was kind of expecting to discuss the new > EAP scheme, 3G AKA in London ... but perhaps we can > progress such work on the mailing list? Is it necessary > to meet to get something progress towards an RFC > status or to get WG work item status for something? No. That's never necessary. The only "official" IETF discussion is done on the mailing list because not all participants are able to travel to the IETF meeting sites. The meetings are helpful if there are unresolved issues in the drafts that need to be haggled out face-to-face, but they're not definitive. RFC 2418: 3.2. Session venue Each working group will determine the balance of email and face-to- face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list. > Any comments by the way from anybody on the below e-mail > and draft? The operation of USIM-Authentication-Reject and USIM-GSM-Authentication-Reject versus EAP Nak isn't clear to me. What do you expect the authenticator to do with these messages? What does the authenticatee do if it doesn't support this EAP extension at all? I think the answer to the first question is that if the authenticator receives either reject message, it performs the same function as if the authenticatee had either sent Response message that didn't validate correctly or had simply shut down the link. If this is so, then I don't see what the extra subtype does. For the second question, I'd think that the authenticatee would send EAP Nak. How is that distinct from USIM-GSM-Authentication-Reject? -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jun 14 03:10:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22904 for ; Thu, 14 Jun 2001 03:10:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8846091226; Thu, 14 Jun 2001 03:10:57 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5833C912FD; Thu, 14 Jun 2001 03:10:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 338D491226 for ; Thu, 14 Jun 2001 03:10:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3BD95DDFC; Thu, 14 Jun 2001 03:11:34 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E13305DDB0 for ; Thu, 14 Jun 2001 03:11:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA02830; Thu, 14 Jun 2001 00:05:14 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 14 Jun 2001 00:05:13 -0700 (PDT) From: Bernard Aboba To: James Carlson Cc: Jari Arkko , Karl Fox , ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF In-Reply-To: <15143.32714.258349.4528@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > Any comments by the way from anybody on the below e-mail > > and draft? > > The operation of USIM-Authentication-Reject and > USIM-GSM-Authentication-Reject versus EAP Nak isn't clear to me. What > do you expect the authenticator to do with these messages? What does > the authenticatee do if it doesn't support this EAP extension at all? EAK Nak is sent to indicate that the peer does not support the required authentication type. However, it isn't a general purpose error mechanism, so it can't be used to say much more than that. In this particular usage, distinct Reject message types are used, presumably to provide more detail on the reasons why the peer cannot comply. I'm not sure that they provide more information than a Nak does in this particular instance, though. Given that the authenticator knows what it was trying to do, and knows that the peer couldn't do it (a Nak tells you that), what more information do these sub-types provide? I'd also note that we are seeing within multiple EAP methods the need to communicate error conditions of various sorts. EAP itself does not provide a way to do this; there is no Alert code. This is lame, but probably not fixable at this point. However, I do think it would be useful to develop an Alert sub-type message, with an embedded error code, whose general format could be reused in multiple methods, rather than utilizing different sub-types for each error condition. From owner-ietf-ppp@merit.edu Thu Jun 14 07:08:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24697 for ; Thu, 14 Jun 2001 07:08:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9BC39131B; Thu, 14 Jun 2001 07:08:07 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72F7B9131E; Thu, 14 Jun 2001 07:08:07 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 571169131B for ; Thu, 14 Jun 2001 07:08:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D50BF5DDB0; Thu, 14 Jun 2001 07:08:44 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 65CE95DD92 for ; Thu, 14 Jun 2001 07:08:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24606; Thu, 14 Jun 2001 07:07:44 -0400 (EDT) Message-Id: <200106141107.HAA24606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-andersson-eap-tls-sasl-00.txt Date: Thu, 14 Jun 2001 07:07:44 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Mechanism using TLS and SASL (Version 1) Author(s) : H. Andersson, S. Josefsson Filename : draft-andersson-eap-tls-sasl-00.txt Pages : 11 Date : 13-Jun-01 This document specifies an Extensible Authentication Protocol (EAP) mechanism for mutual authentication and session key generation in a roaming environment. The server authentication and the negotiation of the session key is done using the PPP EAP Transport Layer Security Authentication Protocol. The user authenticates using a SASL mechanism, the SASL authentication being protected by TLS. An important application discussed in this document is to provide a strong form of authentication of access points and stations within an IEEE 802.11 Wireless Local Area Network (WLAN), but other applications such as LAN access over Bluetooth might also be considered in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-andersson-eap-tls-sasl-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-andersson-eap-tls-sasl-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-andersson-eap-tls-sasl-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613125856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-andersson-eap-tls-sasl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-andersson-eap-tls-sasl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613125856.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Jun 14 07:08:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24840 for ; Thu, 14 Jun 2001 07:08:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AEE89131E; Thu, 14 Jun 2001 07:08:49 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3219F9131F; Thu, 14 Jun 2001 07:08:49 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A38B9131E for ; Thu, 14 Jun 2001 07:08:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC6A15DDB0; Thu, 14 Jun 2001 07:09:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 5796B5DD92 for ; Thu, 14 Jun 2001 07:09:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24745; Thu, 14 Jun 2001 07:08:26 -0400 (EDT) Message-Id: <200106141108.HAA24745@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-pppmux-03.txt Date: Thu, 14 Jun 2001 07:08:26 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Multiplexed Author(s) : R. Pazhyannur, I. Ali, G. Fox Filename : draft-ietf-pppext-pppmux-03.txt Pages : 8 Date : 13-Jun-01 This draft describes a method to reduce the PPP framing overhead used to transport small packets over slow links. The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppmux-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-pppmux-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pppmux-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613130031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pppmux-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pppmux-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613130031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Jun 14 07:19:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25029 for ; Thu, 14 Jun 2001 07:19:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAB5F9131F; Thu, 14 Jun 2001 07:19:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8997291320; Thu, 14 Jun 2001 07:19:21 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 370269131F for ; Thu, 14 Jun 2001 07:19:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E683B5DDB0; Thu, 14 Jun 2001 07:19:58 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 692BC5DD92 for ; Thu, 14 Jun 2001 07:19:58 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05342; Thu, 14 Jun 2001 04:19:22 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26960; Thu, 14 Jun 2001 07:19:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5EBK8Z24041; Thu, 14 Jun 2001 07:20:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15144.40424.150482.926182@gargle.gargle.HOWL> Date: Thu, 14 Jun 2001 07:20:08 -0400 (EDT) From: James Carlson To: Bernard Aboba Cc: Jari Arkko , Karl Fox , ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF In-Reply-To: Bernard Aboba's message of 14 June 2001 00:05:13 References: <15143.32714.258349.4528@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bernard Aboba writes: > EAK Nak is sent to indicate that the peer does not support the required > authentication type. However, it isn't a general purpose error mechanism, > so it can't be used to say much more than that. In this particular usage, > distinct Reject message types are used, presumably to provide more detail > on the reasons why the peer cannot comply. I'm not sure that they provide > more information than a Nak does in this particular instance, > though. Given that the authenticator knows what it was trying to do, and > knows that the peer couldn't do it (a Nak tells you that), what more > information do these sub-types provide? That's exactly the point. If you can't authenticate through the (presumably) pre-arranged method, then you may as well give up and try some other method. Something is quite broken. > I'd also note that we are seeing within multiple EAP methods the need to > communicate error conditions of various sorts. EAP itself does not > provide a way to do this; there is no Alert code. This is lame, > but probably not fixable at this point. However, I do think it > would be useful to develop an Alert sub-type message, with an embedded > error code, whose general format could be reused in multiple > methods, rather than utilizing different sub-types for each error > condition. Besides logging it to some diagnostic record in an implementation- dependent manner, I'm not sure what the semantics of this EAP Alert would be. For existing PPP and EAP, I'd bury the disconnect reason in the LCP Terminate-Request message instead. (In fact, that's what I do in my implementation.) I'd prefer that we just obsolete 2284 and write a new draft that says that Nak and Failure can carry diagnostic text. That fixes the problem at hand -- it allows both authenticator and authenticatee to give some indication about what went wrong, should they choose to do so. Are there any implementations out there that *don't* accept Nak or Failure messages with additional appended data? Does anyone do a strict comparison on the length and drop the message on the floor? It seems to me that doing so would be an extremely poor design decision (failing to be liberal in what's expected). The interoperability of an Alert with existing EAP, on the other hand, might be troublesome. 2284 doesn't give any hints about what to do with unknown message codes. There's no equivalent of "Code-Reject." Unlike appending a text message, the result could be anything ... (There are other flaws that could be fixed with a new draft. For example, what EAP Nak message do you send if you have *no* more acceptable types left to suggest?) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jun 14 08:45:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26845 for ; Thu, 14 Jun 2001 08:45:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FD1C91324; Thu, 14 Jun 2001 08:45:07 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF91B91325; Thu, 14 Jun 2001 08:45:06 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8932791324 for ; Thu, 14 Jun 2001 08:45:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 567025DD8C; Thu, 14 Jun 2001 08:45:43 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 49F165DDA7 for ; Thu, 14 Jun 2001 08:45:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26812; Thu, 14 Jun 2001 08:44:41 -0400 (EDT) Message-Id: <200106141244.IAA26812@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-pppmux-03.txt Date: Thu, 14 Jun 2001 08:44:40 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Multiplexed Author(s) : R. Pazhyannur, I. Ali, C. Fox Filename : draft-ietf-pppext-pppmux-03.txt Pages : 8 Date : 13-Jun-01 This draft describes a method to reduce the PPP framing overhead used to transport small packets over slow links. The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppmux-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-pppmux-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pppmux-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613130031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pppmux-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pppmux-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613130031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Jun 14 11:50:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02735 for ; Thu, 14 Jun 2001 11:50:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B9659132B; Thu, 14 Jun 2001 11:50:46 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2D659132D; Thu, 14 Jun 2001 11:50:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2DF39132B for ; Thu, 14 Jun 2001 11:50:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5A815DDB0; Thu, 14 Jun 2001 11:51:23 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EF0BD5DDA7 for ; Thu, 14 Jun 2001 11:51:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA03608; Thu, 14 Jun 2001 08:45:02 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 14 Jun 2001 08:45:02 -0700 (PDT) From: Bernard Aboba To: James Carlson Cc: Jari Arkko , Karl Fox , ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF In-Reply-To: <15144.40424.150482.926182@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I'd prefer that we just obsolete 2284 and write a new draft that says > that Nak and Failure can carry diagnostic text. That fixes the > problem at hand -- it allows both authenticator and authenticatee to > give some indication about what went wrong, should they choose to do > so. Notification might also be used. > Are there any implementations out there that *don't* accept Nak > or Failure messages with additional appended data? Yes. Because Failure messages are not ACK'd you can't assume that the peer will receive the message at all, let alone the appended data. So with RFC 2284 as it currently stands, adding data to a Success or Failure message is probably a bad idea. Naks already can carry a data field, and are ACK'd, so this concern would not apply here. > The interoperability of an Alert with existing EAP, on the other hand, > might be troublesome. 2284 doesn't give any hints about what to do > with unknown message codes. Another "issue" to add to the list in a revision discussion. > (There are other flaws that could be fixed with a new draft. For > example, what EAP Nak message do you send if you have *no* more > acceptable types left to suggest?) I'm creating a list of outstanding issues for an EAP revision. I'll add this one to the list. If you have others, please post them. From owner-ietf-ppp@merit.edu Thu Jun 14 12:25:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03491 for ; Thu, 14 Jun 2001 12:25:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DA0691331; Thu, 14 Jun 2001 12:25:53 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CE3591332; Thu, 14 Jun 2001 12:25:53 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CB3991331 for ; Thu, 14 Jun 2001 12:25:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2FEB15DDA7; Thu, 14 Jun 2001 12:26:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A9F7F5DD8C for ; Thu, 14 Jun 2001 12:26:30 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03263; Thu, 14 Jun 2001 10:25:54 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22697; Thu, 14 Jun 2001 12:25:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5EGQfK24601; Thu, 14 Jun 2001 12:26:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15144.58817.221447.441636@gargle.gargle.HOWL> Date: Thu, 14 Jun 2001 12:26:41 -0400 (EDT) From: James Carlson To: Bernard Aboba Cc: Jari Arkko , Karl Fox , ietf-ppp@merit.edu Subject: Re: No PPPEXT meeting at London IETF In-Reply-To: Bernard Aboba's message of 14 June 2001 08:45:02 References: <15144.40424.150482.926182@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bernard Aboba writes: > > I'd prefer that we just obsolete 2284 and write a new draft that says > > that Nak and Failure can carry diagnostic text. That fixes the > > problem at hand -- it allows both authenticator and authenticatee to > > give some indication about what went wrong, should they choose to do > > so. > > Notification might also be used. That only really works from the authenticator side. The authenticatee can't use Notification. If it did, that message would apply only if there were mutual authentication, and then only to the separate authentication conversation in the other direction. > > Are there any implementations out there that *don't* accept Nak > > or Failure messages with additional appended data? > > Yes. If so, I think that's a sad state of affairs. Postel's note in RFC 791 is really quite old now. > Because Failure messages are not ACK'd you can't assume that the peer > will receive the message at all, let alone the appended data. So with RFC > 2284 as it currently stands, adding data to a Success or Failure message > is probably a bad idea. True, of course, they're not acknowledged. However, we're not talking about something that necessarily *requires* acknowledgment. We're talking about some diagnostic information that would be nice to deliver to the peer, but won't cause any undue harm if it isn't. Of course, any decent implementation would take pains to make sure that the chance that this message is lost is fairly low. > Naks already can carry a data field, and are ACK'd, so this concern would > not apply here. No. Naks are Response only. There is no acknowledgment of a Nak. The subsequent Request message (if any) doesn't acknowledge it. As written, there are acknowledgments from authenticatee to authenticator only. There are none in the reverse direction. > > (There are other flaws that could be fixed with a new draft. For > > example, what EAP Nak message do you send if you have *no* more > > acceptable types left to suggest?) > > I'm creating a list of outstanding issues for an EAP revision. I'll add > this one to the list. If you have others, please post them. Some text about what the authenticator ought to do when the Nak hint isn't acceptable might be good. (Of course, this might just say that the behavior is "implementation defined.") -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jun 14 16:48:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09586 for ; Thu, 14 Jun 2001 16:48:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A63579122C; Thu, 14 Jun 2001 16:48:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 742359122D; Thu, 14 Jun 2001 16:48:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F3389122C for ; Thu, 14 Jun 2001 16:48:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D8C45DDD3; Thu, 14 Jun 2001 16:48:51 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id CF4665DDCF for ; Thu, 14 Jun 2001 16:48:50 -0400 (EDT) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f5EKW0326116; Thu, 14 Jun 2001 13:32:01 -0700 From: "Bernard Aboba" To: Cc: "Bernard Aboba" Subject: EAP Implementation survey Date: Thu, 14 Jun 2001 13:48:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit EAP Implementation Survey ------------------------- Please fill this out and return it to aboba@internaut.com by July 21, 2001. For EAP (RFC 2284) to advance to Draft Standard, every feature must have at least two independent implementations, or must be cut from the draft. I'm putting together the RFC 2284bis document. Please read these directions carefully and email your answers to me directly, not to the list. I only need a reply to this if your implementation is INDEPENDENT, that is, not based on another implementation. If you started out once upon a time with another code base and eventually replaced all the code with fresh code, that counts as independent. If you did your implementation from scratch, better yet. Please provide contact information and fill out the Company, Product and Version fields following their colons, and mark the features with a Y or N *before* the feature, and keep the spelling and order exactly as they are here (so I can automate processing the results). Lines starting with __ are headers and should not be marked. Y means you support that feature in your EAP implementation NOW, N means you do not. No fair saying you'll be adding it later, it has to be in your implementation that's already done and being used somewhere, although beta or experimental software counts as in use, as long as its actually running. If you make both an EAP client and access device, please send in two submissions (as two separate email messages), one for each. If you make different flavors of access device (say, a switch, access point and NAS), but they have the same EAP implementation, you only need to send me an entry for one flavor. Similarly, if you ship multiple client implementations, but they are using the same code base, just send me one entry. Contact name: Contact email address: Contact phone number: Company name: Product Name: Product Version: Client or Access Device (only one per entry): Media Type(s) Supported (PPP, IEEE 802, Bluetooth, Other): If Other, please describe: __ Configuration Option LCP Configuration option (C227) supported __ Message Codes supported: Request Response Success Failure __ EAP Types supported: Identity Notification Nak (Response only) MD5-Challenge One-Time Password (OTP) (RFC 1938) Generic Token Card __ Length field check Octets outside the range of the Length field ignored on reception __ Request and Response messages One Type specified per EAP Request or Response Type field of the Response same as the Type of the Request (except Nak) Authenticator transmits Request Peer sends a Response packet in reply to a Request Responses not retransmitted on a timer Identifier field of Response matches that of the Request Retransmitted Request sent with same Identifier value New (non-retransmission) Requests modify the Identifier field Additional Requests sent until a valid Response is received, or retry counter expires Retransmission timer of 6 seconds with a maximum of 10 retransmissions used as default Peer silently discards received retransmissions while waiting for user input __ Success and Failure messages Success packet is sent by the authenticator to the peer Success packet is not sent by peer to authenticator Success packet acknowledges successful authentication Success packet sent with Code field set to 3 Failure packet is sent by the authenticator to the peer Failure packet is not sent by peer to authenticator Failure packet acknowledges unsuccessful authentication Failure packet sent with Code field set to 4 Authenticator issues multiple Requests before sending a Failure Peer allows for loss of Success and Failure packets Peer uses Network protocol packet as alternative indication of Success Peer uses receipt of LCP Terminate-Request as alternative indication of Failure __Identity type Identity Request can contain a displayable message Identity field is not null terminates Length of identity field derived from Length field Identity can be bypassed If Identity is unknown, Identity Response is zero bytes in length Authenticator retries Identity Request Identity Request retried a minimum of 3 times before termination Failure indicated within new Identity Request __ Notification type Peer displays Notification to the user Peer logs Notification if it cannot be displayed Notification request used to indicate invalid authentication attempt Notification is not null terminated Length of notification field derived from Length field Response sent in reply to Notification Request The Type-Data field of Notification Response is zero octets in length Notification Response sent immediately (independent of display or logging) __ Nak type Nak Type sent in Response Nak Type NOT sent in a Request Nak Type-data field contains single octet indicating desired auth type __ MD5-Challenge type MD5-Challenge Response can be sent in reply to MD5-Challenge Request Nak message can be sent in reply to MD5-Challenge Request __ OTP type Request contains OTP challenge Request is not null terminated Length of Request derived from Length field Type 5 (OTP) Response can be sent in reply to the Request Type 3 (Nak) Response can be sent in reply to the Request __ Generic Token Card type Request contains displayable message greater than zero octets in length Length of message determined by length field Request is not null terminated Type 6 (GTC) response can be sent in reply to GTC Request Type 3 (Nak) response can be sent in reply to GTC Request __ Security considerations Upon authentication failure, link is terminated Upon authentication failure, traffic limited to filtered subset Counters used for authentication failure not reset until after successful authentication, link termination For each named user support for exactly one authentication method From owner-ietf-ppp@merit.edu Fri Jun 15 09:09:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06359 for ; Fri, 15 Jun 2001 09:09:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1940791247; Fri, 15 Jun 2001 09:09:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D711191248; Fri, 15 Jun 2001 09:09:30 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC79B91247 for ; Fri, 15 Jun 2001 09:09:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60FE65DDCC; Fri, 15 Jun 2001 09:10:10 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 1EB725DDC8 for ; Fri, 15 Jun 2001 09:10:09 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5FD9rm02936 for ; Fri, 15 Jun 2001 16:09:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Jun 2001 16:09:38 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 15 Jun 2001 16:09:38 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E626F4@treis03nok> From: henry.haverinen@nokia.com To: aboba@internaut.com, james.d.carlson@east.sun.com Cc: Jari.Arkko@lmf.ericsson.se, karl@xc.org, ietf-ppp@merit.edu Subject: RE: No PPPEXT meeting at London IETF Date: Fri, 15 Jun 2001 16:09:32 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > The operation of USIM-Authentication-Reject and > > USIM-GSM-Authentication-Reject versus EAP Nak isn't clear > to me. What > > do you expect the authenticator to do with these messages? > What does > > the authenticatee do if it doesn't support this EAP > extension at all? > > EAK Nak is sent to indicate that the peer does not support > the required > authentication type. However, it isn't a general purpose > error mechanism, > so it can't be used to say much more than that. In this > particular usage, > distinct Reject message types are used, presumably to provide > more detail > on the reasons why the peer cannot comply. I'm not sure that > they provide > more information than a Nak does in this particular instance, > though. Given that the authenticator knows what it was trying > to do, and > knows that the peer couldn't do it (a Nak tells you that), what more > information do these sub-types provide? Nak would tell the authenticator that the peer doesn't support the EAP/AKA authentication type. GSM-Authentication- Reject would tell the authenticator that the peer supports the EAP/AKA authentication type, but it does not accept the GSM backward compatibility version of EAP/AKA. So the peer would like to use EAP/AKA with UMTS authentication (but the authenticator isn't likely to be able to do that because it tried GSM authentication in the first place). This is not a big issue for us -- the information won't probably be very useful for the authenticator anyway -- and we are happy to revise the draft to use Nak or some new RFC2284bis mechanism instead, if you feel that would be a better way to do it. Regards, Henry From owner-ietf-ppp@merit.edu Wed Jun 20 10:09:02 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08175 for ; Wed, 20 Jun 2001 10:09:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70EA691235; Wed, 20 Jun 2001 10:09:08 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B0E291236; Wed, 20 Jun 2001 10:09:08 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3899291235 for ; Wed, 20 Jun 2001 10:09:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77F055DDAC; Wed, 20 Jun 2001 10:09:57 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id AAA495DDC8 for ; Wed, 20 Jun 2001 10:09:56 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5KEBdG13412 for ; Wed, 20 Jun 2001 17:11:39 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 20 Jun 2001 17:09:19 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 20 Jun 2001 17:09:19 +0300 Message-ID: From: henry.haverinen@nokia.com To: ietf-ppp@merit.edu Subject: EAP-SRP and identity privacy Date: Wed, 20 Jun 2001 17:09:13 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi all, Here is a proposal how to include identity privacy support in the EAP-SRP draft. We could add a new (optional?) field called "next pseudonym" in the EAP-Request/SRP-SHA1/Server Validator message. A "pseudonym" would be recoverable from this field using the session key K, so it would be available to the authenticatee only. Eavesdroppers are not able to recover the pseudonym. In the next EAP authentication, the authenticatee can use the pseudonym obtained during the previous authentication as the client name C, hence making consecutive authentications unlinkable to everyone else but the authenticator. The cleartext client name needs to be send only if a pseudonym is not available (in the very first authentication). Note that the authenticator would not need to maintain state in order to generate pseudonyms. Pseudonyms could be obtained by encrypting the client name with random salt, using a key that is known to the authenticator only. Regards, Henry From owner-ietf-ppp@merit.edu Wed Jun 20 10:22:05 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08658 for ; Wed, 20 Jun 2001 10:22:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E73F91236; Wed, 20 Jun 2001 10:21:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E28D791237; Wed, 20 Jun 2001 10:21:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBE2991236 for ; Wed, 20 Jun 2001 10:21:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10DA25DE02; Wed, 20 Jun 2001 10:22:47 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id B82A75DE01 for ; Wed, 20 Jun 2001 10:22:46 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jun 2001 14:22:09 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010620161155.00c2b570@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 16:21:56 +0200 To: henry.haverinen@nokia.com From: Jacques Caron Subject: Re: EAP-SRP and identity privacy Cc: ietf-ppp@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, This raises the issue of the real privacy of sessions keys. As I pointed out to James earlier, it is quite necessary to make sure that the authenticatee knows whether the derived keys are kept by the authenticator and authenticatee only, or if the authenticator will then send them to the link-layer endpoint (NAS, Access point...) for link encryption purposes (PPP ECP, WEP...). Or, even better, two sets of keys should actually be derived, one for each application. One set would be kept on the EAP endpoints only, while the other could be sent (via Radius, Diameter or any other protocol) to the NAS/AP. Otherwise the authenticatee might be tricked into sending information using a derived key, which it thinks only the authenticator knows, while the NAS/AP actually also knows it. More specifically to your proposal: - I don't understand why it would be the authenticator which would generate the pseudonym? I would rather think it should be the authenticatee that would send an encrypted version of its "real" username? - what identity should be used in the first request, that would not reveal the identity of the user? Some share identity (and password)? I mucht have miched chomeching here... Jacques. At 16:09 20/06/01, henry.haverinen@nokia.com wrote: >Hi all, > >Here is a proposal how to include identity privacy >support in the EAP-SRP draft. > >We could add a new (optional?) field called "next pseudonym" >in the EAP-Request/SRP-SHA1/Server Validator message. A "pseudonym" >would be recoverable from this field using the session key K, so >it would be available to the authenticatee only. Eavesdroppers are >not able to recover the pseudonym. > >In the next EAP authentication, the authenticatee can use the >pseudonym obtained during the previous authentication as the client >name C, hence making consecutive authentications unlinkable to everyone >else but the authenticator. The cleartext client name needs to be >send only if a pseudonym is not available (in the very first >authentication). > >Note that the authenticator would not need to maintain state in >order to generate pseudonyms. Pseudonyms could be >obtained by encrypting the client name with random salt, >using a key that is known to the authenticator only. > >Regards, >Henry _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Wed Jun 20 11:05:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10117 for ; Wed, 20 Jun 2001 11:05:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95CD491237; Wed, 20 Jun 2001 11:05:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FABC91238; Wed, 20 Jun 2001 11:05:31 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D3E891237 for ; Wed, 20 Jun 2001 11:05:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A242A5DDFC; Wed, 20 Jun 2001 11:06:20 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B14145DDAC for ; Wed, 20 Jun 2001 11:06:19 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5KF5v309074 for ; Wed, 20 Jun 2001 18:05:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 18:05:42 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 20 Jun 2001 18:05:42 +0300 Message-ID: From: henry.haverinen@nokia.com To: jacques_m_caron@yahoo.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy Date: Wed, 20 Jun 2001 18:05:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Jacques, > Or, even better, two sets of keys should actually be derived, > one for each > application. One set would be kept on the EAP endpoints only, > while the > other could be sent (via Radius, Diameter or any other > protocol) to the NAS/AP. That's true. The key that is used to send data securely from the authenticator to the authenticatee should be separate from the keys that are sent to the NAS/AP so that the pseudonyms won't become linkable to the NAS/AP. We could use a pseudo random function to derive session keys for each application from the "master" session key. > More specifically to your proposal: > - I don't understand why it would be the authenticator which > would generate > the pseudonym? I would rather think it should be the > authenticatee that > would send an encrypted version of its "real" username? The problem is what key the authenticatee should use to encrypt the username. There is a chicken-egg problem: you can't have a key to protect the user-name until you've provided the user-name so as to enable the key exchange. So we need to use a pseudonym obtained in a previous authentication. The pseudonym _can_ be an encrypted version of the real username, but it needs to be encrypted by the authenticator, with an internal (private) key it uses for all clients. Then the authenticator can recover the real username by decrypting the pseudonym. > - what identity should be used in the first request, that > would not reveal > the identity of the user? Some share identity (and password)? It is hard not to reveal the identity, so I think the real cleartext client name can be used. We need to transmitit the very first time the user uses the terminal. After that the authentication software on the terminal should have a cached pseudonym available for the user. Regards, Henry From owner-ietf-ppp@merit.edu Wed Jun 20 11:16:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10490 for ; Wed, 20 Jun 2001 11:16:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D96491238; Wed, 20 Jun 2001 11:16:17 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC19091239; Wed, 20 Jun 2001 11:16:16 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC09491238 for ; Wed, 20 Jun 2001 11:16:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24F275DDFF; Wed, 20 Jun 2001 11:17:05 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 899BC5DDFC for ; Wed, 20 Jun 2001 11:17:04 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11682; Wed, 20 Jun 2001 08:16:21 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16614; Wed, 20 Jun 2001 11:16:19 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KFH7N18351; Wed, 20 Jun 2001 11:17:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.48754.838780.118484@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:17:06 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: Re: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 20 June 2001 17:09:13 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > We could add a new (optional?) field called "next pseudonym" > in the EAP-Request/SRP-SHA1/Server Validator message. A "pseudonym" > would be recoverable from this field using the session key K, so > it would be available to the authenticatee only. Eavesdroppers are > not able to recover the pseudonym. That's an interesting idea. Of course, you'd need to be able to handle the error-recovery cases (where authenticator or authenticatee either "forgets" the current pseudonym entirely or, due to a restoration from back-up, reverts to a prior pseudonym) to make it robust, but it sounds like it should work. Here's what I'll propose: add an optional Next Pseudonym field to the Server Validator (Subtype 3) message. If this is present, then the authenticatee MAY save this value and MAY use it in response to the EAP Identity Request message in a subsequent session. Regardless of the use of a Next Pseudonym value in any prior session, the authenticator MUST always accept the authenticatee's regular name for validation. The Next Pseudonym value SHOULD contain an implementation-dependent identifying mark (the string "Pseudo" is suggested) so that the authenticator can requery for EAP Identity if the Pseudonym presented by the authenticatee is unknown due to synchronization problems. If the authenticator sends an EAP Identity Request message with a changed ID field, the authenticatee MUST revert to its regular identity in subsequent Responses and the authenticator MUST NOT allow the use of a Pseudonym for identification within that same authentication session. Authenticatees that do not have stable storage for the Next Pseudonym value or otherwise do not elect to implement this feature may ignore this field entirely and use the same client identifier with all sessions. How does that look? > Note that the authenticator would not need to maintain state in > order to generate pseudonyms. Pseudonyms could be > obtained by encrypting the client name with random salt, > using a key that is known to the authenticator only. The authenticator *would* have to maintain state across calls in order to use the pseudonym; you must at least to keep track of that random salt. Otherwise, you either always have the same pseudonym or you can't recognize the client by his pseudonym when he comes back. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 11:17:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10568 for ; Wed, 20 Jun 2001 11:17:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBD9591239; Wed, 20 Jun 2001 11:17:57 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 906479123A; Wed, 20 Jun 2001 11:17:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8604591239 for ; Wed, 20 Jun 2001 11:17:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F21D55DDFF; Wed, 20 Jun 2001 11:18:46 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7478E5DDAC for ; Wed, 20 Jun 2001 11:18:46 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18625; Wed, 20 Jun 2001 09:18:08 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16936; Wed, 20 Jun 2001 11:18:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KFIuR18359; Wed, 20 Jun 2001 11:18:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.48864.625635.654336@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:18:56 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: EAP-SRP and identity privacy In-Reply-To: James Carlson's message of 20 June 2001 11:17:06 References: <15152.48754.838780.118484@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson writes: > Here's what I'll propose: add an optional Next Pseudonym field to the > Server Validator (Subtype 3) message. If this is present, then the > authenticatee MAY save this value and MAY use it in response to the > EAP Identity Request message in a subsequent session. Regardless of > the use of a Next Pseudonym value in any prior session, the > authenticator MUST always accept the authenticatee's regular name for > validation. I managed to leave off an important aspect: the Next Pseudoynm needs to be the result *after* encryption using the shared key, naturally. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 11:27:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11035 for ; Wed, 20 Jun 2001 11:27:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B3689123F; Wed, 20 Jun 2001 11:27:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B2CF91240; Wed, 20 Jun 2001 11:27:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEABE9123F for ; Wed, 20 Jun 2001 11:27:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59DE55DDFC; Wed, 20 Jun 2001 11:28:13 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C03E85DDAC for ; Wed, 20 Jun 2001 11:28:12 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16611; Wed, 20 Jun 2001 08:27:29 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17405; Wed, 20 Jun 2001 11:27:22 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KFSAK18368; Wed, 20 Jun 2001 11:28:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.49418.622113.647531@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:28:10 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: jacques_m_caron@yahoo.com, ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 20 June 2001 18:05:36 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > That's true. The key that is used to send data securely > from the authenticator to the authenticatee should be > separate from the keys that are sent to the NAS/AP > so that the pseudonyms won't become linkable to the NAS/AP. > We could use a pseudo random function to derive > session keys for each application from the "master" > session key. The problem with separating the authenticator function from the NAS itself is that I don't see a good way for the NAS to get *any* sort of key out of the exchange. That problem is why I punted on the whole issue. > The problem is what key the authenticatee should use to > encrypt the username. There is a chicken-egg problem: > you can't have a key to protect the user-name until you've provided > the user-name so as to enable the key exchange. > So we need to use a pseudonym obtained in a previous > authentication. More than that, it has to be picked by the authenticator side so that there's no possibility of collisions with other clients. If the authenticatee picks it, and it somehow duplicates the name that someone else uses (imagine a bad implementation that just gives the pseudonym as the constant string "foo"), then the authenticator is in trouble. > It is hard not to reveal the identity, so I think the real cleartext > client name can be used. We need to transmitit the very > first time the user uses the terminal. After that the > authentication software on the terminal should have a cached > pseudonym available for the user. An implementation option would be to have an "always use pseudonym, if available" flag. The semantics would be that, if set, the client would establish a connection using the real name. If that connection resulted in a pseudonym (i.e., the authenticator supports this feature), then the client would disconnect and reconnect. On this (and subsequent) connections, only the pseudonym would be used, and network data transfer would then be enabled. What we're really talking about here are nonces. So here's an alternative implementation: server generates random value P, and includes this in the Server Validator message. Both client and server calculate SHA1(P | K) and save this value in stable storage. On a subsequent authentication sessions, the client offers SHA1(P | K) as its identity. This avoids having to do any sort of encryption. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 11:38:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11424 for ; Wed, 20 Jun 2001 11:38:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 584AE91241; Wed, 20 Jun 2001 11:39:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2610191242; Wed, 20 Jun 2001 11:39:00 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13CBB91241 for ; Wed, 20 Jun 2001 11:38:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73AF35DDFC; Wed, 20 Jun 2001 11:39:49 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id BD35D5DDAC for ; Wed, 20 Jun 2001 11:39:48 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5KFdQ319299 for ; Wed, 20 Jun 2001 18:39:26 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 20 Jun 2001 18:39:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 20 Jun 2001 18:39:11 +0300 Message-ID: From: henry.haverinen@nokia.com To: james.d.carlson@east.sun.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy Date: Wed, 20 Jun 2001 18:39:06 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi James, I just have time for one quick comment, I'll get back with more comments later. > The authenticator *would* have to maintain state across calls in order > to use the pseudonym; you must at least to keep track of that random > salt. Otherwise, you either always have the same pseudonym or you > can't recognize the client by his pseudonym when he comes back. If the authenticator generates the pseydonym by encrypting the string random number || cleartext_identity with its private key for this purpose (the same key for all users), then different pseudonyms will generated each time, except in the unlikely event that the random number generator gives the same random number. When the authenticator decrypts any pseudonym, it recovers the string random number||cleartext_identity, and hence it is always able to recognize the client. So no need to keep state or even use the pseudonyms in order. Regards, Henry From owner-ietf-ppp@merit.edu Wed Jun 20 11:50:05 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11749 for ; Wed, 20 Jun 2001 11:50:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2040391230; Wed, 20 Jun 2001 11:50:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E661D91242; Wed, 20 Jun 2001 11:49:59 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC1C891230 for ; Wed, 20 Jun 2001 11:49:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 599D95DE02; Wed, 20 Jun 2001 11:50:49 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D53665DDFF for ; Wed, 20 Jun 2001 11:50:48 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21152; Wed, 20 Jun 2001 09:50:01 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21851; Wed, 20 Jun 2001 11:50:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KFoo218408; Wed, 20 Jun 2001 11:50:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.50778.37556.522452@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:50:50 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 20 June 2001 18:39:06 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > I just have time for one quick comment, I'll get back > with more comments later. OK. > > The authenticator *would* have to maintain state across calls in order > > to use the pseudonym; you must at least to keep track of that random > > salt. Otherwise, you either always have the same pseudonym or you > > can't recognize the client by his pseudonym when he comes back. > > If the authenticator generates the pseydonym by encrypting the string > random number || cleartext_identity with its private key for this purpose > (the same key for all users), then different pseudonyms will generated > each time, except in the unlikely event that the random number generator > gives the same random number. When the authenticator decrypts any pseudonym, > it recovers the string random number||cleartext_identity, and hence it > is always able to recognize the client. So no need to keep state or even > use the pseudonyms in order. Ah, I think I see what you're suggesting now. So, you're proposing two levels of encryption on the server side -- one with this private key, then again with the ephemeral key "K". The client decrypts with "K" to reveal the encrypted identity, and uses that as its identity in the next session. That appears to fix an important problem. It allows the protocol to run without having to requery for identity -- the identity is always in the pseudonym, and it's always valid. The tradeoff would be that some form of reversible encryption is required, and that makes it tougher (in that respect) to deploy. Hmm. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 11:51:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11776 for ; Wed, 20 Jun 2001 11:51:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B82091242; Wed, 20 Jun 2001 11:51:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0736E91243; Wed, 20 Jun 2001 11:51:19 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF33F91242 for ; Wed, 20 Jun 2001 11:51:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 709D35DE02; Wed, 20 Jun 2001 11:52:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EDCB45DDFF for ; Wed, 20 Jun 2001 11:52:08 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22847; Wed, 20 Jun 2001 09:51:28 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23728; Wed, 20 Jun 2001 11:51:29 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KFqH618413; Wed, 20 Jun 2001 11:52:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.50865.313894.710686@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 11:52:17 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 20 June 2001 18:39:06 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit (Resend; last message omitted the mailing list cc. Sigh ...) henry.haverinen@nokia.com writes: > I just have time for one quick comment, I'll get back > with more comments later. OK. > > The authenticator *would* have to maintain state across calls in order > > to use the pseudonym; you must at least to keep track of that random > > salt. Otherwise, you either always have the same pseudonym or you > > can't recognize the client by his pseudonym when he comes back. > > If the authenticator generates the pseydonym by encrypting the string > random number || cleartext_identity with its private key for this purpose > (the same key for all users), then different pseudonyms will generated > each time, except in the unlikely event that the random number generator > gives the same random number. When the authenticator decrypts any pseudonym, > it recovers the string random number||cleartext_identity, and hence it > is always able to recognize the client. So no need to keep state or even > use the pseudonyms in order. Ah, I think I see what you're suggesting now. So, you're proposing two levels of encryption on the server side -- one with this private key, then again with the ephemeral key "K". The client decrypts with "K" to reveal the encrypted identity, and uses that as its identity in the next session. That appears to fix an important problem. It allows the protocol to run without having to requery for identity -- the identity is always in the pseudonym, and it's always valid. The tradeoff would be that some form of reversible encryption is required, and that makes it tougher (in that respect) to deploy. Hmm. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 11:54:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11870 for ; Wed, 20 Jun 2001 11:54:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB46891243; Wed, 20 Jun 2001 11:54:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D0F591244; Wed, 20 Jun 2001 11:54:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AD5791243 for ; Wed, 20 Jun 2001 11:54:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3ACA5DE02; Wed, 20 Jun 2001 11:55:34 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 6AD1F5DDFF for ; Wed, 20 Jun 2001 11:55:34 -0400 (EDT) Received: from pc25.paris-dc.fr.psi.com (HELO jc.yahoo.com) (212.81.116.25) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jun 2001 15:54:56 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010620173044.00c19910@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 17:54:04 +0200 To: James Carlson From: Jacques Caron Subject: RE: EAP-SRP and identity privacy Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu In-Reply-To: <15152.49418.622113.647531@gargle.gargle.HOWL> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 17:28 20/06/01, James Carlson wrote: >henry.haverinen@nokia.com writes: > > That's true. The key that is used to send data securely > > from the authenticator to the authenticatee should be > > separate from the keys that are sent to the NAS/AP > > so that the pseudonyms won't become linkable to the NAS/AP. > > We could use a pseudo random function to derive > > session keys for each application from the "master" > > session key. > >The problem with separating the authenticator function from the NAS >itself is that I don't see a good way for the NAS to get *any* sort of >key out of the exchange. That's something that is supposed to be dealt with in Diameter (and maybe Radius). Cisco APs using 802.1x/EAP already get the session keys back via Radius, if I'm not mistaken. The idea is simply that the auth server will send (encrypted) session keys to the NAS/AP upon completion of the EAP auth. But to still be able to have private communications between the authenticator and the authenticatee, there should be another set of keys. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Wed Jun 20 15:18:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19095 for ; Wed, 20 Jun 2001 15:18:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1047491248; Wed, 20 Jun 2001 15:18:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D025B91249; Wed, 20 Jun 2001 15:18:42 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1563291248 for ; Wed, 20 Jun 2001 15:18:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C392A5DE01; Wed, 20 Jun 2001 15:19:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1347A5DDED for ; Wed, 20 Jun 2001 15:19:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA09757; Wed, 20 Jun 2001 12:12:48 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 20 Jun 2001 12:12:48 -0700 (PDT) From: Bernard Aboba To: Jacques Caron Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: EAP-SRP and identity privacy In-Reply-To: <4.3.2.7.2.20010620161155.00c2b570@pop.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Otherwise the authenticatee might be tricked into sending information using > a derived key, which it thinks only the authenticator knows, while the > NAS/AP actually also knows it. > The keys are ONLY for use at the link layer, right? They MUST NOT be used for anything else! I'd note that the client doesn't really know who he's talking to -- with L2TP compulsory tunneling, it might be a tunnel server halfway around the world, not the NAS. So all the client really knows is that the other side of the link has obtained the keys it previously negotiated. From owner-ietf-ppp@merit.edu Wed Jun 20 15:23:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19247 for ; Wed, 20 Jun 2001 15:23:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F32B291246; Wed, 20 Jun 2001 15:23:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0F049124A; Wed, 20 Jun 2001 15:23:43 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87D9191246 for ; Wed, 20 Jun 2001 15:23:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46F2C5DE02; Wed, 20 Jun 2001 15:24:33 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8BFA45DE01 for ; Wed, 20 Jun 2001 15:24:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA09764; Wed, 20 Jun 2001 12:17:50 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 20 Jun 2001 12:17:49 -0700 (PDT) From: Bernard Aboba To: James Carlson Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Question on SRP Intellectual Property Statement In-Reply-To: <15152.48864.625635.654336@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I had the following question put to me recently: a. In the IP statement filed with IETF on SRP, it is noted that "bi-directional auth" (SRP-Z) requires a royalty. This version involves having both sides store the verifier. b. In a peer-to-peer protocol like PPP (or 802.11 ad-hoc, for that matter), either side might be the authenticator, and therefore might have to store the verifier. Does this mean that use of SRP in adhoc scenarios is not "freely licensable"? From owner-ietf-ppp@merit.edu Wed Jun 20 15:46:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20036 for ; Wed, 20 Jun 2001 15:46:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3E779124A; Wed, 20 Jun 2001 15:46:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68C089124B; Wed, 20 Jun 2001 15:46:11 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACA369124A for ; Wed, 20 Jun 2001 15:46:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 650525DE02; Wed, 20 Jun 2001 15:47:00 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id CD1C95DDED for ; Wed, 20 Jun 2001 15:46:59 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11666; Wed, 20 Jun 2001 12:46:10 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10785; Wed, 20 Jun 2001 15:46:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KJknw18996; Wed, 20 Jun 2001 15:46:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.64936.433507.538491@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 15:46:48 -0400 (EDT) From: James Carlson To: Bernard Aboba Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu, Tom Wu Subject: Re: Question on SRP Intellectual Property Statement In-Reply-To: Bernard Aboba's message of 20 June 2001 12:17:49 References: <15152.48864.625635.654336@gargle.gargle.HOWL> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bernard Aboba writes: > I had the following question put to me recently: > > a. In the IP statement filed with IETF on SRP, it is noted that > "bi-directional auth" (SRP-Z) requires a royalty. This version involves > having both sides store the verifier. It's my understanding that SRP-Z is a different algorithm, though I haven't been able to find enough information about it to be certain. The implementation described in the EAP SRP-SHA1 draft is based directly on RFC 2495, and that is known to be "free." > b. In a peer-to-peer protocol like PPP (or 802.11 ad-hoc, for that > matter), either side might be the authenticator, and therefore might have > to store the verifier. SRP as described in this draft doesn't work that way. It's more like PAP. If you had (for whatever reason) both sides behaving as authenticators, then you'd have independent verifiers and secrets for each direction. In particular, I don't see how a client with only a copy of the verifier (and no access to the secret) could use it to authenticate to the server. > Does this mean that use of SRP in adhoc scenarios is not "freely > licensable"? The right person to ask is probably Thomas Wu, so I've copied him. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 16:50:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22300 for ; Wed, 20 Jun 2001 16:50:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 522DA9124C; Wed, 20 Jun 2001 16:50:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FF259124E; Wed, 20 Jun 2001 16:50:52 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13C759124C for ; Wed, 20 Jun 2001 16:50:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E72045DDCF; Wed, 20 Jun 2001 16:51:41 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 6EB5C5DDB8 for ; Wed, 20 Jun 2001 16:51:41 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25690; Wed, 20 Jun 2001 14:50:56 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23601; Wed, 20 Jun 2001 16:50:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KKpi619052; Wed, 20 Jun 2001 16:51:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15153.3296.400285.921943@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 16:51:44 -0400 (EDT) From: James Carlson To: Tom Wu Cc: Bernard Aboba , henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: Question on SRP Intellectual Property Statement In-Reply-To: Tom Wu's message of 20 June 2001 13:44:15 References: <15152.48864.625635.654336@gargle.gargle.HOWL> <15152.64936.433507.538491@gargle.gargle.HOWL> <3B310B1F.BC0F59A6@arcot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Tom Wu writes: > That's a security property of the SRP protocol. The important > distinction to bear in mind, to determine if 802.11 ad-hoc or PPP uses > SRP or SRP-Z, is whether or not both sides use their secrets and > verifiers *at the same time* during authentication. > > For example, given that all the nodes in some network had verifiers for > all the other nodes in that network, if node A wants to authenticate to > node B, and node A uses his password while node B uses his verifier for > A to authenticate A, then that's "free" use of SRP. OTOH, if node A > uses his password to authenticate to B, while simultaneously using his > verifier for B to ensure that B is explicitly authenticated back to A, > that's SRP-Z. Standard PPP is symmetric; in a given session, each side can choose to authenticate or not as it sees fit, and the (possible) two authentications are completely independent and asynchronous. If merely using RFC 2495 in two directions "at the same time" is a violation of this separate patent, then we've got a real problem here with EAP SRP-SHA1. At a minimum, I'll probably have to note somewhere that doing bidirectional authentication requires a special license, and document some sort of work-around. Since standard PPP is, as I said, symmetric, this isn't going to be very pretty. This isn't a good result. Thanks for the clarification, though. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jun 20 17:10:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22933 for ; Wed, 20 Jun 2001 17:10:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC65C9124E; Wed, 20 Jun 2001 17:10:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE39C9124F; Wed, 20 Jun 2001 17:10:22 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97E519124E for ; Wed, 20 Jun 2001 17:10:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E42B5DE01; Wed, 20 Jun 2001 17:11:12 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by segue.merit.edu (Postfix) with SMTP id 2414D5DDCF for ; Wed, 20 Jun 2001 17:11:12 -0400 (EDT) Received: from s164.dhcp212-198-137.noos.fr (HELO jc.yahoo.com) (212.198.137.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Jun 2001 21:10:28 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010620225817.00c214e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Jun 2001 23:08:44 +0200 To: Bernard Aboba From: Jacques Caron Subject: Re: EAP-SRP and identity privacy Cc: henry.haverinen@nokia.com, ietf-ppp@merit.edu In-Reply-To: References: <4.3.2.7.2.20010620161155.00c2b570@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 21:12 20/06/01, Bernard Aboba wrote: > > Otherwise the authenticatee might be tricked into sending information > using > > a derived key, which it thinks only the authenticator knows, while the > > NAS/AP actually also knows it. > > > >The keys are ONLY for use at the link layer, right? They MUST NOT be >used for anything else! I'd note that the client doesn't really know who >he's talking to -- with L2TP compulsory tunneling, it might be a tunnel >server halfway around the world, not the NAS. So all the client really >knows is that the other side of the link has obtained the keys it >previously negotiated. Actually, the "standard" is rather the opposite. At the end of EAP negociation, the only two machines to hold the derived session key are the two EAP endpoints, i.e. the authenticatee (the dialup/wireless/whatever client) and the authenticator (the Radius/Diameter server, unless the NAS/AP/whatever is actually the EAP endpoint). Now, the obvious application of this session key is encryption, which is done between the two link-layer endpoints (PPP ECP, 802.11 WEP, PPTP or L2TP ECP...). One the "client" side, no problem, since the endpoints for EAP and encryption are the same. On the other side, they are most probably different. So we need to have the auth server send the key to the NAS/AP/whatever. On the other hand, there might be other mechanisms (such as the one exposed by Henry) that require the key to remain secret between the two EAP endpoints. And in still other scenarios, you might need both: - a key that is only known by the two EAP endpoints (client & auth server) - a key that is known by the two link-layer endpoints (client & NAS/AP), as well as the auth server as a side effect of the process of obtaining those. At the least, the client should be able to know whether the key was derived purely locally by the remote endpoint (i.e. the EAP peer == the encryption peer) or has travelled across a network, encrypted or not. At best, there should be two keys, and the client should be told which one to use for the purposes of link-layer encryption. Note that another application of a key known only by the EAP endpoints would be a "quick reauth"... EAP/SRP is quite heavy, both in terms of network roundtrips and CPU usage, you might not want to run that every minute or so. So, a "simpler" reauth, e.g. server sends a challenge, client sends back the challenge encrypted with the session key, would be nice. But you need to make sure the NAS doesn't know that key, if you want to avoid accounting settlement issues (in a roaming environment). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Wed Jun 20 17:32:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23685 for ; Wed, 20 Jun 2001 17:32:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A7979124F; Wed, 20 Jun 2001 17:32:41 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6429E91250; Wed, 20 Jun 2001 17:32:41 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47C369124F for ; Wed, 20 Jun 2001 17:32:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 283AC5DDB8; Wed, 20 Jun 2001 17:33:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 81A625DDA7 for ; Wed, 20 Jun 2001 17:33:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA09956; Wed, 20 Jun 2001 14:26:35 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 20 Jun 2001 14:26:35 -0700 (PDT) From: Bernard Aboba To: Tom Wu Cc: James Carlson , henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: Question on SRP Intellectual Property Statement In-Reply-To: <3B310B1F.BC0F59A6@arcot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > SRP-Z is indeed a different algorithm. It's not that "both sides store > the verifier", but more accurately, each side has a verifier for its > peer, and both sides use them during authentication. In regular SRP, > explicit authentication is done only in one direction. Don't both sides verify the hashes so as to provie mutual auth? > That's a security property of the SRP protocol. The important > distinction to bear in mind, to determine if 802.11 ad-hoc or PPP uses > SRP or SRP-Z, is whether or not both sides use their secrets and > verifiers *at the same time* during authentication. > So the distinction between SRP and SRP-Z isn't based on an on-the-wire protocol difference, but rather the usage model? Typically you will do one auth at a time, first one direction, then the other. So would that be SRP if they're not *simultaneous*? > For example, given that all the nodes in some network had verifiers for > all the other nodes in that network, if node A wants to authenticate to > node B, and node A uses his password while node B uses his verifier for > A to authenticate A, then that's "free" use of SRP. OTOH, if node A > uses his password to authenticate to B, while simultaneously using his > verifier for B to ensure that B is explicitly authenticated back to A, > that's SRP-Z. > > Tom > Is there a document on SRP-Z available somewhere that we can read so as to make the distinction more clear? From owner-ietf-ppp@merit.edu Thu Jun 21 07:30:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23676 for ; Thu, 21 Jun 2001 07:30:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9DFF79125E; Thu, 21 Jun 2001 07:30:06 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EE979125F; Thu, 21 Jun 2001 07:30:05 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99F889125E for ; Thu, 21 Jun 2001 07:30:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C1655DDEE; Thu, 21 Jun 2001 07:30:55 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 83FBE5DDCE for ; Thu, 21 Jun 2001 07:30:54 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24556; Thu, 21 Jun 2001 05:30:14 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01086; Thu, 21 Jun 2001 07:30:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5LBV2w19548; Thu, 21 Jun 2001 07:31:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15153.56054.214824.594520@gargle.gargle.HOWL> Date: Thu, 21 Jun 2001 07:31:02 -0400 (EDT) From: James Carlson To: Jacques Caron Cc: Bernard Aboba , henry.haverinen@nokia.com, ietf-ppp@merit.edu Subject: Re: EAP-SRP and identity privacy In-Reply-To: Jacques Caron's message of 20 June 2001 23:08:44 References: <4.3.2.7.2.20010620161155.00c2b570@pop.mail.yahoo.com> <4.3.2.7.2.20010620225817.00c214e0@pop.mail.yahoo.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jacques Caron writes: [...] > So we need to have the auth server send the key to the > NAS/AP/whatever. I'm not really comfortable with that notion. I don't like the idea of simply transporting session keys from box to box. It rather defeats the purpose of doing this nifty DH-style key exchange in the first place. Fortunately, this doesn't appear to me to really be an issue for the PPP wg. It's a generic issue for NASREQ/AAA: "if an authentication mechanism produces an encryption session key as a side-effect, is this transported from the server to the NAS and, if so, how?" > At the least, the client should be able to know whether the key was derived > purely locally by the remote endpoint (i.e. the EAP peer == the encryption > peer) or has travelled across a network, encrypted or not. At best, there > should be two keys, and the client should be told which one to use for the > purposes of link-layer encryption. OK. How about this? We add a flag to the Server and Client Validator messages. If this flag is set, then that peer intends to use the session key with any ECP that may be negotiated. If it's not, then the peer won't use the session key. There's no need to negotiate this; merely informing the peer of intent does the job. If either doesn't agree, then the key won't be used. This mechanism solves the problem for systems that can't access the key for some reason (those with some sort of proxy authentication), and those that expect some other keying mechanism (external). > Note that another application of a key known only by the EAP endpoints > would be a "quick reauth"... EAP/SRP is quite heavy, both in terms of > network roundtrips and CPU usage, you might not want to run that every > minute or so. So, a "simpler" reauth, e.g. server sends a challenge, client > sends back the challenge encrypted with the session key, would be nice. But > you need to make sure the NAS doesn't know that key, if you want to avoid > accounting settlement issues (in a roaming environment). Also an interesting idea, though it may leak key material into the data stream. As long as it's limited in use on both ends, it sounds ok. How about this? Authenticator generates a random number (R) and computes H1 = SHA1(R | | "server" | | K). Authenticator sends Request {R, H1} using a new subtype 4. Authenticatee validates H1 and disconnects in an implementation- dependent way if H1 is invalid. Otherwise, it responds either with Response subtype 4 or, if it doesn't wish to participate in this type of rechallenge for any reason (too many in a row, for instance), EAP Nak with hint of SRP-SHA1 in order to restart full EAP SRP-SHA1 authentication. The Response subtype 4, if given, would contain just H2, calculated as SHA1(R | | "client" | | K). (This assumes the is present in the original challenge [subtype 1 request], as it will be in the next rev of the draft. I inadvertently left that out even though it's in the code I've got.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Jun 22 07:14:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16226 for ; Fri, 22 Jun 2001 07:14:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EEBD91273; Fri, 22 Jun 2001 07:14:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C08BD91274; Fri, 22 Jun 2001 07:14:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BCD791273 for ; Fri, 22 Jun 2001 07:14:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EC2D5DDBC; Fri, 22 Jun 2001 07:15:04 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 308D35DDBA for ; Fri, 22 Jun 2001 07:15:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16131; Fri, 22 Jun 2001 07:13:47 -0400 (EDT) Message-Id: <200106221113.HAA16131@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-01.txt Date: Fri, 22 Jun 2001 07:13:46 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over AAL2 Author(s) : B. Thompson, b. Buffam, T. Koren Filename : draft-ietf-pppext-ppp-over-aal2-01.txt Pages : Date : 21-Jun-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ppp-over-aal2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621134553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Tue Jun 26 09:04:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01625 for ; Tue, 26 Jun 2001 09:04:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A530E9125E; Tue, 26 Jun 2001 09:04:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70DD4912FE; Tue, 26 Jun 2001 09:04:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 179C99125E for ; Tue, 26 Jun 2001 09:04:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C04A15DDCF; Tue, 26 Jun 2001 09:05:13 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7EAF25DDA1 for ; Tue, 26 Jun 2001 09:05:11 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5QD4hI16376 for ; Tue, 26 Jun 2001 16:04:43 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 26 Jun 2001 16:04:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 16:04:25 +0300 Message-ID: From: henry.haverinen@nokia.com To: james.d.carlson@east.sun.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy Date: Tue, 26 Jun 2001 16:04:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > > Ah, I think I see what you're suggesting now. So, you're proposing > two levels of encryption on the server side -- one with this private > key, then again with the ephemeral key "K". The client decrypts with > "K" to reveal the encrypted identity, and uses that as its identity > in the next session. > > That appears to fix an important problem. It allows the protocol to > run without having to requery for identity -- the identity is always > in the pseudonym, and it's always valid. Yes, pseudonyms could always be easely recovered by the authenticator. You're right, this would require the pseudonym to be transmitted using some form of reversible encryption. The pseudonym cannot be simply a keyed hash of a nonce. I think some robustness considerations need to be taken into account regardless of the approach we choose. A requery for the identity is an alternative. Or, the authenticator could simply send an EAP-Failure in response to the EAP-Response/Identity if it doesn't recognize the pseudonym, and the client would have to retry with the actual user identity. > An implementation option would be to have an "always use pseudonym, if > available" flag. The semantics would be that, if set, the client > would establish a connection using the real name. If that connection > resulted in a pseudonym (i.e., the authenticator supports this > feature), then the client would disconnect and reconnect. On this > (and subsequent) connections, only the pseudonym would be used, and > network data transfer would then be enabled. Hmm... Why the disconnect? Observers already know that this user is around and using the network. Is it just to make the duration of the session and the traffic patterns unlinkable to observers? I guess that might make sense. > Here's what I'll propose: add an optional Next Pseudonym field to the > Server Validator (Subtype 3) message. If this is present, then the > authenticatee MAY save this value and MAY use it in response to the > EAP Identity Request message in a subsequent session. Regardless of > the use of a Next Pseudonym value in any prior session, the > authenticator MUST always accept the authenticatee's regular name for > validation. This looks good and we just need to specify how the actual next pseudonym is obtained from the contents of the Next Pseudonym field. In any case, it would be good to include some robustness considerations, for example: "If the authenticator does not recognize a pseudonym received in an EAP Identity Response, the authenticator MUST send an EAP Failure to the authenticatee. The authenticatee's regular name SHOULD then be used in the EAP Identity Response message of the next authentication attempt." Regards, Henry From owner-ietf-ppp@merit.edu Tue Jun 26 19:08:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07102 for ; Tue, 26 Jun 2001 19:08:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 233239126C; Tue, 26 Jun 2001 19:05:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E130591352; Tue, 26 Jun 2001 19:05:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC4799126C for ; Tue, 26 Jun 2001 19:05:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 415005DE50; Tue, 26 Jun 2001 19:06:11 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from yarilo.pluris.com (host200.pluris.com [208.227.9.200]) by segue.merit.edu (Postfix) with ESMTP id AECD75DDB4 for ; Tue, 26 Jun 2001 19:06:10 -0400 (EDT) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA21248 for ; Tue, 26 Jun 2001 16:05:24 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 16:04:12 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA0A0EFD@avalon.pluris.com> From: Erol Basturk To: "'ietf-ppp@merit.edu'" Subject: link balancing Date: Tue, 26 Jun 2001 16:04:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu hi, There is a requirement from some vendors to create bundle of high-speed PPP interfaces (POS notably) . Such implementation may not however support PPP fragmentation over multiple links as mandated by MP (RFC 1990), but instead packets are sent unfragmented over one of the links of the bundle, without MP header. At the same time, the functionality provided by MP to validate new members of the bundle is desirable (end-point discriminators, etc.). The PPP link balancing detection draft (draft-ietf-pppext-lbd-02.txt) seemed the right way to address some of these issues by providing new options for MP negotation. This draft is currently expired, although I am not sure why. Unless there are obvious issues with this approach, I would like to request this WG to consider advancing the LBD draft along standard tracks. . Thanks, -- Erol Basturk From owner-ietf-ppp@merit.edu Wed Jun 27 09:48:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12059 for ; Wed, 27 Jun 2001 09:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B18F491371; Wed, 27 Jun 2001 09:48:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 788449137B; Wed, 27 Jun 2001 09:48:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EEF491371 for ; Wed, 27 Jun 2001 09:48:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A2165DE69; Wed, 27 Jun 2001 09:49:25 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 90E825DE64 for ; Wed, 27 Jun 2001 09:49:24 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15572; Wed, 27 Jun 2001 07:48:36 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17695; Wed, 27 Jun 2001 09:48:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.4+Sun/8.11.4) id f5RDnPg10822; Wed, 27 Jun 2001 09:49:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15161.58468.232349.7724@gargle.gargle.HOWL> Date: Wed, 27 Jun 2001 09:49:24 -0400 (EDT) From: James Carlson To: Erol Basturk Cc: "'ietf-ppp@merit.edu'" Subject: Re: link balancing In-Reply-To: Erol Basturk's message of 26 June 2001 16:04:12 References: <17C81AD1F1FED411991E006008F6D1CA0A0EFD@avalon.pluris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Erol Basturk writes: > The PPP link balancing detection draft (draft-ietf-pppext-lbd-02.txt) seemed > the right way to address some of these issues by providing new options for > MP negotation. This draft is currently expired, although I am not sure why. It was lack of expressed interest coupled with the fact that the author's former employer is now floating upside down at the top of the tank. Now that there's interest, I can certainly update the draft and reissue it. > Unless there are obvious issues with this approach, I would like to request > this WG to consider advancing the LBD draft along standard tracks. We'll have to wait for the reissue in order to proceed ... -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jun 28 08:24:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13490 for ; Thu, 28 Jun 2001 08:24:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFF7191205; Thu, 28 Jun 2001 08:25:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FF5F91206; Thu, 28 Jun 2001 08:25:01 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9397491205 for ; Thu, 28 Jun 2001 08:25:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15AE85DDD7; Thu, 28 Jun 2001 08:26:06 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B8DD45DDCC for ; Thu, 28 Jun 2001 08:26:05 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20632; Thu, 28 Jun 2001 05:25:15 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06850; Thu, 28 Jun 2001 08:25:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.4+Sun/8.11.4) id f5SCQ3G22922; Thu, 28 Jun 2001 08:26:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15163.8795.124986.773266@gargle.gargle.HOWL> Date: Thu, 28 Jun 2001 08:26:03 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 26 June 2001 16:04:20 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > Yes, pseudonyms could always be easely recovered by the > authenticator. You're right, this would require the pseudonym to be > transmitted using some form of reversible encryption. The pseudonym > cannot be simply a keyed hash of a nonce. There are two issues here. One is the generation of the pseudonym, which ought to be just a local implementation matter on the authenticator as far as EAP is concerned. The only problem is that if there's proxy authentication going on (AAA), and the determination of the AAA server itself depends on a portion of the identity (e.g., "user@domain.org"), then the NAS needs to recover enough of the real name to direct the query. What I'm going to recommend is that for proxy environments, the server use a long-term configured password (which MAY be the same password as used for AAA access), and hash this with the date (to the nearest day), and then use this as the key for a DES encryption of the real client ID. This allows all NASes within a group to be able to decode the identity in a consistent manner. (Since the AAA server doesn't necessarily know that this decoding is going on, and DIAMETER at least just copies the EAP messages, it seems like this is a requirement on the generation of the pseudonym by the AAA server itself.) Including the date in the hash above has two benefits. The pseudonym for a given client changes unpredictably over time (frustrating the efforts of long-term traffic analysis) and the NAS can statelessly recover prior decoding keys to allow for graceful pseudonym encryption key change without dropping back to cleartext identity. The other issue is transmission of the pseudonym to the authenticatee. Using a nonce has the distinct advantage that no encryption at all is required for this feature, but the implementation disadvantages are probably more significant. So, I'll require the use of a SHA-1-based hiding mechanism (similar to the AVP hiding done in RADIUS and L2TP) for the pseudonym transfer from authenticator to authenticatee. > I think some robustness considerations need to be taken into > account regardless of the approach we choose. A requery for > the identity is an alternative. Or, the authenticator could > simply send an EAP-Failure in response to the EAP-Response/Identity > if it doesn't recognize the pseudonym, and the client would have > to retry with the actual user identity. I'm not wild about the EAP Failure approach because it will cause the authenticatee to disconnect and reconnect on most implementations. On some common media, this can be an unnecessarily expensive proposition, and I don't see that it has any advantage. Since the mechanism (pseudonym support) is brand new, I see no reason we can't overload the ID number semantics in a manner compatible with the spirit of RFC 2284. That is, if the ID number is the same, then the authenticatee should assume that it's seeing a retransmission. The authenticator is required to do that anyway by section 2.2.1. If the ID number is different, then the authenticator is clearly requesting a "new" identity which, in this context, means dropping back to the real client name. > Hmm... Why the disconnect? Observers already know that this user is > around and using the network. Is it just to make the duration of > the session and the traffic patterns unlinkable to observers? I guess > that might make sense. Yes. If the monitoring is done "near" the server side and there's sufficient call traffic, then this introduces uncertainty into the deduction of identity. If the monitoring is not "near" the server or there's little call traffic, then no measure is going to help. Picking one user out of a crowd of one isn't very hard. :-/ So, it might help, and doesn't hurt. > This looks good and we just need to specify how the actual next > pseudonym is obtained from the contents of the Next Pseudonym field. > In any case, it would be good to include some robustness considerations, > for example: > "If the authenticator does not recognize a pseudonym received in > an EAP Identity Response, the authenticator MUST send an EAP Failure > to the authenticatee. The authenticatee's regular name SHOULD then be > used in the EAP Identity Response message of the next authentication > attempt." This exposes another problem. You don't want to allow the authenticatee to be able to probe for valid real names using its EAP Identity Response messages. This means that the use of the pseudonym must be clearly identifiable, and not just assumed on the authenticator's part merely because it doesn't match a known authenticatee name. Prepending the text "Pseudonym" to the name in the EAP Identity Response message and requiring the EAP server to accept only one failed pseudonym per session does the trick. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jun 28 10:34:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14873 for ; Thu, 28 Jun 2001 10:34:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB8C4912C3; Thu, 28 Jun 2001 10:34:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F17D9137B; Thu, 28 Jun 2001 10:34:13 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70ED3912C3 for ; Thu, 28 Jun 2001 10:34:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 303A75DDE2; Thu, 28 Jun 2001 10:35:18 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id EB6035DDE0 for ; Thu, 28 Jun 2001 10:35:16 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5SEb0G06934 for ; Thu, 28 Jun 2001 17:37:00 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 28 Jun 2001 17:34:28 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 28 Jun 2001 17:34:28 +0300 Message-ID: From: henry.haverinen@nokia.com To: james.d.carlson@east.sun.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy Date: Thu, 28 Jun 2001 17:34:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > > There are two issues here. One is the generation of the pseudonym, > which ought to be just a local implementation matter on the > authenticator as far as EAP is concerned. The only problem is that if > there's proxy authentication going on (AAA), and the determination of > the AAA server itself depends on a portion of the identity (e.g., > "user@domain.org"), then the NAS needs to recover enough of the real > name to direct the query. We could use cleartext domain portions in the pseudonyms, so that a pseudomyn of "user@domain.org" would be something like "pseudonym_0487BD83AF3BF45A845109FF345A3235@domain.org". In other words pseudonyms could be valid NAI's. A drawback would be that the organization of the user would be revealed to observers. But the operation of PPP, 802.1X, Radius proxies etc. wouldn't need to be modified. > What I'm going to recommend is that for > proxy environments, the server use a long-term configured password > (which MAY be the same password as used for AAA access), and hash this > with the date (to the nearest day), and then use this as the key for a > DES encryption of the real client ID. This allows all NASes within a > group to be able to decode the identity in a consistent manner. > (Since the AAA server doesn't necessarily know that this decoding is > going on, and DIAMETER at least just copies the EAP messages, it seems > like this is a requirement on the generation of the pseudonym by the > AAA server itself.) > > Including the date in the hash above has two benefits. The pseudonym > for a given client changes unpredictably over time (frustrating the > efforts of long-term traffic analysis) and the NAS can statelessly > recover prior decoding keys to allow for graceful pseudonym encryption > key change without dropping back to cleartext identity. If we want to hide the organization, then I guess something like that is required. Here the NAS must know how to decrypt the pseudonym or the mechanism won't work. So this could cause interoperability problems. At least the client should be able to detect if the NAS doesn't support this feature, and then drop back to cleartext identity. I'm inclined to think the solution should be conservative in what it expects NAS'es to implement. Making the pseudonyms valid NAI's by using cleartext domain names would be a backward compatible way to do this. > I'm not wild about the EAP Failure approach because it will cause the > authenticatee to disconnect and reconnect on most implementations. On > some common media, this can be an unnecessarily expensive proposition, > and I don't see that it has any advantage. > > Since the mechanism (pseudonym support) is brand new, I see no reason > we can't overload the ID number semantics in a manner compatible with > the spirit of RFC 2284. That is, if the ID number is the same, then > the authenticatee should assume that it's seeing a retransmission. > The authenticator is required to do that anyway by section 2.2.1. If > the ID number is different, then the authenticator is clearly > requesting a "new" identity which, in this context, means dropping > back to the real client name. You're right, disconnecting could be too expensive, and I also don't see any reasons why your propsal wouldn't work. I guess even current EAP implementations should have no problems with a second EAP Identity Request. > This exposes another problem. You don't want to allow the > authenticatee to be able to probe for valid real names using its EAP > Identity Response messages. This means that the use of the pseudonym > must be clearly identifiable, and not just assumed on the > authenticator's part merely because it doesn't match a known > authenticatee name. Prepending the text "Pseudonym" to the name in > the EAP Identity Response message and requiring the EAP server to > accept only one failed pseudonym per session does the trick. That sounds like a good idea. Regards, Henry From owner-ietf-ppp@merit.edu Thu Jun 28 10:54:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29045 for ; Thu, 28 Jun 2001 10:54:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB364912C4; Thu, 28 Jun 2001 10:54:26 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98A999137B; Thu, 28 Jun 2001 10:54:26 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 643A5912C4 for ; Thu, 28 Jun 2001 10:54:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C7B05DDCC; Thu, 28 Jun 2001 10:55:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 976185DDCB for ; Thu, 28 Jun 2001 10:55:30 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02159; Thu, 28 Jun 2001 08:54:39 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05441; Thu, 28 Jun 2001 10:54:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.4+Sun/8.11.4) id f5SEtQh23031; Thu, 28 Jun 2001 10:55:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15163.17758.500606.643937@gargle.gargle.HOWL> Date: Thu, 28 Jun 2001 10:55:26 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 28 June 2001 17:34:19 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > We could use cleartext domain portions in the pseudonyms, > so that a pseudomyn of "user@domain.org" would be something like > "pseudonym_0487BD83AF3BF45A845109FF345A3235@domain.org". In other > words pseudonyms could be valid NAI's. > A drawback would be that the organization of the user would be > revealed to observers. But the operation of PPP, 802.1X, Radius > proxies etc. wouldn't need to be modified. It also means that the pseudonym has to be converted to some kind of text representation. I had been planning to use raw binary data for it, but this is obviously friendlier and less troublesome. If it's bigger than the default MTU, then you probably have other identity problems. :-/ One sticking point is that the AAA server itself might not be aware of the domain extension. If so, then it can't add the appropriate "@domain.org" to the pseudonym that it sends back through the NAS. Either the NAS must be able to do this (meaning that the NAS rewrites the EAP message arriving from the DIAMETER server on the fly ... yuck) or the authenticatee must know to tack this string back on when using the pseudonym. Given that the client sent its real name with "@domain.org" in the first place, I'm inclined to move the issue there. This implies a user interface change, since most clients are blissfully ignorant of the domain portion; they just cough up a string configured by a user. Since we're requiring that clients implement stable storage in order to have this new feature, I think the additional burden of isolating the domain value (if any) belongs there as well. We'll need to recommend that clients should be implemented such that they have two strings that are concatenated to form the real name. The first string is the authenticatee's name, and the second is the domain. When sending back the pseudonym, the EAP Identity string is formed as "pseudonym_" | | . When sending back the real name, the string is | . > If we want to hide the organization, then I guess something like that > is required. Here the NAS must know how to decrypt the pseudonym or > the mechanism won't work. So this could cause interoperability problems. > At least the client should be able to detect if the NAS doesn't support > this feature, and then drop back to cleartext identity. You'd have to rely on the NAS failing to decrypt a useful value, being unable to find a AAA server, and then falling back on a second EAP Identify message. Not pretty, but it would work. > I'm inclined to think the solution should be conservative in what > it expects NAS'es to implement. Making the pseudonyms valid NAI's > by using cleartext domain names would be a backward compatible way > to do this. That seems like a fair argument to me. We'll keep the domain in the clear. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Jun 29 09:48:53 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16358 for ; Fri, 29 Jun 2001 09:48:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 383E1912CF; Fri, 29 Jun 2001 09:48:36 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE7AE912D0; Fri, 29 Jun 2001 09:48:35 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6E5D912CF for ; Fri, 29 Jun 2001 09:48:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30A325DE2E; Fri, 29 Jun 2001 09:49:42 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 857535DE1E for ; Fri, 29 Jun 2001 09:49:41 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5TDnEI05411 for ; Fri, 29 Jun 2001 16:49:14 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 29 Jun 2001 16:48:52 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 29 Jun 2001 16:48:52 +0300 Message-ID: From: henry.haverinen@nokia.com To: james.d.carlson@east.sun.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy Date: Fri, 29 Jun 2001 16:48:42 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > It also means that the pseudonym has to be converted to some kind of > text representation. I had been planning to use raw binary data for > it, but this is obviously friendlier and less troublesome. If it's > bigger than the default MTU, then you probably have other identity > problems. :-/ Yes, the size of the pseudonym may become a problem. RFC 2486 says devices handling NAIs MUST support an NAI length of at least 72 octets. That isn't much. We should probably use the 72 octects as efficiently as possible. Can base64 encoding be used? If the pseudonym is opaque to everything else but the AAA server, then maybe we don't have to specify what it is. We should give examples and recommendations. Is it enough if the AAA server is able to tell a pseudonym from an invalid NAI? If so, then the format of the pseudonym could be left up to implementations altogether. If we can do that, then the client should obtain the text presentation of pseudonym (without domain part) from the Next Pseudonym field, without doing any textual encoding itself but just decryption. > Given that the client sent its real name with "@domain.org" in the > first place, I'm inclined to move the issue there. This implies a > user interface change, since most clients are blissfully ignorant of > the domain portion; they just cough up a string configured by a user. > Since we're requiring that clients implement stable storage in order > to have this new feature, I think the additional burden of isolating > the domain value (if any) belongs there as well. I agree. > We'll need to recommend that clients should be implemented such that > they have two strings that are concatenated to form the real name. > The first string is the authenticatee's name, and the second is the > domain. When sending back the pseudonym, the EAP Identity string is > formed as "pseudonym_" | | . > When sending back the real name, the string is | . Yes, the client should be able to concatenate the user name portion of the pseudonym and the domain to the EAP Identity string. (But as I wrote above, I'm not sure if we need to specify the actual format of the pseudonym user name portion.) > > I'm inclined to think the solution should be conservative in what > > it expects NAS'es to implement. Making the pseudonyms valid NAI's > > by using cleartext domain names would be a backward compatible way > > to do this. > > That seems like a fair argument to me. We'll keep the domain in the > clear. OK. This is starting to look pretty good to me! Regards, Henry From owner-ietf-ppp@merit.edu Fri Jun 29 10:11:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00802 for ; Fri, 29 Jun 2001 10:11:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 598B191227; Fri, 29 Jun 2001 10:11:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2772191228; Fri, 29 Jun 2001 10:11:14 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F32C91227 for ; Fri, 29 Jun 2001 10:11:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A835B5DE2E; Fri, 29 Jun 2001 10:12:20 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2F8755DDC4 for ; Fri, 29 Jun 2001 10:12:20 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26606; Fri, 29 Jun 2001 08:11:27 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22908; Fri, 29 Jun 2001 10:11:28 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.4+Sun/8.11.4) id f5TECGv30357; Fri, 29 Jun 2001 10:12:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15164.36032.585652.605628@gargle.gargle.HOWL> Date: Fri, 29 Jun 2001 10:12:16 -0400 (EDT) From: James Carlson To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Subject: RE: EAP-SRP and identity privacy In-Reply-To: henry.haverinen@nokia.com's message of 29 June 2001 16:48:42 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com writes: > Yes, the size of the pseudonym may become a problem. RFC 2486 says > devices handling NAIs MUST support an NAI length of at least 72 octets. > That isn't much. No kidding. I think, though, that if the pseudonym is too long, and the AAA server doesn't handle long enough NAIs, then the failure handling is rather simple; it doesn't recognize the mangled pseudonym, and it does the Identity reprompt to drop back to cleartext. This would conflict with the current definition of the "use pseudonym if available," but not terribly. The heuristic "try again just once; two failures in a row means that the peer lied about its support for pseudonyms" does the job well enough, if necessary. I don't think this is a very serious problem since this is an optional feature anyway. Documenting the failure mode is probably enough. Plus, the pseudonym as specified isn't that big. It's the encrypted user name, so it's just rounded up to the next block boundary as specified by the encryption algorithm. > We should probably use the 72 octects as efficiently as possible. > Can base64 encoding be used? Fortunately, there's no conflict between BASE64 and the NAI syntax, so that's reasonable to do. > If the pseudonym is opaque to everything else but the AAA server, > then maybe we don't have to specify what it is. We should > give examples and recommendations. Is it enough if the AAA server is > able to tell a pseudonym from an invalid NAI? If so, then the format > of the pseudonym could be left up to implementations altogether. I think problem is that the charset needs to be restricted enough that existing NAS implementations can handle the user/realm split. As long as that's maintained, I agree that there's no reason for us to strictly specify it. (I wouldn't be surprised to find the use of strchr(nai,'@') to do the split rather than strrchr(nai,'@') in some NASes. If the AAA server were ignorant of NAIs and chose badly in its encoding of the user portion, this would likely break the NAS's server selection.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677