From pana-admin@ietf.org Tue Jan 6 03:28:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10451 for ; Tue, 6 Jan 2004 03:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmZG-0007OK-LL; Tue, 06 Jan 2004 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmYx-0007NX-1d for pana@optimus.ietf.org; Tue, 06 Jan 2004 03:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10412 for ; Tue, 6 Jan 2004 03:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmYu-0000dn-00 for pana@ietf.org; Tue, 06 Jan 2004 03:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmXB-0000Zi-00 for pana@ietf.org; Tue, 06 Jan 2004 03:25:54 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AdmWZ-0000U9-00 for pana@ietf.org; Tue, 06 Jan 2004 03:25:15 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i068PFC04485; Tue, 6 Jan 2004 09:25:15 +0100 (MET) Received: from carmen ([139.25.62.22]) by mail3.siemens.de (8.11.7/8.11.7) with SMTP id i068PEj26238; Tue, 6 Jan 2004 09:25:14 +0100 (MET) From: "Hannes Tschofenig" To: "Mohan Parthasarathy" Cc: "'Yoshihiro Ohba'" , Subject: RE: [Pana] Unique identifier per session Date: Tue, 6 Jan 2004 09:33:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi mohan, hi yoshi, i am also in favor of including information into the PANA-Bind-Request message for this purpose. but i am still not sure whether you need to update the pre-shared secret for the ike run with every eap "reauthentication" protocol run.. instead i would argue that you should not do it. using this approach you could leave it to the network to trigger a change of the pre-shared secret. ciao hannes > -----Original Message----- > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > Sent: Mittwoch, 31. Dezember 2003 18:33 > To: Tschofenig Hannes > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > a few comments on the ability to have multiple IKE > > > pre-shared secrets > > > > currently for IKE protocol runs: > > > > > > > > ike does not support this type of scenario easily. as stated in > > > [ipsec-pana] > > > > in aggressive mode you could use the ID_KEY_ID with the > > > (session id || > > > > version number) as a key name. this would ensure that you always > > > select > > > the > > > > > > What do you mean by version number ? > > > > if you have multiple IKE pre-shared secrets concurrently > then you need > to > > have a way to distinguish a more recent key from an older one. > > additionally you need to indicate this somehow. when entity > A selects > > key X then entity B needs to know that X was selected. > > > > the key version number could be an integer which is increased by one > if > you > > add a new version of the key. > > > How do you propose to exchange this information between PAA > and PaC ? See the other discussion between me and Yoshihiro. > Explicit communication seems better. I think this should be > another AVP. What do you think ? > > -mohan > > > > > > > > most recent key and in case of failures it would be possible to > > > fallback > > > to > > > > the previous sa. however, this does not work with ike main mode > > > (pre-shared > > > > secret authentication) since the ID payload is sent after > > > authentication > > > > (with message 5). this already caused problems in road > > > warrior cases. > > > > > > > > from this point of view it would be good to use aggressive mode > only > > > (also > > > > from the number of messages). however, the availability of > > > aggressive > > > mode > > > > in existing implementations is not widespread. > > > > > > > My next update (soon to be out) already clarifies that only > > > aggressive mode MUST be supported because of the problem you > > > mention above with main-mode. > > > > great. > > > > ciao > > hannes > > > > > > > > -mohan > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > To: Mohan Parthasarathy > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > Parthasarathy wrote: > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > also > > > does > > > > > not > > > > > > change > > > > > > > > across a reauthentication. > > > > > > > > The PANA-IPsec draft needs something unique to identify > the > > > > > pre-shared > > > > > > keys > > > > > > > > within a sub-session. > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > ID also in > > > > > > reauth-answer. > > > > > > > > 2) Invent another ID that changes with every reauth > > > and hence > > > > > uniquely > > > > > > > > identifies the keys derived > > > > > > > > during a reauth. > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > Session-ID across > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > How about using | as the IKE > pre-shared > > > key > > > > > > > identifier, where N is the number of EAP-based > > > re-authentications > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > I am assuming that "N" is implicitly and independently > > > > > arrived by PaC > > > > > and > > > > > > PAA. > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > message > > > is > > > > > lost. > > > > > > 3) PAA retransmits reauth request > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > message > > > is > > > > > > successful. > > > > > > 5) PAA increments N by 1. > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > that the IKE > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > occurs. When the other type of reauthentication based on > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > IKE > > > > > pre-shared key needs to be updated because there is no > > > change in the > > > > > EAP Master Session Key in this case. For EAP-based > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > derivation can be made because PANA-Bind-Request that > carries an > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > message. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > From what i > > > > > can > > > > > > understand > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > the above > > > > > looks > > > > > > possible. > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 6 03:32:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10559 for ; Tue, 6 Jan 2004 03:32:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admci-0007Vx-I4 for pana-archive@odin.ietf.org; Tue, 06 Jan 2004 03:31:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i068VaKP028886 for pana-archive@odin.ietf.org; Tue, 6 Jan 2004 03:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Admch-0007Vp-Q9 for pana-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 03:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10543 for ; Tue, 6 Jan 2004 03:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Admcf-0000lw-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 03:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Admaq-0000im-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 03:29:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdmZH-0000fN-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 03:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmZG-0007OK-LL; Tue, 06 Jan 2004 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdmYx-0007NX-1d for pana@optimus.ietf.org; Tue, 06 Jan 2004 03:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10412 for ; Tue, 6 Jan 2004 03:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdmYu-0000dn-00 for pana@ietf.org; Tue, 06 Jan 2004 03:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdmXB-0000Zi-00 for pana@ietf.org; Tue, 06 Jan 2004 03:25:54 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AdmWZ-0000U9-00 for pana@ietf.org; Tue, 06 Jan 2004 03:25:15 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i068PFC04485; Tue, 6 Jan 2004 09:25:15 +0100 (MET) Received: from carmen ([139.25.62.22]) by mail3.siemens.de (8.11.7/8.11.7) with SMTP id i068PEj26238; Tue, 6 Jan 2004 09:25:14 +0100 (MET) From: "Hannes Tschofenig" To: "Mohan Parthasarathy" Cc: "'Yoshihiro Ohba'" , Subject: RE: [Pana] Unique identifier per session Date: Tue, 6 Jan 2004 09:33:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi mohan, hi yoshi, i am also in favor of including information into the PANA-Bind-Request message for this purpose. but i am still not sure whether you need to update the pre-shared secret for the ike run with every eap "reauthentication" protocol run.. instead i would argue that you should not do it. using this approach you could leave it to the network to trigger a change of the pre-shared secret. ciao hannes > -----Original Message----- > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > Sent: Mittwoch, 31. Dezember 2003 18:33 > To: Tschofenig Hannes > Cc: 'Yoshihiro Ohba'; pana@ietf.org > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > a few comments on the ability to have multiple IKE > > > pre-shared secrets > > > > currently for IKE protocol runs: > > > > > > > > ike does not support this type of scenario easily. as stated in > > > [ipsec-pana] > > > > in aggressive mode you could use the ID_KEY_ID with the > > > (session id || > > > > version number) as a key name. this would ensure that you always > > > select > > > the > > > > > > What do you mean by version number ? > > > > if you have multiple IKE pre-shared secrets concurrently > then you need > to > > have a way to distinguish a more recent key from an older one. > > additionally you need to indicate this somehow. when entity > A selects > > key X then entity B needs to know that X was selected. > > > > the key version number could be an integer which is increased by one > if > you > > add a new version of the key. > > > How do you propose to exchange this information between PAA > and PaC ? See the other discussion between me and Yoshihiro. > Explicit communication seems better. I think this should be > another AVP. What do you think ? > > -mohan > > > > > > > > most recent key and in case of failures it would be possible to > > > fallback > > > to > > > > the previous sa. however, this does not work with ike main mode > > > (pre-shared > > > > secret authentication) since the ID payload is sent after > > > authentication > > > > (with message 5). this already caused problems in road > > > warrior cases. > > > > > > > > from this point of view it would be good to use aggressive mode > only > > > (also > > > > from the number of messages). however, the availability of > > > aggressive > > > mode > > > > in existing implementations is not widespread. > > > > > > > My next update (soon to be out) already clarifies that only > > > aggressive mode MUST be supported because of the problem you > > > mention above with main-mode. > > > > great. > > > > ciao > > hannes > > > > > > > > -mohan > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > To: Mohan Parthasarathy > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > Parthasarathy wrote: > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > also > > > does > > > > > not > > > > > > change > > > > > > > > across a reauthentication. > > > > > > > > The PANA-IPsec draft needs something unique to identify > the > > > > > pre-shared > > > > > > keys > > > > > > > > within a sub-session. > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > ID also in > > > > > > reauth-answer. > > > > > > > > 2) Invent another ID that changes with every reauth > > > and hence > > > > > uniquely > > > > > > > > identifies the keys derived > > > > > > > > during a reauth. > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > Session-ID across > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > How about using | as the IKE > pre-shared > > > key > > > > > > > identifier, where N is the number of EAP-based > > > re-authentications > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > I am assuming that "N" is implicitly and independently > > > > > arrived by PaC > > > > > and > > > > > > PAA. > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > message > > > is > > > > > lost. > > > > > > 3) PAA retransmits reauth request > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > message > > > is > > > > > > successful. > > > > > > 5) PAA increments N by 1. > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > that the IKE > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > occurs. When the other type of reauthentication based on > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > IKE > > > > > pre-shared key needs to be updated because there is no > > > change in the > > > > > EAP Master Session Key in this case. For EAP-based > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > derivation can be made because PANA-Bind-Request that > carries an > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > message. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > From what i > > > > > can > > > > > > understand > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > the above > > > > > looks > > > > > > possible. > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 6 16:16:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04143 for ; Tue, 6 Jan 2004 16:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYU-0001si-1N; Tue, 06 Jan 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYK-0001sV-0L for pana@optimus.ietf.org; Tue, 06 Jan 2004 16:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04081 for ; Tue, 6 Jan 2004 16:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyYI-0000rK-00 for pana@ietf.org; Tue, 06 Jan 2004 16:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyWc-0000iu-00 for pana@ietf.org; Tue, 06 Jan 2004 16:14:07 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AdyRQ-0000Ut-00 for pana@ietf.org; Tue, 06 Jan 2004 16:08:44 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 6 Jan 2004 21:07:35 -0000 Message-ID: <008501c3d499$1d65ee10$681067c0@adithya> From: "Mohan Parthasarathy" To: "Hannes Tschofenig" Cc: "'Yoshihiro Ohba'" , References: Subject: Re: [Pana] Unique identifier per session Date: Tue, 6 Jan 2004 13:07:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes, > hi mohan, > hi yoshi, > > i am also in favor of including information into the PANA-Bind-Request > message for this purpose. but i am still not sure whether you need to update > the pre-shared secret for the ike run with every eap "reauthentication" > protocol run.. Updating the pre-shared secret does not mean you negotiate a new IKE/IPSec SA. It says that "in the future if you negotiate new SA, use the new pre-shared key". What is the problem with updating it everytime ? > instead i would argue that you should not do it. using this approach > you could leave it to the network to trigger a change of the pre-shared > secret. > Do you mean a new message ? -mohan > ciao > hannes > > > > -----Original Message----- > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > To: Tschofenig Hannes > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > pre-shared secrets > > > > > currently for IKE protocol runs: > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > [ipsec-pana] > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > (session id || > > > > > version number) as a key name. this would ensure that you always > > > > select > > > > the > > > > > > > > What do you mean by version number ? > > > > > > if you have multiple IKE pre-shared secrets concurrently > > then you need > > to > > > have a way to distinguish a more recent key from an older one. > > > additionally you need to indicate this somehow. when entity > > A selects > > > key X then entity B needs to know that X was selected. > > > > > > the key version number could be an integer which is increased by one > > if > > you > > > add a new version of the key. > > > > > How do you propose to exchange this information between PAA > > and PaC ? See the other discussion between me and Yoshihiro. > > Explicit communication seems better. I think this should be > > another AVP. What do you think ? > > > > -mohan > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > fallback > > > > to > > > > > the previous sa. however, this does not work with ike main mode > > > > (pre-shared > > > > > secret authentication) since the ID payload is sent after > > > > authentication > > > > > (with message 5). this already caused problems in road > > > > warrior cases. > > > > > > > > > > from this point of view it would be good to use aggressive mode > > only > > > > (also > > > > > from the number of messages). however, the availability of > > > > aggressive > > > > mode > > > > > in existing implementations is not widespread. > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > aggressive mode MUST be supported because of the problem you > > > > mention above with main-mode. > > > > > > great. > > > > > > ciao > > > hannes > > > > > > > > > > > -mohan > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > To: Mohan Parthasarathy > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > Parthasarathy wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > also > > > > does > > > > > > not > > > > > > > change > > > > > > > > > across a reauthentication. > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > the > > > > > > pre-shared > > > > > > > keys > > > > > > > > > within a sub-session. > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > ID also in > > > > > > > reauth-answer. > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > and hence > > > > > > uniquely > > > > > > > > > identifies the keys derived > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > Session-ID across > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > How about using | as the IKE > > pre-shared > > > > key > > > > > > > > identifier, where N is the number of EAP-based > > > > re-authentications > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > arrived by PaC > > > > > > and > > > > > > > PAA. > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > lost. > > > > > > > 3) PAA retransmits reauth request > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > > successful. > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > that the IKE > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > occurs. When the other type of reauthentication based on > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > IKE > > > > > > pre-shared key needs to be updated because there is no > > > > change in the > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > derivation can be made because PANA-Bind-Request that > > carries an > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > message. > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > From what i > > > > > > can > > > > > > > understand > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > the above > > > > > > looks > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 6 16:20:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04448 for ; Tue, 6 Jan 2004 16:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adyc7-00025h-Hr for pana-archive@odin.ietf.org; Tue, 06 Jan 2004 16:19:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i06LJlVv008031 for pana-archive@odin.ietf.org; Tue, 6 Jan 2004 16:19:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Adyc7-00025S-9n for pana-web-archive@optimus.ietf.org; Tue, 06 Jan 2004 16:19:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04394 for ; Tue, 6 Jan 2004 16:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adyc5-00018U-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 16:19:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyaJ-000123-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 16:17:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdyYV-0000st-00 for pana-web-archive@ietf.org; Tue, 06 Jan 2004 16:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYU-0001si-1N; Tue, 06 Jan 2004 16:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdyYK-0001sV-0L for pana@optimus.ietf.org; Tue, 06 Jan 2004 16:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04081 for ; Tue, 6 Jan 2004 16:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdyYI-0000rK-00 for pana@ietf.org; Tue, 06 Jan 2004 16:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdyWc-0000iu-00 for pana@ietf.org; Tue, 06 Jan 2004 16:14:07 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AdyRQ-0000Ut-00 for pana@ietf.org; Tue, 06 Jan 2004 16:08:44 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 6 Jan 2004 21:07:35 -0000 Message-ID: <008501c3d499$1d65ee10$681067c0@adithya> From: "Mohan Parthasarathy" To: "Hannes Tschofenig" Cc: "'Yoshihiro Ohba'" , References: Subject: Re: [Pana] Unique identifier per session Date: Tue, 6 Jan 2004 13:07:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hannes, > hi mohan, > hi yoshi, > > i am also in favor of including information into the PANA-Bind-Request > message for this purpose. but i am still not sure whether you need to update > the pre-shared secret for the ike run with every eap "reauthentication" > protocol run.. Updating the pre-shared secret does not mean you negotiate a new IKE/IPSec SA. It says that "in the future if you negotiate new SA, use the new pre-shared key". What is the problem with updating it everytime ? > instead i would argue that you should not do it. using this approach > you could leave it to the network to trigger a change of the pre-shared > secret. > Do you mean a new message ? -mohan > ciao > hannes > > > > -----Original Message----- > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > To: Tschofenig Hannes > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > pre-shared secrets > > > > > currently for IKE protocol runs: > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > [ipsec-pana] > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > (session id || > > > > > version number) as a key name. this would ensure that you always > > > > select > > > > the > > > > > > > > What do you mean by version number ? > > > > > > if you have multiple IKE pre-shared secrets concurrently > > then you need > > to > > > have a way to distinguish a more recent key from an older one. > > > additionally you need to indicate this somehow. when entity > > A selects > > > key X then entity B needs to know that X was selected. > > > > > > the key version number could be an integer which is increased by one > > if > > you > > > add a new version of the key. > > > > > How do you propose to exchange this information between PAA > > and PaC ? See the other discussion between me and Yoshihiro. > > Explicit communication seems better. I think this should be > > another AVP. What do you think ? > > > > -mohan > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > fallback > > > > to > > > > > the previous sa. however, this does not work with ike main mode > > > > (pre-shared > > > > > secret authentication) since the ID payload is sent after > > > > authentication > > > > > (with message 5). this already caused problems in road > > > > warrior cases. > > > > > > > > > > from this point of view it would be good to use aggressive mode > > only > > > > (also > > > > > from the number of messages). however, the availability of > > > > aggressive > > > > mode > > > > > in existing implementations is not widespread. > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > aggressive mode MUST be supported because of the problem you > > > > mention above with main-mode. > > > > > > great. > > > > > > ciao > > > hannes > > > > > > > > > > > -mohan > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > To: Mohan Parthasarathy > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > Parthasarathy wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > also > > > > does > > > > > > not > > > > > > > change > > > > > > > > > across a reauthentication. > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > the > > > > > > pre-shared > > > > > > > keys > > > > > > > > > within a sub-session. > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > ID also in > > > > > > > reauth-answer. > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > and hence > > > > > > uniquely > > > > > > > > > identifies the keys derived > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > Session-ID across > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > How about using | as the IKE > > pre-shared > > > > key > > > > > > > > identifier, where N is the number of EAP-based > > > > re-authentications > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > arrived by PaC > > > > > > and > > > > > > > PAA. > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > lost. > > > > > > > 3) PAA retransmits reauth request > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > > successful. > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > that the IKE > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > occurs. When the other type of reauthentication based on > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > IKE > > > > > > pre-shared key needs to be updated because there is no > > > > change in the > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > derivation can be made because PANA-Bind-Request that > > carries an > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > message. > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > From what i > > > > > > can > > > > > > > understand > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > the above > > > > > > looks > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 7 14:09:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25060 for ; Wed, 7 Jan 2004 14:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ37-0004Nu-5m; Wed, 07 Jan 2004 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ2E-0004Ia-Ak for pana@optimus.ietf.org; Wed, 07 Jan 2004 14:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24937 for ; Wed, 7 Jan 2004 14:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeJ2B-0005t4-00 for pana@ietf.org; Wed, 07 Jan 2004 14:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeJ0G-0005kp-00 for pana@ietf.org; Wed, 07 Jan 2004 14:06:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AeIyM-0005fC-00 for pana@ietf.org; Wed, 07 Jan 2004 14:04:06 -0500 Date: Wed, 07 Jan 2004 11:03:47 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200312232034.PAA07743@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3156318231_1470783" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] FW: I-D ACTION:draft-yacine-pana-snmp-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3156318231_1470783 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 23 Dec 2003 15:34:12 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yacine-pana-snmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PANA: SNMP usage for PAA-2-EP interface Author(s) : Y. Mghazli Filename : draft-yacine-pana-snmp-00.txt Pages : 23 Date : 2003-12-23 The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yacine-pana-snmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-yacine-pana-snmp-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-yacine-pana-snmp-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. ------ End of Forwarded Message --B_3156318231_1470783 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDAzLTEyLTIzMTUzMDIz LkktREBpZXRmLm9yZz4NDUVOQ09ESU5HIG1pbWUNRklMRSAvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXlhY2luZS1wYW5hLXNubXAtMDAudHh0DQ0= --B_3156318231_1470783 Content-type: application/octet-stream; name="draft-yacine-pana-snmp-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDAzLTEyLTIzMTUzMDIz LkktREBpZXRmLm9yZz4NDQ== --B_3156318231_1470783-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 7 14:12:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25447 for ; Wed, 7 Jan 2004 14:12:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ6M-0004kI-QX for pana-archive@odin.ietf.org; Wed, 07 Jan 2004 14:12:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07JCMc6018236 for pana-archive@odin.ietf.org; Wed, 7 Jan 2004 14:12:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ6M-0004k3-Mv for pana-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 14:12:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25360 for ; Wed, 7 Jan 2004 14:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeJ6K-0006Hb-00 for pana-web-archive@ietf.org; Wed, 07 Jan 2004 14:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeJ4h-0006AC-00 for pana-web-archive@ietf.org; Wed, 07 Jan 2004 14:10:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeJ37-00061h-00 for pana-web-archive@ietf.org; Wed, 07 Jan 2004 14:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ37-0004Nu-5m; Wed, 07 Jan 2004 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeJ2E-0004Ia-Ak for pana@optimus.ietf.org; Wed, 07 Jan 2004 14:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24937 for ; Wed, 7 Jan 2004 14:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeJ2B-0005t4-00 for pana@ietf.org; Wed, 07 Jan 2004 14:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeJ0G-0005kp-00 for pana@ietf.org; Wed, 07 Jan 2004 14:06:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AeIyM-0005fC-00 for pana@ietf.org; Wed, 07 Jan 2004 14:04:06 -0500 Date: Wed, 07 Jan 2004 11:03:47 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200312232034.PAA07743@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3156318231_1470783" Subject: [Pana] FW: I-D ACTION:draft-yacine-pana-snmp-00.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3156318231_1470783 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 23 Dec 2003 15:34:12 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yacine-pana-snmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PANA: SNMP usage for PAA-2-EP interface Author(s) : Y. Mghazli Filename : draft-yacine-pana-snmp-00.txt Pages : 23 Date : 2003-12-23 The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client (PaC) successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group mandates the use of Simple Network Management Protocol (SNMP) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMP as the PAA-2-EP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yacine-pana-snmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-yacine-pana-snmp-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-yacine-pana-snmp-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. ------ End of Forwarded Message --B_3156318231_1470783 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDAzLTEyLTIzMTUzMDIz LkktREBpZXRmLm9yZz4NDUVOQ09ESU5HIG1pbWUNRklMRSAvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXlhY2luZS1wYW5hLXNubXAtMDAudHh0DQ0= --B_3156318231_1470783 Content-type: application/octet-stream; name="draft-yacine-pana-snmp-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDAzLTEyLTIzMTUzMDIz LkktREBpZXRmLm9yZz4NDQ== --B_3156318231_1470783-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 8 08:31:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22478 for ; Thu, 8 Jan 2004 08:31:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaFa-0007iO-Gx; Thu, 08 Jan 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaF4-0007hd-HO for pana@optimus.ietf.org; Thu, 08 Jan 2004 08:30:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22455 for ; Thu, 8 Jan 2004 08:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeaEy-00025h-00 for pana@ietf.org; Thu, 08 Jan 2004 08:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aea9H-0001su-00 for pana@ietf.org; Thu, 08 Jan 2004 08:24:32 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Aea6h-0001iz-00 for pana@ietf.org; Thu, 08 Jan 2004 08:21:51 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i08DKm7F026468 for ; Thu, 8 Jan 2004 14:20:48 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004010814204711:4044 ; Thu, 8 Jan 2004 14:20:47 +0100 Message-ID: <3FFD592F.9080400@alcatel.fr> Date: Thu, 08 Jan 2004 14:20:47 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@ietf.org X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/08/2004 14:20:47, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/08/2004 14:20:48, Serialize complete at 01/08/2004 14:20:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Pana] PAA-2-EP SNMP solution Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, http://www.ietf.org/internet-drafts/draft-yacine-pana-snmp-00.txt this ID provides an SNMP solution for the PAA-2-EP interface. please do note two remarks: 1) discussions on the PAA-2-EP protocol requirements are currently held on the PANA ML. 2) this SNMP solution is largely based on the IPSec Configuration MIB that has been designed in the IPSP wg. Indeed, it has recently been decided to split this IPSec MIB into 3 modules (see http://www.vpnc.org/ipsec-policy/mail-archive/msg00797.html). In the present version of the draft, the IPSec MIB is referenced as a whole, as it was before the split, when I edited this version. the next version of the document would take these changes into account. thanks, yacine _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 8 08:39:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22798 for ; Thu, 8 Jan 2004 08:39:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaMy-0008Hv-Sa for pana-archive@odin.ietf.org; Thu, 08 Jan 2004 08:38:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08Dce29031853 for pana-archive@odin.ietf.org; Thu, 8 Jan 2004 08:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaMy-0008Hg-OT for pana-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 08:38:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22749 for ; Thu, 8 Jan 2004 08:38:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeaMx-0002ey-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 08:38:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeaLA-0002Ri-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 08:36:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AeaFu-0002AY-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 08:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaFa-0007iO-Gx; Thu, 08 Jan 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeaF4-0007hd-HO for pana@optimus.ietf.org; Thu, 08 Jan 2004 08:30:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22455 for ; Thu, 8 Jan 2004 08:30:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeaEy-00025h-00 for pana@ietf.org; Thu, 08 Jan 2004 08:30:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aea9H-0001su-00 for pana@ietf.org; Thu, 08 Jan 2004 08:24:32 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Aea6h-0001iz-00 for pana@ietf.org; Thu, 08 Jan 2004 08:21:51 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i08DKm7F026468 for ; Thu, 8 Jan 2004 14:20:48 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004010814204711:4044 ; Thu, 8 Jan 2004 14:20:47 +0100 Message-ID: <3FFD592F.9080400@alcatel.fr> Date: Thu, 08 Jan 2004 14:20:47 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@ietf.org X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/08/2004 14:20:47, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/08/2004 14:20:48, Serialize complete at 01/08/2004 14:20:48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Subject: [Pana] PAA-2-EP SNMP solution Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, http://www.ietf.org/internet-drafts/draft-yacine-pana-snmp-00.txt this ID provides an SNMP solution for the PAA-2-EP interface. please do note two remarks: 1) discussions on the PAA-2-EP protocol requirements are currently held on the PANA ML. 2) this SNMP solution is largely based on the IPSec Configuration MIB that has been designed in the IPSP wg. Indeed, it has recently been decided to split this IPSec MIB into 3 modules (see http://www.vpnc.org/ipsec-policy/mail-archive/msg00797.html). In the present version of the draft, the IPSec MIB is referenced as a whole, as it was before the split, when I edited this version. the next version of the document would take these changes into account. thanks, yacine _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 8 10:36:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28243 for ; Thu, 8 Jan 2004 10:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecCY-0005lk-48; Thu, 08 Jan 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecBe-0005fe-0V for pana@optimus.ietf.org; Thu, 08 Jan 2004 10:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28137 for ; Thu, 8 Jan 2004 10:34:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecBR-0001lo-00 for pana@ietf.org; Thu, 08 Jan 2004 10:34:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aec5P-0001SG-00 for pana@ietf.org; Thu, 08 Jan 2004 10:28:40 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AebzJ-000194-00 for pana@ietf.org; Thu, 08 Jan 2004 10:22:21 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i08FM9r13066; Thu, 8 Jan 2004 16:22:10 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i08FM8L00898; Thu, 8 Jan 2004 16:22:09 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jan 2004 16:21:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC054F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Mohan Parthasarathy'" Cc: "'Yoshihiro Ohba'" , "'pana@ietf.org'" Subject: RE: [Pana] Unique identifier per session Date: Thu, 8 Jan 2004 16:21:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi mohan, > Hannes, > > > hi mohan, > > hi yoshi, > > > > i am also in favor of including information into the > PANA-Bind-Request > > message for this purpose. but i am still not sure whether > you need to > update > > the pre-shared secret for the ike run with every eap > "reauthentication" > > protocol run.. > Updating the pre-shared secret does not mean you negotiate a > new IKE/IPSec SA. good. > It says that "in the future if you > negotiate new SA, use the new pre-shared key". What is the > problem with updating it everytime ? adding a new pre-shared secret is no problem. but you need to specify whether you run a new ike exchange as a result of a new eap exchange. i guess in ieee 802.11i/8002.1x you establish a new link layer security association if you execute a new eap exchange. is there someone who has a preference? > > > instead i would argue that you should not do it. using > this approach > > you could leave it to the network to trigger a change of the > pre-shared > > secret. > > > Do you mean a new message ? i personally think that you only need a new AVP which is carried within a PANA-Bind-Request message. ciao hannes > > -mohan > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > > To: Tschofenig Hannes > > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > > pre-shared secrets > > > > > > currently for IKE protocol runs: > > > > > > > > > > > > ike does not support this type of scenario easily. as stated > in > > > > > [ipsec-pana] > > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > > (session id || > > > > > > version number) as a key name. this would ensure that you > always > > > > > select > > > > > the > > > > > > > > > > What do you mean by version number ? > > > > > > > > if you have multiple IKE pre-shared secrets concurrently > > > then you need > > > to > > > > have a way to distinguish a more recent key from an older one. > > > > additionally you need to indicate this somehow. when entity > > > A selects > > > > key X then entity B needs to know that X was selected. > > > > > > > > the key version number could be an integer which is increased by > one > > > if > > > you > > > > add a new version of the key. > > > > > > > How do you propose to exchange this information between > PAA and PaC > > > ? See the other discussion between me and Yoshihiro. Explicit > > > communication seems better. I think this should be > another AVP. What > > > do you think ? > > > > > > -mohan > > > > > > > > > > > > > > most recent key and in case of failures it would be possible > to > > > > > fallback > > > > > to > > > > > > the previous sa. however, this does not work with ike main > mode > > > > > (pre-shared > > > > > > secret authentication) since the ID payload is sent after > > > > > authentication > > > > > > (with message 5). this already caused problems in road > > > > > warrior cases. > > > > > > > > > > > > from this point of view it would be good to use aggressive > mode > > > only > > > > > (also > > > > > > from the number of messages). however, the availability of > > > > > aggressive > > > > > mode > > > > > > in existing implementations is not widespread. > > > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > > aggressive mode MUST be supported because of the problem you > > > > > mention above with main-mode. > > > > > > > > great. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > -mohan > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > > To: Mohan Parthasarathy > > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > > Parthasarathy wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a > session. But, it > > > also > > > > > does > > > > > > > not > > > > > > > > change > > > > > > > > > > across a reauthentication. > > > > > > > > > > The PANA-IPsec draft needs something unique to > identify > > > the > > > > > > > pre-shared > > > > > > > > keys > > > > > > > > > > within a sub-session. > > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > > ID also in > > > > > > > > reauth-answer. > > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > > and hence > > > > > > > uniquely > > > > > > > > > > identifies the keys derived > > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > > Session-ID across > > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > > > How about using | as the IKE > > > pre-shared > > > > > key > > > > > > > > > identifier, where N is the number of EAP-based > > > > > re-authentications > > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > > arrived by PaC > > > > > > > and > > > > > > > > PAA. > > > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > lost. > > > > > > > > 3) PAA retransmits reauth request > > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > > successful. > > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > > that the IKE > > > > > > > pre-shared key is updated when an EAP-based > re-authentication > > > > > > > occurs. When the other type of reauthentication based on > > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think > the > > > IKE > > > > > > > pre-shared key needs to be updated because there is no > > > > > change in the > > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > > re-authentication, synchronization on EAP Master > Session Key > > > > > > > derivation can be made because PANA-Bind-Request that > > > carries an > > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > > message. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above > possible ? > > > > > > > From what i > > > > > > > can > > > > > > > > understand > > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > > the above > > > > > > > looks > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Pana mailing list > > > > > > > > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From mailman-admin@ietf.org Fri Jan 9 12:52:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18187 for ; Fri, 9 Jan 2004 12:52:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af0nH-0000zT-K5 for pana-archive@lists.ietf.org; Fri, 09 Jan 2004 12:51:35 -0500 Date: Fri, 09 Jan 2004 12:51:35 -0500 Message-ID: <20040109175135.9164.71666.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pana-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pana-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pana-archive@lists.ietf.org: List Password // URL ---- -------- pana@ietf.org onobde https://www1.ietf.org/mailman/options/pana/pana-archive%40lists.ietf.org From pana-admin@ietf.org Mon Jan 12 18:33:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29521 for ; Mon, 12 Jan 2004 18:33:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBYK-0001hW-FI; Mon, 12 Jan 2004 18:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBXQ-0001gN-UY for pana@optimus.ietf.org; Mon, 12 Jan 2004 18:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29473 for ; Mon, 12 Jan 2004 18:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBXN-0001NR-00 for pana@ietf.org; Mon, 12 Jan 2004 18:32:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBVa-0001JX-00 for pana@ietf.org; Mon, 12 Jan 2004 18:30:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AgBTq-0001FE-00 for pana@ietf.org; Mon, 12 Jan 2004 18:28:22 -0500 Date: Mon, 12 Jan 2004 15:28:11 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Hannes Tschofenig CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Hannes, Thank you for this analysis! This is a very useful material for having this discussion... Please see my inlined comments below. > hi all, >=20 > an interesting issue with a relationship to the EAP keying work was raise= d. > i have tried (in this first shot) to write a short text on the EAP keying > issues as they appear in PANA. >=20 > this text also includes some discussion parts where further input is > required (denoted as FOR DISCUSSION). >=20 > ciao > hannes >=20 > ------------- >=20 > Protocol Communication Overview > ------------------------------------------- >=20 > This section discusses EAP keying issues and is therefore strongly aligne= d > with Section 1.3 of [EAP-Keying]. There the entire EAP communication is > separated into three steps. Note that the first step is actually not part= of > EAP itself. >=20 > - Discovery phase (phase 0) > - EAP authentication, key derivation and transport (phase 1) > - Unicast security association establishment (phase 2) >=20 > The discovery phase in PANA has the goal to find the PAA in the visited > network. This step is very hard to secure in a roaming environment. In ma= ny > cases an additional security protection at this step would add denial of > service vulnerabilities. However, to prevent very basic denial of service > attacks, whereby an adversary floods the PAA with bogus requests, a cooki= e > exchange is used. In PANA no capability discovery takes place at phase 0. >=20 > Phase 1 is subdivided into two phases: Phase 1a and phase 1b. In phase 1a > the PAA starts sending the initial EAP packet and thereby initiates the > authentication procedure. The PAA might implement some EAP methods or in > many cases not even a single one - it acts as a passthrough device which > interacts with a backend authentication server. >=20 > EAP methods might provide key derivation and mutual authentication. PANA > leaves the choice to network architects which EAP methods to mandate. Thi= s > is necessary to fullfil the requirements of the larger number of deployme= nt > scenarios. In case of wireless networks without physical or link layer > security the suggestions of [EAP-KEYING] with regard to EAP methods shoul= d > be followed. Methods which provide session key establishment and mutual > authentication are mandated. >=20 > Since the key derivation takes place between the EAP peer and the EAP ser= ver > it is (in many cases) necessary to transport the keying material from the > EAP server to the Authenticator (which corresponds to the PAA in PANA). T= his > step is referred as phase 1b. If the EAP server and the Authenticator are > co-located then this step is replaced by an API call. >=20 > Since PANA signaling messages need protection a PANA SA needs to be > established between the PaC and the PAA The PANA SA is needed to provide the keys for the so-called phase 2. While we have this SA, we thought we can also use it for securing the subsequent PANA exchanges. Though, it is not a requirement that PANA, as a EAP lower layer, needs this kind of protection. > whereby new keying material needs to > be derived from the key provided by the EAP method. This step is a slight > deviation from IEEE 802.1X since PANA does not automatically create secur= ity > associations for data traffic protection. 802.1X does not either. It's the 4-way handshake of 802.11i that creates this SA. > With the help of EAP session keys are in place and PANA needs to create, > delete and update the parameters of the PANA SA. >=20 > PANA makes a more fine-grain separation in phase 2. Parts of phase 2a are > accomplished within PANA and some parts are delegated towards IKE if IPse= c > SA establishment is desired (see [PANA-IPsec]). Phase 2b does not exist i= n > PANA. We will address the differences in more details in this section. >=20 > Figure 1 shows the communication overview. The figure is taken from > [EAP-Keying] and modified accordingly. The "Unicast Secure association > (phase 2a)" is replaced by the abstract term PANA Phase 2 to avoid a > terminology confusion. >=20 >=20 > EAP peer/PaC Authenticator/PAA Auth. Server > ------------ ----------------- ------------ > |<----------------------------->| | > | Discovery (phase 0) | | > |<----------------------------->|<----------------------------->| > | EAP auth (phase 1a) | AAA pass-through (optional) | > | | | > | |<----------------------------->| > | | AAA-Key transport | > | | (optional; phase 1b) | > |<----------------------------->| | > | PANA Phase 2 | | > | | | > |<----------------------------->| | > | IKE/IPsec SA establishment | | > | (optional) | | > | | | I didn't understand why we have "PANA phase 2". Normally PANA should not "leak into" phase 2. Phase 2 is for IKE (or, in the case of 802.1X-based systems, 4-way handshake) >=20 > Figure 1: Communication Overview >=20 > Figure 1 ignores the fact that the Authenticator/PAA can physically be > separated from the Enforcement Point (EP). In this case IKE would not run > between the PaC and the PAA. >=20 > Phase 2 is executed after a successful EAP exchange in phase 1 (including > the transport of keying material to the Authenticator). >=20 > This phase accomplishes the following tasks (compared with the list > described in Section 1.3 of [EAP-KEYING]): >=20 > - Since PANA does not negotiate parameters during the discovery phase it = is > not possible to confirm them. No cipher suite negotiation takes place in > PANA. >=20 > - PANA securely provides an exchange of parameters and usage modes as par= t > of the PANA-Bind-Request message (such as Device-Id, Lifetime, > Protection-Cap AVPs). >=20 > - PANA does not derive further session keys for protection of data traffi= c. > If an IPsec has to be established then IKE or IKEv2 is used. >=20 > - Mutual key confirmation (PAA to PaC with the help of the PANA-Bind-Requ= est > and PaC to PAA with the help of the PANA-Bind-Answer message) is provided= . > This ensure that both, the PaC and the PAA, successfully executed EAP and= , > in the case of the PAA, were able to create the necessary keys and parame= ter > for the PANA SA. >=20 > - The PANA SA is active immediately after the PANA SA is established (i.e= ., > after the EAP method was successfully executed and session keys are > available). >=20 > - PANA also offers a mechanism for terminating access and to delete the > established state with the help of the PANA-Termination-Request and > PANA-Termination-Answer message. Without sending such a message the PAA a= nd > the PaC delete their established state after lifetime expiration. >=20 > Security Associations > -------------------------- >=20 > Several different security associations are created as part of the PANA > exchange. We will describe of them in some level of detail whereby some P= ANA > specific aspects might lead to discussions. >=20 > - EAP SA >=20 > First, there is the EAP SA which is described in Section 3.1 of > [EAP-KEYING]. Due to the nature of EAP there are some restrictions on the > EAP SA such as the missing lifetime negotiation, no SA delete operation e= tc. > Some EAP methods provide enhanced functionality by establishing additiona= l > state which is subject to special optimizations such as "fast resume". A > detailed discussion of these issues is beyond the scope of PANA. >=20 > - AAA-Key SA / PANA SA >=20 > The AAA-Key SA described in Section 3.2 of [EAP-KEYING] seems to be the > counterpart of the PANA SA. This security association exists between the = PaC > and the PAA. The following parameters constitute this AAA-Key SA: >=20 > - the EAP peer name > - the NAS/authenticator name > - the AAA-Key > - the AAA-Key maximum lifetime (if known) > - the AAA attributes sent in the Access-Accept >=20 > The subsequent paragraph is an attempt to map the text in [EAP-KEYING] to > PANA. >=20 > For the PANA-SA at the PAA would have the following parameters: > - AAA attributes (obtained via the Access-Accept) > - Lifetime (optional?) > - Key of the PANA SA (derived from the AAA-Key) > - Socket-Pair information (Src/Dst IP address, Src/Port, UDP protocol) We don't really deal with "sockets" context in the PANA design. Instead, I think we can refer to the "device IDs" in here. > - Session ID > The PANA-SA at the PaC contains similar attributes except for the AAA > attributes since they are invisible to the PaC. >=20 > The lifetime of the PANA SA is determined by a number of parameters. The > Lifetime AVP transmitted to the PaC is an indication for the PaC about th= e > time duration granted for network access (and therefore also for the > lifetime of the security association). >=20 > The identities used for the PaC and the PAA are less clearly described in > PANA (and also in the EAP context). Some of these issues will be discusse= d > again in the context of "key naming". >=20 > The identity of the NAS (in the IEEE context) or PAA (in PANA) has to be > mapped to attributes in the AAA infrastructure. Hence, within RADIUS the = NAS > is identified by the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address > attributes. Although these attributes are kept very flexible it needs to = be > ensured that they match to the PANA context. >=20 > --- >=20 > FOR DISCUSSION: Should the PANA SA be bound to a specific PaC <-> PAA? Th= is > is particularly of interest for mobility. It needs to be evaluated whethe= r > the discussion in the EAP keying design team (or within the EAP working > group in general) is an issue here or even in general (e.g., a virtual NA= S). PANA SA is bound to a PANA session. >=20 > FOR DISCUSSION: Should a new key be derived after the lifetime of the PAN= A > SA expires (as part of a re-authentication procedure)? This should then > require that the Lifetime AVP is mandatory in order for the PaC to perfor= m > the same computation/protocol action. What protocol interaction is requir= ed > for rekeying? It should be noted that the expiration of the PANA SA lifet= ime > is not necessarily the same as a regular SA expiration. The lifetime refe= rs > more likely to the authorization decision or some other security policy > based aspects of reauthentication interval. A clarification would be > necessary and helpful. When the PANA session expires, if the peers are interested in continuing th= e "access", another run of EAP is executed inside PANA. This should create a new EAP SA, hence a new PANA SA. >=20 > --- >=20 > - Unicast Secure Association SA / IPsec SA >=20 > In [EAP-KEYING] a "unicast secure association SA" seems to be a link laye= r > specific security association which is used to protect the data traffic > itself. In the PANA context the equivalent would be an IPsec SA. In theory, one might choose to enable L2 ciphering after a successful PANA authentication. For example, using the newly generated keys with WPA-PSK. I'm not aware of anyone looking at the details yet though. So, this is another possibility in addition to enabling IPsec-based access control. > Since PANA > IPsec uses IKE or IKEv2, it would be necessary to consider also the state > established with these protocols. >=20 > The content of the "unicast secure association SA" is described as >=20 > - the peer port identifier (Calling-Station-Id) > - the NAS port identifier (Called-Station-Id) > - the unicast Transient Session Keys (TSKs) > - the unicast secure association peer nonce > - the unicast secure association authenticator nonce > - the negotiated unicast capabilities and unicast ciphersuite. >=20 > For PANA IPsec usage three SAs are of relevance: > - PANA-IKE-SA > - IKE-SA/ISAKMP SA > - IPsec SA >=20 > Each of these SAs have different attributes and a different lifetime. >=20 > The content of the IPsec SA and the IKE-SA/ISAKMP SA is described in the > relevant IPsec working group documents and will not be repeated here. >=20 > The PANA-IKE-SA, which is the state information used as input to the IKE = / > IKEv2 exchange, is of interest here. The following information is necessa= ry: So, is this what you are saying: EAP SA -> PANA SA -> PANA-IKE-SA -> IPsec-SA Do we need PANA-IKE-SA, or can we skip it? >=20 > - the PANA-SA derived key (which is indirectly used as a pre-shared > secret for IKE/IKEv2) > - the identities of the PaC (IP address) and EP (also IP address) (both > IP addresses are > made available to both entities during the PANA protocol execution). > - the Session ID >=20 > --- >=20 > FOR DISCUSSION: A key derived from the PANA SA key should be used as inpu= t > to the key derivation function for the IKE preshared secret key and not t= he > MSK. Mutual key confirmation is provided for the PANA SA key. >=20 > --- >=20 >> From authorization point of view it is necessary to ensure that the IPse= c > SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain active after the > PANA context is removed since otherwise network resources could be consum= ed > without authorization. Since the PaC is able to send a terminate message = at > any time there is a need for a good API between the PAA/EP and the IKE/IP= sec > daemon. >=20 > --- >=20 > FOR DISCUSSION: > Should a newly derived key for the PANA SA lead to a new key for the > PANA-IKE SA? My preference is NO. The PaC should, however, be able to > create a new IPsec SA at any time during the lifetime of a PANA SA. > Should the PAA be able to force the PaC to create a new IPsec SA? > Should it be possible to create more than one IPsec SA between the PaC an= d > the EP at the same time (for example to support different quality of serv= ice > classes)? I think this is beyond the scope of PANA design. If PANA provides a shared secret to PaC and EP for generation of an IPsec SA for access control, then its job is done. If someone proposes a design for generating multiple IPsec SAs from a single shared secret for QoS/etc reasons, then they can do so independent of where the shared secret came from. >=20 > --- >=20 >=20 >=20 > "Key Naming" > ------------------ >=20 > This section discusses aspects of selecting a security associations befor= e > applying protection to signaling messages or to data traffic itself. A ne= w > term ("key naming") was invented to describe this selection of a security > association as part of the work done in the EAP working group. >=20 > To avoid confusion with new terms, a possible definition is included here= : >=20 > Key Naming: "Parameters used to index (=3D to select, or to point to) a > security association in order to protection the corresponding cryptograph= ic > computation. The computation might be applied for inbound and for outboun= d > traffic." >=20 > As a well-known example, IPsec is used to describe the meaning of key > naming. Not that inbound and outbound processing is different. For inbou= nd > processing an IPsec SA is selected using the destination IP address, SPI = and > protocol type (ESP, AH). > For outbound processing the IPsec SA is selected based on the installed > policies which highly differ from environment to environment. A typical > policy might protect all traffic between a source IP address and a given > destination IP address. The applicable policy then points to the IPsec SA > that has to be applied. In some cases even more than one IPsec SA might b= e > applied. >=20 >> From this example it can easily be seen that key naming has to consider > inbound and outbound processing separately for most protocols. >=20 > Section 3.5 of [EAP-KEYING] describes the following key names: >=20 > "EAP SA name: > The EAP security association is uniquely named with server name, EAP Method Type, EAP peer nonce, EAP server nonce>." >=20 > Please note that the EAP SA is created as a result of a full EAP protocol > run between the EAP peer and EAP server. It is for further study why an E= AP > SA needs to be named. >=20 > "AAA-Key Name: > The AAA-Key is named by the concatenation of the EAP SA name, "AAA-Key" a= nd > the authenticator name." >=20 > For PANA the key naming of the EAP SA is not of interest here. The > definition of the AAA-Key name sounds like an input for a key derivation > function rather than information to select a security association. The PA= NA > SA name which should be equivalent to the AAA-Key name is selected as > follows: >=20 > Inbound processing: > The PAA is able to select the PANA security association of an incoming > signaling message based on the session identifier. > The PaC is able to select the PANA SA of an incoming signaling message al= so > based on the session identifier included in the header of the PANA signal= ing > message. >=20 > Note that in both cases it would be possible to use the socket pair for t= he > same purpose. >=20 > Outbound processing: > For outbound processing at the PAA the socket is used to determine where = to > send the message. The socket is selected either based on a reply which is > pending or based on information from the AAA infrastructure. State must b= e > stored to bind a message arriving from the PaC (e.g., an EAP payload in t= he > PANA-Auth-Answer message) and the EAP message send to the EAP server via = the > AAA infrastructure. >=20 > TBD: What information elements are used here exactly to provide these > multiplexing capabilities? >=20 > For outbound processing at the PaC we have to consider a case where the P= aC > is equipped with multiple interfaces and hence has to select the correct > one. At the end a socket is used to select which interface to send the > messages but to deal with IP address changes at the interfaces the Sessio= n > Identifier is used to as an intermediate pointer. Furthermore, policies > determine at which interface a message needs to be send in general (e.g., > reauthentication or an incoming request from the PAA which requires a > response). I'm not sure if there is anything specific to PANA in here. These sound lik= e general "how to send a UDP packet to peer" issues. >=20 > ----- >=20 > FOR DISCUSSION: If the PaC has to run a new re-authentication step then a > new EAP SA is created. As a consequence a new key for the PANA SA is > created. This is at least true for a full EAP protocol run (but it might = not > be true for a "fast resume" since the desired properties have not been > described yet). I presume you are referring to the fast resume features in "EAP methods"? >From PANA perspective, whether it is fast resume or not, it will just look like "running EAP". >=20 > If two PANA SAs (with overlapping lifetime) exist in parallel then you ne= ed > a way to identify which SA to select. Two mechanisms are possible: > - A key version number as in Kerberos which is increased and allows to > select the refer to the latest version of the key. For the purpose of key > naming both values, the session identifier and the key version number, wo= uld > be required. > - A new identifier (e.g., SPI) such as in IPsec which itself has no order= ing > property. Additionally the lifetime of the security association is requir= ed > to determine the most recent one. >=20 > Based on this, the following procedure is necessary to see whether > - Is this a problem in PANA itself? > - Is this a problem for PANA-IPsec handling? > - If so, then which approach should be chosen in PANA: > a) key version number > b) modification of the identifier (the session identifier in our case); > This could mean that a new session identifier is created once a new key i= s > available. >=20 > ----- >=20 > For other protocols (such as IKE) rekeying turned out to be complex with = a > number of failure cases. For IPsec SAs rekeying considerations are > dealt-with in IKE/IKEv2 itself. PANA, however, needs to make sure that bo= th > views of the world are consistent based on the unreliable channel provide= d > with UDP=20 UDP itself is unreliable, but we have the ack mechanism for the Bind messages. > (and the various error cases of the different protocols). It should > not be possible to create a protocol sequence whereby the PaC and the PAA > established different state. >=20 > Please note that the usage of the session identifier in the PANA protocol= is > different from the one in PANA-IPsec handling. Can you please elaborate, what kind of differences are you referring to. > The session identifier > shipped to the EP mainly helps to associate the established PANA session > (and therefore the EAP authentication and authorization) to the accountin= g > mechanisms at the EP. >=20 > TBD: What mechanisms are available in IKE to indicate different keys? Tak= e a > look at the PANA IPsec draft. IKE itself does not address different versi= ons > of the pre-shared secret. The API used by IKE/IKEv2 must be able to provi= de > this functionality. >=20 > EAP Keying requirements > ------------------------------- >=20 > Section 4.2.3 of [EAP-KEYING] lists a few requirements which have to be m= et > by the protocols using EAP. We will briefly list the requirements and > mention whether we believe that the individual requirement is met. Beyond > the requirements listed below a number of other requirements are discusse= d > in [EAP-KEYING] which are also relevant for PANA, such as AAA and EAP met= hod > requirements. >=20 > - Mutual proof of possession >=20 > PANA provides mutual proof of possession (i.e., mutual key confirmation) = of > a key derived from the AAA-Key (or more precisely from the MSK which is > transported to the PAA via the AAA infrastructure). >=20 > - Key Naming >=20 > Every protocol provides mechanisms to select the security associations. P= ANA > should be/is no different here. A previous section discusses some of the > issues which need to be addressed with regard to key naming and different > versions of the key. >=20 > - Creation and Deletion >=20 > This requirement mainly addresses the creation and deletion of phase 2 > security associations. [EAP-KEYING] tightly binds the successful executio= n > of phase 2 with security associations for securing the data traffic. This > is, however, not the case in PANA since these are separate protocols. I didn't understand this one. What exactly are you referring to as "separat= e protocols?" > Some > questions have been raised in this context in previous sections. Deletion= of > the IPsec SAs MUST be accomplished indirectly with a PANA termination > message. >=20 > - Integrity and Replay Protection >=20 > Once the EAP exchange is successfully finished PANA signaling messages ca= n > be integrity and replay protected. >=20 > - Direct operation >=20 > This requirement is highly tight to the IEEE environment where a link lay= er > security associations are established. Hence the requirement is made that > the protocol must only run between these two entities and not between oth= er > parties. >=20 > For PANA this is, however, not the case since the EP might be physically > separated and hence it is required to transfer derived keys to the EP. Th= e > transfer is controlled by the PAA and hence it is not possible by an > unauthorized entity to query the PAA for keys. > Furthermore, the IPsec SA and the IKE-SA/ISAKMP SA is not available to th= e > PAA itself. >=20 > - Derivation of transient session keys >=20 > In case of PANA the PANA protocol itself does not establish the IPsec SAs > directly. >=20 > - TSK freshness >=20 > As mentioned in the previous section PANA itself does not derive unicast > (and multicast) transient session keys. IPsec is responsible for this > purpose and provides these capabilities. IPsec SAs can be reestablished > independently of a PANA protocol. >=20 > - Bi-directional operation >=20 > This requirement addresses the establishment of uni-directional security > associations for protection of data traffic. Again, this requirement is n= ot > directly applicable to PANA. IKE/IKEv2, however, establishes two separate > uni-lateral security associations. >=20 > - Secure capabilities negotiation >=20 > PANA does not negotiate capabilities during phase 0. However, some form o= f > limited capability negotiation takes place secured with the PANA exchange= . > Cipher suites are not negotiated in PANA. >=20 > References > ------------- >=20 > [EAP-KEYING] B. Aboba, D. Simon, J. Arkko and H. Levkowetz: "EAP Key > Management Framework", , (work in progress)= , > October, 2003. >=20 > [PANA-IPsec] M. Parthasarathy: =93PANA enabling IPsec based Access Contr= ol =93, > , (work in progress), October 2003. Thanks. Alper =20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 12 18:36:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29656 for ; Mon, 12 Jan 2004 18:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBbG-0001m4-7g for pana-archive@odin.ietf.org; Mon, 12 Jan 2004 18:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CNa2Ja006816 for pana-archive@odin.ietf.org; Mon, 12 Jan 2004 18:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBbG-0001lq-33 for pana-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 18:36:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29649 for ; Mon, 12 Jan 2004 18:35:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBbD-0001Tr-00 for pana-web-archive@ietf.org; Mon, 12 Jan 2004 18:35:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBZJ-0001RY-00 for pana-web-archive@ietf.org; Mon, 12 Jan 2004 18:34:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgBYL-0001Pg-00 for pana-web-archive@ietf.org; Mon, 12 Jan 2004 18:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBYK-0001hW-FI; Mon, 12 Jan 2004 18:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgBXQ-0001gN-UY for pana@optimus.ietf.org; Mon, 12 Jan 2004 18:32:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29473 for ; Mon, 12 Jan 2004 18:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgBXN-0001NR-00 for pana@ietf.org; Mon, 12 Jan 2004 18:32:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgBVa-0001JX-00 for pana@ietf.org; Mon, 12 Jan 2004 18:30:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AgBTq-0001FE-00 for pana@ietf.org; Mon, 12 Jan 2004 18:28:22 -0500 Date: Mon, 12 Jan 2004 15:28:11 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Hannes Tschofenig CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Hannes, Thank you for this analysis! This is a very useful material for having this discussion... Please see my inlined comments below. > hi all, >=20 > an interesting issue with a relationship to the EAP keying work was raise= d. > i have tried (in this first shot) to write a short text on the EAP keying > issues as they appear in PANA. >=20 > this text also includes some discussion parts where further input is > required (denoted as FOR DISCUSSION). >=20 > ciao > hannes >=20 > ------------- >=20 > Protocol Communication Overview > ------------------------------------------- >=20 > This section discusses EAP keying issues and is therefore strongly aligne= d > with Section 1.3 of [EAP-Keying]. There the entire EAP communication is > separated into three steps. Note that the first step is actually not part= of > EAP itself. >=20 > - Discovery phase (phase 0) > - EAP authentication, key derivation and transport (phase 1) > - Unicast security association establishment (phase 2) >=20 > The discovery phase in PANA has the goal to find the PAA in the visited > network. This step is very hard to secure in a roaming environment. In ma= ny > cases an additional security protection at this step would add denial of > service vulnerabilities. However, to prevent very basic denial of service > attacks, whereby an adversary floods the PAA with bogus requests, a cooki= e > exchange is used. In PANA no capability discovery takes place at phase 0. >=20 > Phase 1 is subdivided into two phases: Phase 1a and phase 1b. In phase 1a > the PAA starts sending the initial EAP packet and thereby initiates the > authentication procedure. The PAA might implement some EAP methods or in > many cases not even a single one - it acts as a passthrough device which > interacts with a backend authentication server. >=20 > EAP methods might provide key derivation and mutual authentication. PANA > leaves the choice to network architects which EAP methods to mandate. Thi= s > is necessary to fullfil the requirements of the larger number of deployme= nt > scenarios. In case of wireless networks without physical or link layer > security the suggestions of [EAP-KEYING] with regard to EAP methods shoul= d > be followed. Methods which provide session key establishment and mutual > authentication are mandated. >=20 > Since the key derivation takes place between the EAP peer and the EAP ser= ver > it is (in many cases) necessary to transport the keying material from the > EAP server to the Authenticator (which corresponds to the PAA in PANA). T= his > step is referred as phase 1b. If the EAP server and the Authenticator are > co-located then this step is replaced by an API call. >=20 > Since PANA signaling messages need protection a PANA SA needs to be > established between the PaC and the PAA The PANA SA is needed to provide the keys for the so-called phase 2. While we have this SA, we thought we can also use it for securing the subsequent PANA exchanges. Though, it is not a requirement that PANA, as a EAP lower layer, needs this kind of protection. > whereby new keying material needs to > be derived from the key provided by the EAP method. This step is a slight > deviation from IEEE 802.1X since PANA does not automatically create secur= ity > associations for data traffic protection. 802.1X does not either. It's the 4-way handshake of 802.11i that creates this SA. > With the help of EAP session keys are in place and PANA needs to create, > delete and update the parameters of the PANA SA. >=20 > PANA makes a more fine-grain separation in phase 2. Parts of phase 2a are > accomplished within PANA and some parts are delegated towards IKE if IPse= c > SA establishment is desired (see [PANA-IPsec]). Phase 2b does not exist i= n > PANA. We will address the differences in more details in this section. >=20 > Figure 1 shows the communication overview. The figure is taken from > [EAP-Keying] and modified accordingly. The "Unicast Secure association > (phase 2a)" is replaced by the abstract term PANA Phase 2 to avoid a > terminology confusion. >=20 >=20 > EAP peer/PaC Authenticator/PAA Auth. Server > ------------ ----------------- ------------ > |<----------------------------->| | > | Discovery (phase 0) | | > |<----------------------------->|<----------------------------->| > | EAP auth (phase 1a) | AAA pass-through (optional) | > | | | > | |<----------------------------->| > | | AAA-Key transport | > | | (optional; phase 1b) | > |<----------------------------->| | > | PANA Phase 2 | | > | | | > |<----------------------------->| | > | IKE/IPsec SA establishment | | > | (optional) | | > | | | I didn't understand why we have "PANA phase 2". Normally PANA should not "leak into" phase 2. Phase 2 is for IKE (or, in the case of 802.1X-based systems, 4-way handshake) >=20 > Figure 1: Communication Overview >=20 > Figure 1 ignores the fact that the Authenticator/PAA can physically be > separated from the Enforcement Point (EP). In this case IKE would not run > between the PaC and the PAA. >=20 > Phase 2 is executed after a successful EAP exchange in phase 1 (including > the transport of keying material to the Authenticator). >=20 > This phase accomplishes the following tasks (compared with the list > described in Section 1.3 of [EAP-KEYING]): >=20 > - Since PANA does not negotiate parameters during the discovery phase it = is > not possible to confirm them. No cipher suite negotiation takes place in > PANA. >=20 > - PANA securely provides an exchange of parameters and usage modes as par= t > of the PANA-Bind-Request message (such as Device-Id, Lifetime, > Protection-Cap AVPs). >=20 > - PANA does not derive further session keys for protection of data traffi= c. > If an IPsec has to be established then IKE or IKEv2 is used. >=20 > - Mutual key confirmation (PAA to PaC with the help of the PANA-Bind-Requ= est > and PaC to PAA with the help of the PANA-Bind-Answer message) is provided= . > This ensure that both, the PaC and the PAA, successfully executed EAP and= , > in the case of the PAA, were able to create the necessary keys and parame= ter > for the PANA SA. >=20 > - The PANA SA is active immediately after the PANA SA is established (i.e= ., > after the EAP method was successfully executed and session keys are > available). >=20 > - PANA also offers a mechanism for terminating access and to delete the > established state with the help of the PANA-Termination-Request and > PANA-Termination-Answer message. Without sending such a message the PAA a= nd > the PaC delete their established state after lifetime expiration. >=20 > Security Associations > -------------------------- >=20 > Several different security associations are created as part of the PANA > exchange. We will describe of them in some level of detail whereby some P= ANA > specific aspects might lead to discussions. >=20 > - EAP SA >=20 > First, there is the EAP SA which is described in Section 3.1 of > [EAP-KEYING]. Due to the nature of EAP there are some restrictions on the > EAP SA such as the missing lifetime negotiation, no SA delete operation e= tc. > Some EAP methods provide enhanced functionality by establishing additiona= l > state which is subject to special optimizations such as "fast resume". A > detailed discussion of these issues is beyond the scope of PANA. >=20 > - AAA-Key SA / PANA SA >=20 > The AAA-Key SA described in Section 3.2 of [EAP-KEYING] seems to be the > counterpart of the PANA SA. This security association exists between the = PaC > and the PAA. The following parameters constitute this AAA-Key SA: >=20 > - the EAP peer name > - the NAS/authenticator name > - the AAA-Key > - the AAA-Key maximum lifetime (if known) > - the AAA attributes sent in the Access-Accept >=20 > The subsequent paragraph is an attempt to map the text in [EAP-KEYING] to > PANA. >=20 > For the PANA-SA at the PAA would have the following parameters: > - AAA attributes (obtained via the Access-Accept) > - Lifetime (optional?) > - Key of the PANA SA (derived from the AAA-Key) > - Socket-Pair information (Src/Dst IP address, Src/Port, UDP protocol) We don't really deal with "sockets" context in the PANA design. Instead, I think we can refer to the "device IDs" in here. > - Session ID > The PANA-SA at the PaC contains similar attributes except for the AAA > attributes since they are invisible to the PaC. >=20 > The lifetime of the PANA SA is determined by a number of parameters. The > Lifetime AVP transmitted to the PaC is an indication for the PaC about th= e > time duration granted for network access (and therefore also for the > lifetime of the security association). >=20 > The identities used for the PaC and the PAA are less clearly described in > PANA (and also in the EAP context). Some of these issues will be discusse= d > again in the context of "key naming". >=20 > The identity of the NAS (in the IEEE context) or PAA (in PANA) has to be > mapped to attributes in the AAA infrastructure. Hence, within RADIUS the = NAS > is identified by the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address > attributes. Although these attributes are kept very flexible it needs to = be > ensured that they match to the PANA context. >=20 > --- >=20 > FOR DISCUSSION: Should the PANA SA be bound to a specific PaC <-> PAA? Th= is > is particularly of interest for mobility. It needs to be evaluated whethe= r > the discussion in the EAP keying design team (or within the EAP working > group in general) is an issue here or even in general (e.g., a virtual NA= S). PANA SA is bound to a PANA session. >=20 > FOR DISCUSSION: Should a new key be derived after the lifetime of the PAN= A > SA expires (as part of a re-authentication procedure)? This should then > require that the Lifetime AVP is mandatory in order for the PaC to perfor= m > the same computation/protocol action. What protocol interaction is requir= ed > for rekeying? It should be noted that the expiration of the PANA SA lifet= ime > is not necessarily the same as a regular SA expiration. The lifetime refe= rs > more likely to the authorization decision or some other security policy > based aspects of reauthentication interval. A clarification would be > necessary and helpful. When the PANA session expires, if the peers are interested in continuing th= e "access", another run of EAP is executed inside PANA. This should create a new EAP SA, hence a new PANA SA. >=20 > --- >=20 > - Unicast Secure Association SA / IPsec SA >=20 > In [EAP-KEYING] a "unicast secure association SA" seems to be a link laye= r > specific security association which is used to protect the data traffic > itself. In the PANA context the equivalent would be an IPsec SA. In theory, one might choose to enable L2 ciphering after a successful PANA authentication. For example, using the newly generated keys with WPA-PSK. I'm not aware of anyone looking at the details yet though. So, this is another possibility in addition to enabling IPsec-based access control. > Since PANA > IPsec uses IKE or IKEv2, it would be necessary to consider also the state > established with these protocols. >=20 > The content of the "unicast secure association SA" is described as >=20 > - the peer port identifier (Calling-Station-Id) > - the NAS port identifier (Called-Station-Id) > - the unicast Transient Session Keys (TSKs) > - the unicast secure association peer nonce > - the unicast secure association authenticator nonce > - the negotiated unicast capabilities and unicast ciphersuite. >=20 > For PANA IPsec usage three SAs are of relevance: > - PANA-IKE-SA > - IKE-SA/ISAKMP SA > - IPsec SA >=20 > Each of these SAs have different attributes and a different lifetime. >=20 > The content of the IPsec SA and the IKE-SA/ISAKMP SA is described in the > relevant IPsec working group documents and will not be repeated here. >=20 > The PANA-IKE-SA, which is the state information used as input to the IKE = / > IKEv2 exchange, is of interest here. The following information is necessa= ry: So, is this what you are saying: EAP SA -> PANA SA -> PANA-IKE-SA -> IPsec-SA Do we need PANA-IKE-SA, or can we skip it? >=20 > - the PANA-SA derived key (which is indirectly used as a pre-shared > secret for IKE/IKEv2) > - the identities of the PaC (IP address) and EP (also IP address) (both > IP addresses are > made available to both entities during the PANA protocol execution). > - the Session ID >=20 > --- >=20 > FOR DISCUSSION: A key derived from the PANA SA key should be used as inpu= t > to the key derivation function for the IKE preshared secret key and not t= he > MSK. Mutual key confirmation is provided for the PANA SA key. >=20 > --- >=20 >> From authorization point of view it is necessary to ensure that the IPse= c > SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain active after the > PANA context is removed since otherwise network resources could be consum= ed > without authorization. Since the PaC is able to send a terminate message = at > any time there is a need for a good API between the PAA/EP and the IKE/IP= sec > daemon. >=20 > --- >=20 > FOR DISCUSSION: > Should a newly derived key for the PANA SA lead to a new key for the > PANA-IKE SA? My preference is NO. The PaC should, however, be able to > create a new IPsec SA at any time during the lifetime of a PANA SA. > Should the PAA be able to force the PaC to create a new IPsec SA? > Should it be possible to create more than one IPsec SA between the PaC an= d > the EP at the same time (for example to support different quality of serv= ice > classes)? I think this is beyond the scope of PANA design. If PANA provides a shared secret to PaC and EP for generation of an IPsec SA for access control, then its job is done. If someone proposes a design for generating multiple IPsec SAs from a single shared secret for QoS/etc reasons, then they can do so independent of where the shared secret came from. >=20 > --- >=20 >=20 >=20 > "Key Naming" > ------------------ >=20 > This section discusses aspects of selecting a security associations befor= e > applying protection to signaling messages or to data traffic itself. A ne= w > term ("key naming") was invented to describe this selection of a security > association as part of the work done in the EAP working group. >=20 > To avoid confusion with new terms, a possible definition is included here= : >=20 > Key Naming: "Parameters used to index (=3D to select, or to point to) a > security association in order to protection the corresponding cryptograph= ic > computation. The computation might be applied for inbound and for outboun= d > traffic." >=20 > As a well-known example, IPsec is used to describe the meaning of key > naming. Not that inbound and outbound processing is different. For inbou= nd > processing an IPsec SA is selected using the destination IP address, SPI = and > protocol type (ESP, AH). > For outbound processing the IPsec SA is selected based on the installed > policies which highly differ from environment to environment. A typical > policy might protect all traffic between a source IP address and a given > destination IP address. The applicable policy then points to the IPsec SA > that has to be applied. In some cases even more than one IPsec SA might b= e > applied. >=20 >> From this example it can easily be seen that key naming has to consider > inbound and outbound processing separately for most protocols. >=20 > Section 3.5 of [EAP-KEYING] describes the following key names: >=20 > "EAP SA name: > The EAP security association is uniquely named with server name, EAP Method Type, EAP peer nonce, EAP server nonce>." >=20 > Please note that the EAP SA is created as a result of a full EAP protocol > run between the EAP peer and EAP server. It is for further study why an E= AP > SA needs to be named. >=20 > "AAA-Key Name: > The AAA-Key is named by the concatenation of the EAP SA name, "AAA-Key" a= nd > the authenticator name." >=20 > For PANA the key naming of the EAP SA is not of interest here. The > definition of the AAA-Key name sounds like an input for a key derivation > function rather than information to select a security association. The PA= NA > SA name which should be equivalent to the AAA-Key name is selected as > follows: >=20 > Inbound processing: > The PAA is able to select the PANA security association of an incoming > signaling message based on the session identifier. > The PaC is able to select the PANA SA of an incoming signaling message al= so > based on the session identifier included in the header of the PANA signal= ing > message. >=20 > Note that in both cases it would be possible to use the socket pair for t= he > same purpose. >=20 > Outbound processing: > For outbound processing at the PAA the socket is used to determine where = to > send the message. The socket is selected either based on a reply which is > pending or based on information from the AAA infrastructure. State must b= e > stored to bind a message arriving from the PaC (e.g., an EAP payload in t= he > PANA-Auth-Answer message) and the EAP message send to the EAP server via = the > AAA infrastructure. >=20 > TBD: What information elements are used here exactly to provide these > multiplexing capabilities? >=20 > For outbound processing at the PaC we have to consider a case where the P= aC > is equipped with multiple interfaces and hence has to select the correct > one. At the end a socket is used to select which interface to send the > messages but to deal with IP address changes at the interfaces the Sessio= n > Identifier is used to as an intermediate pointer. Furthermore, policies > determine at which interface a message needs to be send in general (e.g., > reauthentication or an incoming request from the PAA which requires a > response). I'm not sure if there is anything specific to PANA in here. These sound lik= e general "how to send a UDP packet to peer" issues. >=20 > ----- >=20 > FOR DISCUSSION: If the PaC has to run a new re-authentication step then a > new EAP SA is created. As a consequence a new key for the PANA SA is > created. This is at least true for a full EAP protocol run (but it might = not > be true for a "fast resume" since the desired properties have not been > described yet). I presume you are referring to the fast resume features in "EAP methods"? >From PANA perspective, whether it is fast resume or not, it will just look like "running EAP". >=20 > If two PANA SAs (with overlapping lifetime) exist in parallel then you ne= ed > a way to identify which SA to select. Two mechanisms are possible: > - A key version number as in Kerberos which is increased and allows to > select the refer to the latest version of the key. For the purpose of key > naming both values, the session identifier and the key version number, wo= uld > be required. > - A new identifier (e.g., SPI) such as in IPsec which itself has no order= ing > property. Additionally the lifetime of the security association is requir= ed > to determine the most recent one. >=20 > Based on this, the following procedure is necessary to see whether > - Is this a problem in PANA itself? > - Is this a problem for PANA-IPsec handling? > - If so, then which approach should be chosen in PANA: > a) key version number > b) modification of the identifier (the session identifier in our case); > This could mean that a new session identifier is created once a new key i= s > available. >=20 > ----- >=20 > For other protocols (such as IKE) rekeying turned out to be complex with = a > number of failure cases. For IPsec SAs rekeying considerations are > dealt-with in IKE/IKEv2 itself. PANA, however, needs to make sure that bo= th > views of the world are consistent based on the unreliable channel provide= d > with UDP=20 UDP itself is unreliable, but we have the ack mechanism for the Bind messages. > (and the various error cases of the different protocols). It should > not be possible to create a protocol sequence whereby the PaC and the PAA > established different state. >=20 > Please note that the usage of the session identifier in the PANA protocol= is > different from the one in PANA-IPsec handling. Can you please elaborate, what kind of differences are you referring to. > The session identifier > shipped to the EP mainly helps to associate the established PANA session > (and therefore the EAP authentication and authorization) to the accountin= g > mechanisms at the EP. >=20 > TBD: What mechanisms are available in IKE to indicate different keys? Tak= e a > look at the PANA IPsec draft. IKE itself does not address different versi= ons > of the pre-shared secret. The API used by IKE/IKEv2 must be able to provi= de > this functionality. >=20 > EAP Keying requirements > ------------------------------- >=20 > Section 4.2.3 of [EAP-KEYING] lists a few requirements which have to be m= et > by the protocols using EAP. We will briefly list the requirements and > mention whether we believe that the individual requirement is met. Beyond > the requirements listed below a number of other requirements are discusse= d > in [EAP-KEYING] which are also relevant for PANA, such as AAA and EAP met= hod > requirements. >=20 > - Mutual proof of possession >=20 > PANA provides mutual proof of possession (i.e., mutual key confirmation) = of > a key derived from the AAA-Key (or more precisely from the MSK which is > transported to the PAA via the AAA infrastructure). >=20 > - Key Naming >=20 > Every protocol provides mechanisms to select the security associations. P= ANA > should be/is no different here. A previous section discusses some of the > issues which need to be addressed with regard to key naming and different > versions of the key. >=20 > - Creation and Deletion >=20 > This requirement mainly addresses the creation and deletion of phase 2 > security associations. [EAP-KEYING] tightly binds the successful executio= n > of phase 2 with security associations for securing the data traffic. This > is, however, not the case in PANA since these are separate protocols. I didn't understand this one. What exactly are you referring to as "separat= e protocols?" > Some > questions have been raised in this context in previous sections. Deletion= of > the IPsec SAs MUST be accomplished indirectly with a PANA termination > message. >=20 > - Integrity and Replay Protection >=20 > Once the EAP exchange is successfully finished PANA signaling messages ca= n > be integrity and replay protected. >=20 > - Direct operation >=20 > This requirement is highly tight to the IEEE environment where a link lay= er > security associations are established. Hence the requirement is made that > the protocol must only run between these two entities and not between oth= er > parties. >=20 > For PANA this is, however, not the case since the EP might be physically > separated and hence it is required to transfer derived keys to the EP. Th= e > transfer is controlled by the PAA and hence it is not possible by an > unauthorized entity to query the PAA for keys. > Furthermore, the IPsec SA and the IKE-SA/ISAKMP SA is not available to th= e > PAA itself. >=20 > - Derivation of transient session keys >=20 > In case of PANA the PANA protocol itself does not establish the IPsec SAs > directly. >=20 > - TSK freshness >=20 > As mentioned in the previous section PANA itself does not derive unicast > (and multicast) transient session keys. IPsec is responsible for this > purpose and provides these capabilities. IPsec SAs can be reestablished > independently of a PANA protocol. >=20 > - Bi-directional operation >=20 > This requirement addresses the establishment of uni-directional security > associations for protection of data traffic. Again, this requirement is n= ot > directly applicable to PANA. IKE/IKEv2, however, establishes two separate > uni-lateral security associations. >=20 > - Secure capabilities negotiation >=20 > PANA does not negotiate capabilities during phase 0. However, some form o= f > limited capability negotiation takes place secured with the PANA exchange= . > Cipher suites are not negotiated in PANA. >=20 > References > ------------- >=20 > [EAP-KEYING] B. Aboba, D. Simon, J. Arkko and H. Levkowetz: "EAP Key > Management Framework", , (work in progress)= , > October, 2003. >=20 > [PANA-IPsec] M. Parthasarathy: =93PANA enabling IPsec based Access Contr= ol =93, > , (work in progress), October 2003. Thanks. Alper =20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 13:08:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00447 for ; Tue, 13 Jan 2004 13:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSxN-0001CF-3P; Tue, 13 Jan 2004 13:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSwT-0000xe-O1 for pana@optimus.ietf.org; Tue, 13 Jan 2004 13:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00147 for ; Tue, 13 Jan 2004 13:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSwQ-0001zQ-00 for pana@ietf.org; Tue, 13 Jan 2004 13:07:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSud-0001is-00 for pana@ietf.org; Tue, 13 Jan 2004 13:05:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgSsV-0001TI-00 for pana@ietf.org; Tue, 13 Jan 2004 13:02:59 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DI2tN9023649 for ; Wed, 14 Jan 2004 03:02:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DI2tKQ014382 for ; Wed, 14 Jan 2004 03:02:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA14381 ; Wed, 14 Jan 2004 03:02:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA05038; Wed, 14 Jan 2004 03:02:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA05041; Wed, 14 Jan 2004 03:02:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DI2r7f016985 for ; Wed, 14 Jan 2004 03:02:53 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRF00F71WSRLO@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 03:02:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgSs5-0004ev-00 for ; Tue, 13 Jan 2004 10:02:33 -0800 Date: Tue, 13 Jan 2004 10:02:33 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040113180233.GO1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] issue 37 (reject?) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I am currently editing pana-03 draft to reflect the resolution for outstanding issues. I am not sure what is the consensus on Issue 37 (Unknown realm problem propagation). Unless there is a strong support, the issue will be rejected. The issue is discussed in: https://www1.ietf.org/mail-archive/working-groups/pana/current/msg00263.html http://www.danforsberg.info:8080/pana-issues/issue37 Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 13:11:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00659 for ; Tue, 13 Jan 2004 13:11:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT02-0001Pm-Dr for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 13:10:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DIAkme005434 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 13:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgT02-0001PZ-Ab for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 13:10:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00639 for ; Tue, 13 Jan 2004 13:10:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgT00-0002J2-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 13:10:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSyQ-0002Cx-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 13:09:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgSxS-000255-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 13:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSxN-0001CF-3P; Tue, 13 Jan 2004 13:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgSwT-0000xe-O1 for pana@optimus.ietf.org; Tue, 13 Jan 2004 13:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00147 for ; Tue, 13 Jan 2004 13:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgSwQ-0001zQ-00 for pana@ietf.org; Tue, 13 Jan 2004 13:07:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgSud-0001is-00 for pana@ietf.org; Tue, 13 Jan 2004 13:05:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgSsV-0001TI-00 for pana@ietf.org; Tue, 13 Jan 2004 13:02:59 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DI2tN9023649 for ; Wed, 14 Jan 2004 03:02:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DI2tKQ014382 for ; Wed, 14 Jan 2004 03:02:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA14381 ; Wed, 14 Jan 2004 03:02:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA05038; Wed, 14 Jan 2004 03:02:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA05041; Wed, 14 Jan 2004 03:02:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DI2r7f016985 for ; Wed, 14 Jan 2004 03:02:53 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRF00F71WSRLO@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 03:02:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgSs5-0004ev-00 for ; Tue, 13 Jan 2004 10:02:33 -0800 Date: Tue, 13 Jan 2004 10:02:33 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040113180233.GO1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 37 (reject?) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I am currently editing pana-03 draft to reflect the resolution for outstanding issues. I am not sure what is the consensus on Issue 37 (Unknown realm problem propagation). Unless there is a strong support, the issue will be rejected. The issue is discussed in: https://www1.ietf.org/mail-archive/working-groups/pana/current/msg00263.html http://www.danforsberg.info:8080/pana-issues/issue37 Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 15:53:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12393 for ; Tue, 13 Jan 2004 15:53:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVX3-0002Mm-AS; Tue, 13 Jan 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVW5-0002Ip-70 for pana@optimus.ietf.org; Tue, 13 Jan 2004 15:52:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12321; Tue, 13 Jan 2004 15:51:58 -0500 (EST) Message-Id: <200401132051.PAA12321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pana@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 13 Jan 2004 15:51:58 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-ipsec-01.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : PANA enabling IPsec based Access Control Author(s) : M. Parthasarathy Filename : draft-ietf-pana-ipsec-01.txt Pages : 11 Date : 2004-1-13 The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pana-ipsec-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-pana-ipsec-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: <2004-1-13160100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13160100.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 15:56:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12567 for ; Tue, 13 Jan 2004 15:56:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVaN-0002eg-5r for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 15:56:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DKuR78010202 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 15:56:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVaL-0002eS-Lh for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 15:56:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12517 for ; Tue, 13 Jan 2004 15:56:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgVaK-0004Z4-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 15:56:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgVYS-0004Vj-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 15:54:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgVX7-0004TA-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 15:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVX3-0002Mm-AS; Tue, 13 Jan 2004 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgVW5-0002Ip-70 for pana@optimus.ietf.org; Tue, 13 Jan 2004 15:52:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12321; Tue, 13 Jan 2004 15:51:58 -0500 (EST) Message-Id: <200401132051.PAA12321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pana@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 13 Jan 2004 15:51:58 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-ipsec-01.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : PANA enabling IPsec based Access Control Author(s) : M. Parthasarathy Filename : draft-ietf-pana-ipsec-01.txt Pages : 11 Date : 2004-1-13 The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pana-ipsec-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-pana-ipsec-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: <2004-1-13160100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-13160100.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 17:39:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19134 for ; Tue, 13 Jan 2004 17:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXBd-0007hK-Ee; Tue, 13 Jan 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXAz-0007gO-FF for pana@optimus.ietf.org; Tue, 13 Jan 2004 17:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18955 for ; Tue, 13 Jan 2004 17:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXAw-0003Yu-00 for pana@ietf.org; Tue, 13 Jan 2004 17:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgX94-0003PG-00 for pana@ietf.org; Tue, 13 Jan 2004 17:36:22 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgX7E-0003JB-00 for pana@ietf.org; Tue, 13 Jan 2004 17:34:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DMYRN9002962 for ; Wed, 14 Jan 2004 07:34:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DMYRR2016147 for ; Wed, 14 Jan 2004 07:34:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16146 ; Wed, 14 Jan 2004 07:34:27 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA15922; Wed, 14 Jan 2004 07:34:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA27501; Wed, 14 Jan 2004 07:34:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DMYP7f008354 for ; Wed, 14 Jan 2004 07:34:25 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG000KO9DC0A@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 07:34:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgX3w-0005KI-00 for ; Tue, 13 Jan 2004 14:31:04 -0800 Date: Tue, 13 Jan 2004 14:31:04 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040113223104.GV1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] pana snapshot Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , The latest PANA specification snapshot (draft-ietf-pana-pana-03a) as well as diff from -02 draft is available at: http://www.toshiba.com/tari/pana/pana-spec.html Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 17:42:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19253 for ; Tue, 13 Jan 2004 17:42:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXEu-00086c-Nb for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 17:42:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DMgOJa031154 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 17:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXEu-00086P-JJ for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 17:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19216 for ; Tue, 13 Jan 2004 17:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXEs-0003l1-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXD1-0003hY-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:40:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgXBe-0003eB-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXBd-0007hK-Ee; Tue, 13 Jan 2004 17:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXAz-0007gO-FF for pana@optimus.ietf.org; Tue, 13 Jan 2004 17:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18955 for ; Tue, 13 Jan 2004 17:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXAw-0003Yu-00 for pana@ietf.org; Tue, 13 Jan 2004 17:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgX94-0003PG-00 for pana@ietf.org; Tue, 13 Jan 2004 17:36:22 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgX7E-0003JB-00 for pana@ietf.org; Tue, 13 Jan 2004 17:34:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DMYRN9002962 for ; Wed, 14 Jan 2004 07:34:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DMYRR2016147 for ; Wed, 14 Jan 2004 07:34:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA16146 ; Wed, 14 Jan 2004 07:34:27 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA15922; Wed, 14 Jan 2004 07:34:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA27501; Wed, 14 Jan 2004 07:34:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DMYP7f008354 for ; Wed, 14 Jan 2004 07:34:25 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG000KO9DC0A@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 07:34:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgX3w-0005KI-00 for ; Tue, 13 Jan 2004 14:31:04 -0800 Date: Tue, 13 Jan 2004 14:31:04 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040113223104.GV1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] pana snapshot Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The latest PANA specification snapshot (draft-ietf-pana-pana-03a) as well as diff from -02 draft is available at: http://www.toshiba.com/tari/pana/pana-spec.html Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 17:49:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19443 for ; Tue, 13 Jan 2004 17:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXLJ-0008Iv-HY; Tue, 13 Jan 2004 17:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXKs-0008IX-Rb for pana@optimus.ietf.org; Tue, 13 Jan 2004 17:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19434 for ; Tue, 13 Jan 2004 17:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXKq-0003zz-00 for pana@ietf.org; Tue, 13 Jan 2004 17:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXJ4-0003xU-00 for pana@ietf.org; Tue, 13 Jan 2004 17:46:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgXIT-0003tz-00 for pana@ietf.org; Tue, 13 Jan 2004 17:46:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DMk4N9006553; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DMk4KL021360; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA21358 ; Wed, 14 Jan 2004 07:46:04 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA19850; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA27233; Wed, 14 Jan 2004 07:46:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DMk27f010638; Wed, 14 Jan 2004 07:46:03 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG000UD9WO0A@tsbpo1.po.toshiba.co.jp>; Wed, 14 Jan 2004 07:46:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgXGE-0005Kp-00; Tue, 13 Jan 2004 14:43:46 -0800 Date: Tue, 13 Jan 2004 14:43:43 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] Unique identifier per session In-reply-to: To: Hannes Tschofenig Cc: Mohan Parthasarathy , "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040113224343.GW1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Hannes Tschofenig , Mohan Parthasarathy , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.4i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Hannes and Mohan, Which type of AVP is needed for PANA to carry the key identifier? How about defining a new Key-Id AVP which is of type Unsigned32 and carried in PANA-Bind-Request message? Does the same AVP need to be carried in the corresponding PANA-Bind-Answer message or can we omit the AVP in the answer message? Yoshihiro Ohba On Tue, Jan 06, 2004 at 09:33:11AM +0100, Hannes Tschofenig wrote: > hi mohan, > hi yoshi, > > i am also in favor of including information into the PANA-Bind-Request > message for this purpose. but i am still not sure whether you need to update > the pre-shared secret for the ike run with every eap "reauthentication" > protocol run.. > instead i would argue that you should not do it. using this approach > you could leave it to the network to trigger a change of the pre-shared > secret. > > ciao > hannes > > > > -----Original Message----- > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > To: Tschofenig Hannes > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > pre-shared secrets > > > > > currently for IKE protocol runs: > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > [ipsec-pana] > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > (session id || > > > > > version number) as a key name. this would ensure that you always > > > > select > > > > the > > > > > > > > What do you mean by version number ? > > > > > > if you have multiple IKE pre-shared secrets concurrently > > then you need > > to > > > have a way to distinguish a more recent key from an older one. > > > additionally you need to indicate this somehow. when entity > > A selects > > > key X then entity B needs to know that X was selected. > > > > > > the key version number could be an integer which is increased by one > > if > > you > > > add a new version of the key. > > > > > How do you propose to exchange this information between PAA > > and PaC ? See the other discussion between me and Yoshihiro. > > Explicit communication seems better. I think this should be > > another AVP. What do you think ? > > > > -mohan > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > fallback > > > > to > > > > > the previous sa. however, this does not work with ike main mode > > > > (pre-shared > > > > > secret authentication) since the ID payload is sent after > > > > authentication > > > > > (with message 5). this already caused problems in road > > > > warrior cases. > > > > > > > > > > from this point of view it would be good to use aggressive mode > > only > > > > (also > > > > > from the number of messages). however, the availability of > > > > aggressive > > > > mode > > > > > in existing implementations is not widespread. > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > aggressive mode MUST be supported because of the problem you > > > > mention above with main-mode. > > > > > > great. > > > > > > ciao > > > hannes > > > > > > > > > > > -mohan > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > To: Mohan Parthasarathy > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > Parthasarathy wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > also > > > > does > > > > > > not > > > > > > > change > > > > > > > > > across a reauthentication. > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > the > > > > > > pre-shared > > > > > > > keys > > > > > > > > > within a sub-session. > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > ID also in > > > > > > > reauth-answer. > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > and hence > > > > > > uniquely > > > > > > > > > identifies the keys derived > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > Session-ID across > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > How about using | as the IKE > > pre-shared > > > > key > > > > > > > > identifier, where N is the number of EAP-based > > > > re-authentications > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > arrived by PaC > > > > > > and > > > > > > > PAA. > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > lost. > > > > > > > 3) PAA retransmits reauth request > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > > successful. > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > that the IKE > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > occurs. When the other type of reauthentication based on > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > IKE > > > > > > pre-shared key needs to be updated because there is no > > > > change in the > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > derivation can be made because PANA-Bind-Request that > > carries an > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > message. > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > From what i > > > > > > can > > > > > > > understand > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > the above > > > > > > looks > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 17:52:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19599 for ; Tue, 13 Jan 2004 17:52:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXOa-0008Rs-W4 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 17:52:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DMqO8A032470 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 17:52:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXOa-0008Rd-QA for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 17:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19549 for ; Tue, 13 Jan 2004 17:52:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXOY-00046v-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:52:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXMh-00043V-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:50:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgXLO-00041N-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 17:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXLJ-0008Iv-HY; Tue, 13 Jan 2004 17:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXKs-0008IX-Rb for pana@optimus.ietf.org; Tue, 13 Jan 2004 17:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19434 for ; Tue, 13 Jan 2004 17:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXKq-0003zz-00 for pana@ietf.org; Tue, 13 Jan 2004 17:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXJ4-0003xU-00 for pana@ietf.org; Tue, 13 Jan 2004 17:46:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgXIT-0003tz-00 for pana@ietf.org; Tue, 13 Jan 2004 17:46:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0DMk4N9006553; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0DMk4KL021360; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA21358 ; Wed, 14 Jan 2004 07:46:04 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA19850; Wed, 14 Jan 2004 07:46:04 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA27233; Wed, 14 Jan 2004 07:46:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0DMk27f010638; Wed, 14 Jan 2004 07:46:03 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG000UD9WO0A@tsbpo1.po.toshiba.co.jp>; Wed, 14 Jan 2004 07:46:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgXGE-0005Kp-00; Tue, 13 Jan 2004 14:43:46 -0800 Date: Tue, 13 Jan 2004 14:43:43 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] Unique identifier per session In-reply-to: To: Hannes Tschofenig Cc: Mohan Parthasarathy , "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040113224343.GW1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Hannes Tschofenig , Mohan Parthasarathy , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.4i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Hannes and Mohan, Which type of AVP is needed for PANA to carry the key identifier? How about defining a new Key-Id AVP which is of type Unsigned32 and carried in PANA-Bind-Request message? Does the same AVP need to be carried in the corresponding PANA-Bind-Answer message or can we omit the AVP in the answer message? Yoshihiro Ohba On Tue, Jan 06, 2004 at 09:33:11AM +0100, Hannes Tschofenig wrote: > hi mohan, > hi yoshi, > > i am also in favor of including information into the PANA-Bind-Request > message for this purpose. but i am still not sure whether you need to update > the pre-shared secret for the ike run with every eap "reauthentication" > protocol run.. > instead i would argue that you should not do it. using this approach > you could leave it to the network to trigger a change of the pre-shared > secret. > > ciao > hannes > > > > -----Original Message----- > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > To: Tschofenig Hannes > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > pre-shared secrets > > > > > currently for IKE protocol runs: > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > [ipsec-pana] > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > (session id || > > > > > version number) as a key name. this would ensure that you always > > > > select > > > > the > > > > > > > > What do you mean by version number ? > > > > > > if you have multiple IKE pre-shared secrets concurrently > > then you need > > to > > > have a way to distinguish a more recent key from an older one. > > > additionally you need to indicate this somehow. when entity > > A selects > > > key X then entity B needs to know that X was selected. > > > > > > the key version number could be an integer which is increased by one > > if > > you > > > add a new version of the key. > > > > > How do you propose to exchange this information between PAA > > and PaC ? See the other discussion between me and Yoshihiro. > > Explicit communication seems better. I think this should be > > another AVP. What do you think ? > > > > -mohan > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > fallback > > > > to > > > > > the previous sa. however, this does not work with ike main mode > > > > (pre-shared > > > > > secret authentication) since the ID payload is sent after > > > > authentication > > > > > (with message 5). this already caused problems in road > > > > warrior cases. > > > > > > > > > > from this point of view it would be good to use aggressive mode > > only > > > > (also > > > > > from the number of messages). however, the availability of > > > > aggressive > > > > mode > > > > > in existing implementations is not widespread. > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > aggressive mode MUST be supported because of the problem you > > > > mention above with main-mode. > > > > > > great. > > > > > > ciao > > > hannes > > > > > > > > > > > -mohan > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > To: Mohan Parthasarathy > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > Parthasarathy wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > also > > > > does > > > > > > not > > > > > > > change > > > > > > > > > across a reauthentication. > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > the > > > > > > pre-shared > > > > > > > keys > > > > > > > > > within a sub-session. > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > ID also in > > > > > > > reauth-answer. > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > and hence > > > > > > uniquely > > > > > > > > > identifies the keys derived > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > Session-ID across > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > How about using | as the IKE > > pre-shared > > > > key > > > > > > > > identifier, where N is the number of EAP-based > > > > re-authentications > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > arrived by PaC > > > > > > and > > > > > > > PAA. > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > lost. > > > > > > > 3) PAA retransmits reauth request > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > message > > > > is > > > > > > > successful. > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > that the IKE > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > occurs. When the other type of reauthentication based on > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > IKE > > > > > > pre-shared key needs to be updated because there is no > > > > change in the > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > derivation can be made because PANA-Bind-Request that > > carries an > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > message. > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > From what i > > > > > > can > > > > > > > understand > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > the above > > > > > > looks > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 18:15:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21401 for ; Tue, 13 Jan 2004 18:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXkV-0001US-P7; Tue, 13 Jan 2004 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXkK-0001Su-1w for pana@optimus.ietf.org; Tue, 13 Jan 2004 18:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21284 for ; Tue, 13 Jan 2004 18:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXkH-0004tL-00 for pana@ietf.org; Tue, 13 Jan 2004 18:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXiO-0004o8-00 for pana@ietf.org; Tue, 13 Jan 2004 18:12:53 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1AgXhE-0004in-00 for pana@ietf.org; Tue, 13 Jan 2004 18:11:40 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 13 Jan 2004 23:11:37 -0000 Message-ID: <01bb01c3da2a$986df350$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Hannes Tschofenig" Cc: References: <20040113224343.GW1777@steelhead> Subject: Re: [Pana] Unique identifier per session Date: Tue, 13 Jan 2004 15:11:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yoshihiro, > Hi Hannes and Mohan, > > Which type of AVP is needed for PANA to carry the key identifier? How > about defining a new Key-Id AVP which is of type Unsigned32 and unsigned32 seems good. > carried in PANA-Bind-Request message? Does the same AVP need to be > carried in the corresponding PANA-Bind-Answer message or can we omit > the AVP in the answer message? > PANA-Bind-Answer message contains the session-id and it might make sense to send the Key-ID also. -mohan > Yoshihiro Ohba > > > On Tue, Jan 06, 2004 at 09:33:11AM +0100, Hannes Tschofenig wrote: > > hi mohan, > > hi yoshi, > > > > i am also in favor of including information into the PANA-Bind-Request > > message for this purpose. but i am still not sure whether you need to update > > the pre-shared secret for the ike run with every eap "reauthentication" > > protocol run.. > > instead i would argue that you should not do it. using this approach > > you could leave it to the network to trigger a change of the pre-shared > > secret. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > > To: Tschofenig Hannes > > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > > pre-shared secrets > > > > > > currently for IKE protocol runs: > > > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > > [ipsec-pana] > > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > > (session id || > > > > > > version number) as a key name. this would ensure that you always > > > > > select > > > > > the > > > > > > > > > > What do you mean by version number ? > > > > > > > > if you have multiple IKE pre-shared secrets concurrently > > > then you need > > > to > > > > have a way to distinguish a more recent key from an older one. > > > > additionally you need to indicate this somehow. when entity > > > A selects > > > > key X then entity B needs to know that X was selected. > > > > > > > > the key version number could be an integer which is increased by one > > > if > > > you > > > > add a new version of the key. > > > > > > > How do you propose to exchange this information between PAA > > > and PaC ? See the other discussion between me and Yoshihiro. > > > Explicit communication seems better. I think this should be > > > another AVP. What do you think ? > > > > > > -mohan > > > > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > > fallback > > > > > to > > > > > > the previous sa. however, this does not work with ike main mode > > > > > (pre-shared > > > > > > secret authentication) since the ID payload is sent after > > > > > authentication > > > > > > (with message 5). this already caused problems in road > > > > > warrior cases. > > > > > > > > > > > > from this point of view it would be good to use aggressive mode > > > only > > > > > (also > > > > > > from the number of messages). however, the availability of > > > > > aggressive > > > > > mode > > > > > > in existing implementations is not widespread. > > > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > > aggressive mode MUST be supported because of the problem you > > > > > mention above with main-mode. > > > > > > > > great. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > -mohan > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > > To: Mohan Parthasarathy > > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > > Parthasarathy wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > > also > > > > > does > > > > > > > not > > > > > > > > change > > > > > > > > > > across a reauthentication. > > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > > the > > > > > > > pre-shared > > > > > > > > keys > > > > > > > > > > within a sub-session. > > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > > ID also in > > > > > > > > reauth-answer. > > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > > and hence > > > > > > > uniquely > > > > > > > > > > identifies the keys derived > > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > > Session-ID across > > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > > > How about using | as the IKE > > > pre-shared > > > > > key > > > > > > > > > identifier, where N is the number of EAP-based > > > > > re-authentications > > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > > arrived by PaC > > > > > > > and > > > > > > > > PAA. > > > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > lost. > > > > > > > > 3) PAA retransmits reauth request > > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > > successful. > > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > > that the IKE > > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > > occurs. When the other type of reauthentication based on > > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > > IKE > > > > > > > pre-shared key needs to be updated because there is no > > > > > change in the > > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > > derivation can be made because PANA-Bind-Request that > > > carries an > > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > > message. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > > From what i > > > > > > > can > > > > > > > > understand > > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > > the above > > > > > > > looks > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Pana mailing list > > > > > > > > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 18:19:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21758 for ; Tue, 13 Jan 2004 18:19:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXoB-0001bt-Jq for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 18:18:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DNIpjK006183 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 18:18:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXoB-0001be-D6 for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 18:18:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21659 for ; Tue, 13 Jan 2004 18:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXo8-0005Cy-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 18:18:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXmD-00052R-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 18:16:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgXkX-0004vx-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 18:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXkV-0001US-P7; Tue, 13 Jan 2004 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgXkK-0001Su-1w for pana@optimus.ietf.org; Tue, 13 Jan 2004 18:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21284 for ; Tue, 13 Jan 2004 18:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgXkH-0004tL-00 for pana@ietf.org; Tue, 13 Jan 2004 18:14:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgXiO-0004o8-00 for pana@ietf.org; Tue, 13 Jan 2004 18:12:53 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1AgXhE-0004in-00 for pana@ietf.org; Tue, 13 Jan 2004 18:11:40 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 13 Jan 2004 23:11:37 -0000 Message-ID: <01bb01c3da2a$986df350$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Hannes Tschofenig" Cc: References: <20040113224343.GW1777@steelhead> Subject: Re: [Pana] Unique identifier per session Date: Tue, 13 Jan 2004 15:11:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yoshihiro, > Hi Hannes and Mohan, > > Which type of AVP is needed for PANA to carry the key identifier? How > about defining a new Key-Id AVP which is of type Unsigned32 and unsigned32 seems good. > carried in PANA-Bind-Request message? Does the same AVP need to be > carried in the corresponding PANA-Bind-Answer message or can we omit > the AVP in the answer message? > PANA-Bind-Answer message contains the session-id and it might make sense to send the Key-ID also. -mohan > Yoshihiro Ohba > > > On Tue, Jan 06, 2004 at 09:33:11AM +0100, Hannes Tschofenig wrote: > > hi mohan, > > hi yoshi, > > > > i am also in favor of including information into the PANA-Bind-Request > > message for this purpose. but i am still not sure whether you need to update > > the pre-shared secret for the ike run with every eap "reauthentication" > > protocol run.. > > instead i would argue that you should not do it. using this approach > > you could leave it to the network to trigger a change of the pre-shared > > secret. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > > To: Tschofenig Hannes > > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > > pre-shared secrets > > > > > > currently for IKE protocol runs: > > > > > > > > > > > > ike does not support this type of scenario easily. as stated in > > > > > [ipsec-pana] > > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > > (session id || > > > > > > version number) as a key name. this would ensure that you always > > > > > select > > > > > the > > > > > > > > > > What do you mean by version number ? > > > > > > > > if you have multiple IKE pre-shared secrets concurrently > > > then you need > > > to > > > > have a way to distinguish a more recent key from an older one. > > > > additionally you need to indicate this somehow. when entity > > > A selects > > > > key X then entity B needs to know that X was selected. > > > > > > > > the key version number could be an integer which is increased by one > > > if > > > you > > > > add a new version of the key. > > > > > > > How do you propose to exchange this information between PAA > > > and PaC ? See the other discussion between me and Yoshihiro. > > > Explicit communication seems better. I think this should be > > > another AVP. What do you think ? > > > > > > -mohan > > > > > > > > > > > > > > most recent key and in case of failures it would be possible to > > > > > fallback > > > > > to > > > > > > the previous sa. however, this does not work with ike main mode > > > > > (pre-shared > > > > > > secret authentication) since the ID payload is sent after > > > > > authentication > > > > > > (with message 5). this already caused problems in road > > > > > warrior cases. > > > > > > > > > > > > from this point of view it would be good to use aggressive mode > > > only > > > > > (also > > > > > > from the number of messages). however, the availability of > > > > > aggressive > > > > > mode > > > > > > in existing implementations is not widespread. > > > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > > aggressive mode MUST be supported because of the problem you > > > > > mention above with main-mode. > > > > > > > > great. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > -mohan > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > > To: Mohan Parthasarathy > > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > > Parthasarathy wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a session. But, it > > > also > > > > > does > > > > > > > not > > > > > > > > change > > > > > > > > > > across a reauthentication. > > > > > > > > > > The PANA-IPsec draft needs something unique to identify > > > the > > > > > > > pre-shared > > > > > > > > keys > > > > > > > > > > within a sub-session. > > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > > ID also in > > > > > > > > reauth-answer. > > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > > and hence > > > > > > > uniquely > > > > > > > > > > identifies the keys derived > > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > > Session-ID across > > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > > > How about using | as the IKE > > > pre-shared > > > > > key > > > > > > > > > identifier, where N is the number of EAP-based > > > > > re-authentications > > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > > arrived by PaC > > > > > > > and > > > > > > > > PAA. > > > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > lost. > > > > > > > > 3) PAA retransmits reauth request > > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > > successful. > > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > > that the IKE > > > > > > > pre-shared key is updated when an EAP-based re-authentication > > > > > > > occurs. When the other type of reauthentication based on > > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think the > > > IKE > > > > > > > pre-shared key needs to be updated because there is no > > > > > change in the > > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > > re-authentication, synchronization on EAP Master Session Key > > > > > > > derivation can be made because PANA-Bind-Request that > > > carries an > > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > > message. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above possible ? > > > > > > > From what i > > > > > > > can > > > > > > > > understand > > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > > the above > > > > > > > looks > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Pana mailing list > > > > > > > > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 13 20:47:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26765 for ; Tue, 13 Jan 2004 20:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aga7Z-0007Re-9T; Tue, 13 Jan 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aga7H-0007Qv-Og for pana@optimus.ietf.org; Tue, 13 Jan 2004 20:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26740 for ; Tue, 13 Jan 2004 20:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aga7F-0002rH-00 for pana@ietf.org; Tue, 13 Jan 2004 20:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aga5d-0002oV-00 for pana@ietf.org; Tue, 13 Jan 2004 20:45:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aga4q-0002kl-00 for pana@ietf.org; Tue, 13 Jan 2004 20:44:13 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0E1i7N9001596 for ; Wed, 14 Jan 2004 10:44:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0E1i6Wv014098 for ; Wed, 14 Jan 2004 10:44:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA14091 ; Wed, 14 Jan 2004 10:44:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA05831; Wed, 14 Jan 2004 10:44:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA19633; Wed, 14 Jan 2004 10:44:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0E1i37f016101 for ; Wed, 14 Jan 2004 10:44:04 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG00J4FI5EWB@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 10:44:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aga3t-0005ht-00 for ; Tue, 13 Jan 2004 17:43:13 -0800 Date: Tue, 13 Jan 2004 17:43:13 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040114014313.GD1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] issue 28 (state machine) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I have non-technical questions about PANA state machines. - Should it be included in the PANA specification draft or described in a separate draft? - What is the format of the diagrams, complex ascii-art, a table of (state, condition/event, action, next state) tuples in ascii text, or having a PostScript (or PDF) versions of draft to include diagrams in picture image? In the third alternative, text version of draft will only have text descriptions about state variables, interface variables and state transition conditions, like the current EAP state machine draft does. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 13 20:51:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27010 for ; Tue, 13 Jan 2004 20:51:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgaB1-0007b7-U6 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 20:50:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0E1oZE8029199 for pana-archive@odin.ietf.org; Tue, 13 Jan 2004 20:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgaB1-0007as-Pg for pana-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 20:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26959 for ; Tue, 13 Jan 2004 20:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgaAz-000327-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 20:50:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aga9I-0002xb-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 20:48:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aga7b-0002to-00 for pana-web-archive@ietf.org; Tue, 13 Jan 2004 20:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aga7Z-0007Re-9T; Tue, 13 Jan 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aga7H-0007Qv-Og for pana@optimus.ietf.org; Tue, 13 Jan 2004 20:46:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26740 for ; Tue, 13 Jan 2004 20:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aga7F-0002rH-00 for pana@ietf.org; Tue, 13 Jan 2004 20:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aga5d-0002oV-00 for pana@ietf.org; Tue, 13 Jan 2004 20:45:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aga4q-0002kl-00 for pana@ietf.org; Tue, 13 Jan 2004 20:44:13 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0E1i7N9001596 for ; Wed, 14 Jan 2004 10:44:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0E1i6Wv014098 for ; Wed, 14 Jan 2004 10:44:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA14091 ; Wed, 14 Jan 2004 10:44:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA05831; Wed, 14 Jan 2004 10:44:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA19633; Wed, 14 Jan 2004 10:44:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0E1i37f016101 for ; Wed, 14 Jan 2004 10:44:04 +0900 (JST) Received: from steelhead ([159.119.168.127]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRG00J4FI5EWB@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 14 Jan 2004 10:44:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aga3t-0005ht-00 for ; Tue, 13 Jan 2004 17:43:13 -0800 Date: Tue, 13 Jan 2004 17:43:13 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040114014313.GD1777@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 28 (state machine) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I have non-technical questions about PANA state machines. - Should it be included in the PANA specification draft or described in a separate draft? - What is the format of the diagrams, complex ascii-art, a table of (state, condition/event, action, next state) tuples in ascii text, or having a PostScript (or PDF) versions of draft to include diagrams in picture image? In the third alternative, text version of draft will only have text descriptions about state variables, interface variables and state transition conditions, like the current EAP state machine draft does. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 09:17:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19744 for ; Wed, 14 Jan 2004 09:17:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglpP-0001H4-Uh; Wed, 14 Jan 2004 09:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglpC-0001FL-1U for pana@optimus.ietf.org; Wed, 14 Jan 2004 09:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19698 for ; Wed, 14 Jan 2004 09:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aglp5-0005XN-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aglp1-0005WK-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:40 -0500 Received: from [168.144.1.60] (helo=relay2.softcomca.com) by ietf-mx with esmtp (Exim 4.12) id 1Aglor-0005Oy-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:30 -0500 Received: from M2W044.mail2web.com ([168.144.251.150]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 09:15:52 -0500 Message-ID: <57050-220041314141553116@M2W044.mail2web.com> X-Priority: 3 Reply-To: vfajardo@optonline.net X-Originating-IP: 207.3.232.158 X-URL: http://mail2web.com/ From: "vfajardo@optonline.net" To: yohba@tari.toshiba.com, pana@ietf.org Subject: Re: [Pana] issue 28 (state machine) Date: Wed, 14 Jan 2004 09:15:53 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 14 Jan 2004 14:15:52.0992 (UTC) FILETIME=[EB157A00:01C3DAA8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I have non-technical questions about PANA state machines=2E > > - Should it be included in the PANA specification draft or described > in a separate draft? >From an implementation perspective, the PANA state machine might merit inclusion into the draft itself because it provides a more concise/complet= e depiction of states and message exchanges for all events than the sample scenario of Section 4=2E6 of the draft=2E > > - What is the format of the diagrams, complex ascii-art, a table of > (state, condition/event, action, next state) tuples in ascii text, or > having a PostScript (or PDF) versions of draft to include diagrams in > picture image? In the third alternative, text version of draft will > only have text descriptions about state variables, interface variables > and state transition conditions, like the current EAP state machine > draft does=2E I think your second proposal is best, an ascii state table (with state, condition/event, action, next state) similar to Sec=2E 8=2E1, 8=2E2 etc=2E= of the diameter RFC (rfc3588)=2E A text diagram (or other formats) would be more complex to introduce and would have provided the same amount of informatio= n=2E -- victor fajardo -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 09:18:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19780 for ; Wed, 14 Jan 2004 09:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglqK-0001RY-Gd; Wed, 14 Jan 2004 09:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgldQ-0008Rk-S9 for pana@optimus.ietf.org; Wed, 14 Jan 2004 09:04:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18273 for ; Wed, 14 Jan 2004 09:04:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgldP-0004AS-00 for pana@ietf.org; Wed, 14 Jan 2004 09:04:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aglbc-00048F-00 for pana@ietf.org; Wed, 14 Jan 2004 09:02:49 -0500 Received: from v180.mailsnare.net ([206.246.200.180] helo=mail.mailsnare.net) by ietf-mx with esmtp (Exim 4.12) id 1AglaX-00045Q-00 for pana@ietf.org; Wed, 14 Jan 2004 09:01:41 -0500 Received: from TOSHI2004 (tari-dhcp158.research.telcordia.com [207.3.232.158]) by mail.mailsnare.net (Postfix) with SMTP id 298179720D; Wed, 14 Jan 2004 13:59:45 +0000 (UTC) Message-ID: <006201c3daa6$d8512a10$b19dfea9@TOSHI2004> From: "Victor Fajardo" To: "Yoshihiro Ohba" , References: <20040114014313.GD1777@steelhead> Subject: Re: [Pana] issue 28 (state machine) Date: Wed, 14 Jan 2004 09:01:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by Clam AntiVirus X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I have non-technical questions about PANA state machines. > > - Should it be included in the PANA specification draft or described > in a separate draft? >From an implementation perspective, the PANA state machine might merit inclusion into the draft itself because it provides a more concise/complete depiction of states and message exchanges for all events than the sample scenario of Section 4.6 of the draft. > > - What is the format of the diagrams, complex ascii-art, a table of > (state, condition/event, action, next state) tuples in ascii text, or > having a PostScript (or PDF) versions of draft to include diagrams in > picture image? In the third alternative, text version of draft will > only have text descriptions about state variables, interface variables > and state transition conditions, like the current EAP state machine > draft does. I think your second proposal is best, an ascii state table (with state, condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the diameter RFC (rfc3588). A text diagram (or other formats) would be more complex to introduce and would have provided the same amount of information. -- victor fajardo _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 09:19:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19830 for ; Wed, 14 Jan 2004 09:19:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglrG-0001mn-Mz for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 09:18:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EEIwfc006849 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 09:18:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglrD-0001lF-4u for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 09:18:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19824 for ; Wed, 14 Jan 2004 09:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AglrB-0005aj-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aglq6-0005ZE-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:17:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AglpX-0005Xt-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:17:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglpP-0001H4-Uh; Wed, 14 Jan 2004 09:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglpC-0001FL-1U for pana@optimus.ietf.org; Wed, 14 Jan 2004 09:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19698 for ; Wed, 14 Jan 2004 09:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aglp5-0005XN-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aglp1-0005WK-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:40 -0500 Received: from [168.144.1.60] (helo=relay2.softcomca.com) by ietf-mx with esmtp (Exim 4.12) id 1Aglor-0005Oy-00 for pana@ietf.org; Wed, 14 Jan 2004 09:16:30 -0500 Received: from M2W044.mail2web.com ([168.144.251.150]) by relay2.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Jan 2004 09:15:52 -0500 Message-ID: <57050-220041314141553116@M2W044.mail2web.com> X-Priority: 3 Reply-To: vfajardo@optonline.net X-Originating-IP: 207.3.232.158 X-URL: http://mail2web.com/ From: "vfajardo@optonline.net" To: yohba@tari.toshiba.com, pana@ietf.org Subject: Re: [Pana] issue 28 (state machine) Date: Wed, 14 Jan 2004 09:15:53 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 14 Jan 2004 14:15:52.0992 (UTC) FILETIME=[EB157A00:01C3DAA8] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I have non-technical questions about PANA state machines=2E > > - Should it be included in the PANA specification draft or described > in a separate draft? >From an implementation perspective, the PANA state machine might merit inclusion into the draft itself because it provides a more concise/complet= e depiction of states and message exchanges for all events than the sample scenario of Section 4=2E6 of the draft=2E > > - What is the format of the diagrams, complex ascii-art, a table of > (state, condition/event, action, next state) tuples in ascii text, or > having a PostScript (or PDF) versions of draft to include diagrams in > picture image? In the third alternative, text version of draft will > only have text descriptions about state variables, interface variables > and state transition conditions, like the current EAP state machine > draft does=2E I think your second proposal is best, an ascii state table (with state, condition/event, action, next state) similar to Sec=2E 8=2E1, 8=2E2 etc=2E= of the diameter RFC (rfc3588)=2E A text diagram (or other formats) would be more complex to introduce and would have provided the same amount of informatio= n=2E -- victor fajardo -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 09:20:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19869 for ; Wed, 14 Jan 2004 09:20:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aglrz-0001pl-UG for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 09:19:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EEJhFm007043 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 09:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aglrz-0001pW-QS for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 09:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19851 for ; Wed, 14 Jan 2004 09:19:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aglry-0005cN-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AglrB-0005ap-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:18:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AglqJ-0005ZP-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 09:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AglqK-0001RY-Gd; Wed, 14 Jan 2004 09:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgldQ-0008Rk-S9 for pana@optimus.ietf.org; Wed, 14 Jan 2004 09:04:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18273 for ; Wed, 14 Jan 2004 09:04:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgldP-0004AS-00 for pana@ietf.org; Wed, 14 Jan 2004 09:04:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aglbc-00048F-00 for pana@ietf.org; Wed, 14 Jan 2004 09:02:49 -0500 Received: from v180.mailsnare.net ([206.246.200.180] helo=mail.mailsnare.net) by ietf-mx with esmtp (Exim 4.12) id 1AglaX-00045Q-00 for pana@ietf.org; Wed, 14 Jan 2004 09:01:41 -0500 Received: from TOSHI2004 (tari-dhcp158.research.telcordia.com [207.3.232.158]) by mail.mailsnare.net (Postfix) with SMTP id 298179720D; Wed, 14 Jan 2004 13:59:45 +0000 (UTC) Message-ID: <006201c3daa6$d8512a10$b19dfea9@TOSHI2004> From: "Victor Fajardo" To: "Yoshihiro Ohba" , References: <20040114014313.GD1777@steelhead> Subject: Re: [Pana] issue 28 (state machine) Date: Wed, 14 Jan 2004 09:01:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by Clam AntiVirus Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I have non-technical questions about PANA state machines. > > - Should it be included in the PANA specification draft or described > in a separate draft? >From an implementation perspective, the PANA state machine might merit inclusion into the draft itself because it provides a more concise/complete depiction of states and message exchanges for all events than the sample scenario of Section 4.6 of the draft. > > - What is the format of the diagrams, complex ascii-art, a table of > (state, condition/event, action, next state) tuples in ascii text, or > having a PostScript (or PDF) versions of draft to include diagrams in > picture image? In the third alternative, text version of draft will > only have text descriptions about state variables, interface variables > and state transition conditions, like the current EAP state machine > draft does. I think your second proposal is best, an ascii state table (with state, condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the diameter RFC (rfc3588). A text diagram (or other formats) would be more complex to introduce and would have provided the same amount of information. -- victor fajardo _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 14:40:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05702 for ; Wed, 14 Jan 2004 14:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqqy-0003DN-UO; Wed, 14 Jan 2004 14:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqqt-0003D3-La for pana@optimus.ietf.org; Wed, 14 Jan 2004 14:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05508 for ; Wed, 14 Jan 2004 14:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqqq-0004W6-00 for pana@ietf.org; Wed, 14 Jan 2004 14:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agqpw-0004Sh-00 for pana@ietf.org; Wed, 14 Jan 2004 14:37:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Agqp9-0004PZ-00 for pana@ietf.org; Wed, 14 Jan 2004 14:37:07 -0500 Date: Wed, 14 Jan 2004 11:36:51 -0800 Subject: Re: [Pana] PAA-2-EP SNMP solution From: Alper Yegin To: , Message-ID: In-Reply-To: <3FFD592F.9080400@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Yacine, I read the draft and I have couple comments. Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). We assume an EP is on the same IP-hop as the PaC. I'd suggest we drop the second part of the text above. We are not going to design the solution where the EP might be multiple hops away. Reading the draft, I couldn't figure out how the "PANA Session ID" and "IKE pre-shared key" are carried in SNMP. Wouldn't we need a MIB for these? [maybe we are inhereting the IKE key one from IPsec MIB, but how about the session ID?] Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 14:41:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05866 for ; Wed, 14 Jan 2004 14:41:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqsw-0003JJ-1l for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 14:41:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EJf1dn012710 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 14:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqsv-0003Io-Kr for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 14:41:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05774 for ; Wed, 14 Jan 2004 14:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqss-0004kH-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 14:40:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agqry-0004e7-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 14:40:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agqr1-0004Xm-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 14:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqqy-0003DN-UO; Wed, 14 Jan 2004 14:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agqqt-0003D3-La for pana@optimus.ietf.org; Wed, 14 Jan 2004 14:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05508 for ; Wed, 14 Jan 2004 14:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agqqq-0004W6-00 for pana@ietf.org; Wed, 14 Jan 2004 14:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agqpw-0004Sh-00 for pana@ietf.org; Wed, 14 Jan 2004 14:37:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Agqp9-0004PZ-00 for pana@ietf.org; Wed, 14 Jan 2004 14:37:07 -0500 Date: Wed, 14 Jan 2004 11:36:51 -0800 Subject: Re: [Pana] PAA-2-EP SNMP solution From: Alper Yegin To: , Message-ID: In-Reply-To: <3FFD592F.9080400@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yacine, I read the draft and I have couple comments. Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). We assume an EP is on the same IP-hop as the PaC. I'd suggest we drop the second part of the text above. We are not going to design the solution where the EP might be multiple hops away. Reading the draft, I couldn't figure out how the "PANA Session ID" and "IKE pre-shared key" are carried in SNMP. Wouldn't we need a MIB for these? [maybe we are inhereting the IKE key one from IPsec MIB, but how about the session ID?] Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 20:10:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24735 for ; Wed, 14 Jan 2004 20:10:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw1K-0004Ph-QF; Wed, 14 Jan 2004 20:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw0Q-0004OZ-6q for pana@optimus.ietf.org; Wed, 14 Jan 2004 20:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24690 for ; Wed, 14 Jan 2004 20:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agw0O-0005Wx-00 for pana@ietf.org; Wed, 14 Jan 2004 20:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgvzX-0005Tu-00 for pana@ietf.org; Wed, 14 Jan 2004 20:08:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Agvya-0005Md-00 for pana@ietf.org; Wed, 14 Jan 2004 20:07:12 -0500 Date: Wed, 14 Jan 2004 17:07:00 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200401132051.PAA12321@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Pana] PANA-IPsec-01 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Mohan, Some comments and questions on the latest draft... In the case of DHCP and IKE, EP can trivially learn the address allocated to the client. I presume you are referring to RFC3456 for DHCP, and configuring IP address within IKEv2 for the latter. You might want to explicitly mention these. In the case of auto-configuration (which includes global address or addresses configured as in [PRIV]), EP may not know the address assigned to the PaC. We should qualify which address we are talking about here. I think it is the inner IP address. Thus, it may not be able to setup the SPD entries appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require slightly a different behavior from IKE in the auto- configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. If there is already an SA for the same address, then the SA request MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry for protecting the subsequent data packets. Does this require any modifications to the IKE protocol, or simply implementation modification is sufficient? The other possibility (in addition to DHCP, IKE, autoconf-based configuration) is the statis IP configuration. I guess its handling will be same as autoconf one? [In that case, would we still use link-local IP address during PANA, or simply use the pre-configured IP address?] As EP and PAA are assumed to be co-located,this might be just an API call. We don't assume that. We just assume EP is co-located with an AR in the IPsec-based access control case. PAA might still be hosted on a separate node. This shouldn't impact the PANA-IPsec design though. IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | Session ID | MSK-ID) I think we should be using PANA SA Key instead of MSK. (or, maybe even another key driven from PANA SA Key??) If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. Are we talking about the inner IP address or the outer (or both)? This should not be a limitation as the link- local address is used only by link-local services e.g. neighbor/router discovery, which uses a different mechanism to protect their traffic. I think we are referring to the SEND problem here. If so, let's give a reference to the current spec. Thanks. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 20:12:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24813 for ; Wed, 14 Jan 2004 20:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw3G-0004Uo-Tn for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 20:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F1C2mf017278 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 20:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw3G-0004Ub-P3 for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 20:12:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24797 for ; Wed, 14 Jan 2004 20:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agw3E-0005dL-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 20:12:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agw2J-0005bN-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 20:11:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agw1L-0005Yt-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 20:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw1K-0004Ph-QF; Wed, 14 Jan 2004 20:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agw0Q-0004OZ-6q for pana@optimus.ietf.org; Wed, 14 Jan 2004 20:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24690 for ; Wed, 14 Jan 2004 20:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agw0O-0005Wx-00 for pana@ietf.org; Wed, 14 Jan 2004 20:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgvzX-0005Tu-00 for pana@ietf.org; Wed, 14 Jan 2004 20:08:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Agvya-0005Md-00 for pana@ietf.org; Wed, 14 Jan 2004 20:07:12 -0500 Date: Wed, 14 Jan 2004 17:07:00 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200401132051.PAA12321@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] PANA-IPsec-01 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mohan, Some comments and questions on the latest draft... In the case of DHCP and IKE, EP can trivially learn the address allocated to the client. I presume you are referring to RFC3456 for DHCP, and configuring IP address within IKEv2 for the latter. You might want to explicitly mention these. In the case of auto-configuration (which includes global address or addresses configured as in [PRIV]), EP may not know the address assigned to the PaC. We should qualify which address we are talking about here. I think it is the inner IP address. Thus, it may not be able to setup the SPD entries appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require slightly a different behavior from IKE in the auto- configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. If there is already an SA for the same address, then the SA request MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry for protecting the subsequent data packets. Does this require any modifications to the IKE protocol, or simply implementation modification is sufficient? The other possibility (in addition to DHCP, IKE, autoconf-based configuration) is the statis IP configuration. I guess its handling will be same as autoconf one? [In that case, would we still use link-local IP address during PANA, or simply use the pre-configured IP address?] As EP and PAA are assumed to be co-located,this might be just an API call. We don't assume that. We just assume EP is co-located with an AR in the IPsec-based access control case. PAA might still be hosted on a separate node. This shouldn't impact the PANA-IPsec design though. IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | Session ID | MSK-ID) I think we should be using PANA SA Key instead of MSK. (or, maybe even another key driven from PANA SA Key??) If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. Are we talking about the inner IP address or the outer (or both)? This should not be a limitation as the link- local address is used only by link-local services e.g. neighbor/router discovery, which uses a different mechanism to protect their traffic. I think we are referring to the SEND problem here. If so, let's give a reference to the current spec. Thanks. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 21:35:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27226 for ; Wed, 14 Jan 2004 21:35:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxLb-0000nZ-9p; Wed, 14 Jan 2004 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxKj-0000lr-Fe for pana@optimus.ietf.org; Wed, 14 Jan 2004 21:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27176 for ; Wed, 14 Jan 2004 21:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxKg-0000GA-00 for pana@ietf.org; Wed, 14 Jan 2004 21:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxJn-0000Dt-00 for pana@ietf.org; Wed, 14 Jan 2004 21:33:12 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AgxIy-0000Ab-00 for pana@ietf.org; Wed, 14 Jan 2004 21:32:20 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 15 Jan 2004 02:32:20 -0000 Message-ID: <017e01c3db0f$cd01b760$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: Subject: Re: [Pana] PANA-IPsec-01 Date: Wed, 14 Jan 2004 18:32:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hi Mohan, > > Some comments and questions on the latest draft... > > In the case of DHCP and IKE, EP can trivially learn the address > allocated to the client. > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > within IKEv2 for the latter. You might want to explicitly mention these. > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. > > In the case of auto-configuration > (which includes global address or addresses configured as in > [PRIV]), EP may not know the address assigned to the PaC. > > We should qualify which address we are talking about here. I think it is the > inner IP address. > Okay. I will clarify this. > Thus, > it may not be able to setup the SPD entries appropriately before > IKE exchange starts. As most of the IKE implementations assume > that the SPD can be consulted during the SA negotiation, it may > require slightly a different behavior from IKE in the auto- > configuration case. In the case of auto-configuration, IKE > should be able to setup the SAs for the traffic selectors > specified by the PaC without consulting the SPD entry. If there > is already an SA for the same address, then the SA request MUST > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > authenticates itself successfully, EP should add the SPD entry > for protecting the subsequent data packets. > > Does this require any modifications to the IKE protocol, or simply > implementation modification is sufficient? > Implementation should be sufficient. Racoon seems to have this knob. > The other possibility (in addition to DHCP, IKE, autoconf-based > configuration) is the statis IP configuration. I guess its handling will be > same as autoconf one? [In that case, would we still use link-local IP > address during PANA, or simply use the pre-configured IP address?] > > > As EP and PAA are assumed to be co-located,this might be just an API > call. > > We don't assume that. We just assume EP is co-located with an AR in the > IPsec-based access control case. PAA might still be hosted on a separate > node. This shouldn't impact the PANA-IPsec design though. > Agreed. > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > Session ID | MSK-ID) > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > another key driven from PANA SA Key??) > I have to think more on this to understand the difference. > If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. > > Are we talking about the inner IP address or the outer (or both)? > This is about the inner address. > This should not be a limitation as the link- > local address is used only by link-local services e.g. > neighbor/router discovery, which uses a different mechanism to > protect their traffic. > > I think we are referring to the SEND problem here. If so, let's give a > reference to the current spec. > Okay. -mohan > Thanks. > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 21:37:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27325 for ; Wed, 14 Jan 2004 21:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxNb-0000vK-4i for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 21:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F2b6K3003542 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 21:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxNZ-0000v3-Mf for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 21:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27281 for ; Wed, 14 Jan 2004 21:37:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxNW-0000N7-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 21:37:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxMY-0000KB-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 21:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgxLb-0000II-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 21:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxLb-0000nZ-9p; Wed, 14 Jan 2004 21:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgxKj-0000lr-Fe for pana@optimus.ietf.org; Wed, 14 Jan 2004 21:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27176 for ; Wed, 14 Jan 2004 21:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgxKg-0000GA-00 for pana@ietf.org; Wed, 14 Jan 2004 21:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgxJn-0000Dt-00 for pana@ietf.org; Wed, 14 Jan 2004 21:33:12 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1AgxIy-0000Ab-00 for pana@ietf.org; Wed, 14 Jan 2004 21:32:20 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 15 Jan 2004 02:32:20 -0000 Message-ID: <017e01c3db0f$cd01b760$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: Subject: Re: [Pana] PANA-IPsec-01 Date: Wed, 14 Jan 2004 18:32:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hi Mohan, > > Some comments and questions on the latest draft... > > In the case of DHCP and IKE, EP can trivially learn the address > allocated to the client. > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > within IKEv2 for the latter. You might want to explicitly mention these. > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. > > In the case of auto-configuration > (which includes global address or addresses configured as in > [PRIV]), EP may not know the address assigned to the PaC. > > We should qualify which address we are talking about here. I think it is the > inner IP address. > Okay. I will clarify this. > Thus, > it may not be able to setup the SPD entries appropriately before > IKE exchange starts. As most of the IKE implementations assume > that the SPD can be consulted during the SA negotiation, it may > require slightly a different behavior from IKE in the auto- > configuration case. In the case of auto-configuration, IKE > should be able to setup the SAs for the traffic selectors > specified by the PaC without consulting the SPD entry. If there > is already an SA for the same address, then the SA request MUST > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > authenticates itself successfully, EP should add the SPD entry > for protecting the subsequent data packets. > > Does this require any modifications to the IKE protocol, or simply > implementation modification is sufficient? > Implementation should be sufficient. Racoon seems to have this knob. > The other possibility (in addition to DHCP, IKE, autoconf-based > configuration) is the statis IP configuration. I guess its handling will be > same as autoconf one? [In that case, would we still use link-local IP > address during PANA, or simply use the pre-configured IP address?] > > > As EP and PAA are assumed to be co-located,this might be just an API > call. > > We don't assume that. We just assume EP is co-located with an AR in the > IPsec-based access control case. PAA might still be hosted on a separate > node. This shouldn't impact the PANA-IPsec design though. > Agreed. > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > Session ID | MSK-ID) > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > another key driven from PANA SA Key??) > I have to think more on this to understand the difference. > If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. > > Are we talking about the inner IP address or the outer (or both)? > This is about the inner address. > This should not be a limitation as the link- > local address is used only by link-local services e.g. > neighbor/router discovery, which uses a different mechanism to > protect their traffic. > > I think we are referring to the SEND problem here. If so, let's give a > reference to the current spec. > Okay. -mohan > Thanks. > > Alper > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 14 22:20:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28425 for ; Wed, 14 Jan 2004 22:20:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy39-0003dm-Ce; Wed, 14 Jan 2004 22:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy2H-0003bX-9k for pana@optimus.ietf.org; Wed, 14 Jan 2004 22:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28388 for ; Wed, 14 Jan 2004 22:19:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agy2E-0001jf-00 for pana@ietf.org; Wed, 14 Jan 2004 22:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agy1Q-0001ih-00 for pana@ietf.org; Wed, 14 Jan 2004 22:18:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Agy0y-0001gc-00 for pana@ietf.org; Wed, 14 Jan 2004 22:17:48 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0F3HjN9003252; Thu, 15 Jan 2004 12:17:45 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0F3HiBD010289; Thu, 15 Jan 2004 12:17:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA10286 ; Thu, 15 Jan 2004 12:17:44 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA29388; Thu, 15 Jan 2004 12:17:44 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA13894; Thu, 15 Jan 2004 12:17:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0F3HgXD024707; Thu, 15 Jan 2004 12:17:42 +0900 (JST) Received: from steelhead ([159.119.168.167]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRI0013KH5GGW@tsbpo1.po.toshiba.co.jp>; Thu, 15 Jan 2004 12:17:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgxyJ-0001mG-00; Wed, 14 Jan 2004 19:15:03 -0800 Date: Wed, 14 Jan 2004 19:15:03 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <017e01c3db0f$cd01b760$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040115031503.GC4868@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > Some comments and questions on the latest draft... > > > > In the case of DHCP and IKE, EP can trivially learn the address > > allocated to the client. > > > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > > within IKEv2 for the latter. You might want to explicitly mention these. > > > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. Hmm, I was interpretting the previous sentence differently. 4) PaC configures a link-local address before the PANA protocol begins. At the end of authentication, it either acquires a globally reachable address using [DHCP][DHCPV6] or using IKE or auto-configures an address using stateless auto-configuration [IPV6-ND] if IPv6 is being used. I think "using [DHCP][DHCPV6]" means using DHCP or DHCPv6 before running IKE or IKEv2. "using IKE" (or "using IKE or IKEv2" according to Mohan's above comment) means that running address configuration methods available within IKE or IKEv2 (i.e., by using modecfg or Configuration Payload). "auto-configures an address" means running stateless auto-configuration before running IKE or IKEv2. RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel mode SA). This may be different from any of above three cases, because DHCP SA is created by "using IKE" but DHCP messages are not carried in IKE payloads. > > > > > In the case of auto-configuration > > (which includes global address or addresses configured as in > > [PRIV]), EP may not know the address assigned to the PaC. > > > > We should qualify which address we are talking about here. I think it is the > > inner IP address. > > > Okay. I will clarify this. > > > Thus, > > it may not be able to setup the SPD entries appropriately before > > IKE exchange starts. As most of the IKE implementations assume > > that the SPD can be consulted during the SA negotiation, it may > > require slightly a different behavior from IKE in the auto- > > configuration case. In the case of auto-configuration, IKE > > should be able to setup the SAs for the traffic selectors > > specified by the PaC without consulting the SPD entry. If there > > is already an SA for the same address, then the SA request MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > for protecting the subsequent data packets. > > > > Does this require any modifications to the IKE protocol, or simply > > implementation modification is sufficient? > > > Implementation should be sufficient. Racoon seems to have this knob. What is the probelm in the case of auto-configuration if IKE is not able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry? > > > The other possibility (in addition to DHCP, IKE, autoconf-based > > configuration) is the statis IP configuration. I guess its handling will be > > same as autoconf one? [In that case, would we still use link-local IP > > address during PANA, or simply use the pre-configured IP address?] > > > > > > As EP and PAA are assumed to be co-located,this might be just an API > > call. > > > > We don't assume that. We just assume EP is co-located with an AR in the > > IPsec-based access control case. PAA might still be hosted on a separate > > node. This shouldn't impact the PANA-IPsec design though. > > > Agreed. I agree, too. > > > > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > Session ID | MSK-ID) > > > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > > another key driven from PANA SA Key??) > > > I have to think more on this to understand the difference. The difference would be whether the IKE pre-shared key and PANA SA key becomes cryptographycally separate or not. By using the MSK, the IKE pre-shared key and PANA SA key are cryptographycally indepenent. Unless there is a specific reason for the two keys to be cryptographycally dependent, I think using the MSK is stronger (and better). Yoshihiro Ohba > > > If the PAA does not verify whether PaC is authorized to use an IP > > address, it is possible for the PaC to steal the traffic destined to > > some other PaC. > > > > Are we talking about the inner IP address or the outer (or both)? > > > This is about the inner address. > > > This should not be a limitation as the link- > > local address is used only by link-local services e.g. > > neighbor/router discovery, which uses a different mechanism to > > protect their traffic. > > > > I think we are referring to the SEND problem here. If so, let's give a > > reference to the current spec. > > > Okay. > > -mohan > > > Thanks. > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 14 22:21:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28467 for ; Wed, 14 Jan 2004 22:21:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy4H-0003hu-5R for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 22:21:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F3LDqR014244 for pana-archive@odin.ietf.org; Wed, 14 Jan 2004 22:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy4H-0003hf-0Z for pana-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 22:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28464 for ; Wed, 14 Jan 2004 22:21:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agy4D-0001ng-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 22:21:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agy3I-0001m1-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 22:20:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agy38-0001kZ-00 for pana-web-archive@ietf.org; Wed, 14 Jan 2004 22:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy39-0003dm-Ce; Wed, 14 Jan 2004 22:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agy2H-0003bX-9k for pana@optimus.ietf.org; Wed, 14 Jan 2004 22:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28388 for ; Wed, 14 Jan 2004 22:19:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agy2E-0001jf-00 for pana@ietf.org; Wed, 14 Jan 2004 22:19:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agy1Q-0001ih-00 for pana@ietf.org; Wed, 14 Jan 2004 22:18:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Agy0y-0001gc-00 for pana@ietf.org; Wed, 14 Jan 2004 22:17:48 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0F3HjN9003252; Thu, 15 Jan 2004 12:17:45 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0F3HiBD010289; Thu, 15 Jan 2004 12:17:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA10286 ; Thu, 15 Jan 2004 12:17:44 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA29388; Thu, 15 Jan 2004 12:17:44 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA13894; Thu, 15 Jan 2004 12:17:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0F3HgXD024707; Thu, 15 Jan 2004 12:17:42 +0900 (JST) Received: from steelhead ([159.119.168.167]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRI0013KH5GGW@tsbpo1.po.toshiba.co.jp>; Thu, 15 Jan 2004 12:17:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgxyJ-0001mG-00; Wed, 14 Jan 2004 19:15:03 -0800 Date: Wed, 14 Jan 2004 19:15:03 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <017e01c3db0f$cd01b760$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040115031503.GC4868@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > Some comments and questions on the latest draft... > > > > In the case of DHCP and IKE, EP can trivially learn the address > > allocated to the client. > > > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > > within IKEv2 for the latter. You might want to explicitly mention these. > > > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. Hmm, I was interpretting the previous sentence differently. 4) PaC configures a link-local address before the PANA protocol begins. At the end of authentication, it either acquires a globally reachable address using [DHCP][DHCPV6] or using IKE or auto-configures an address using stateless auto-configuration [IPV6-ND] if IPv6 is being used. I think "using [DHCP][DHCPV6]" means using DHCP or DHCPv6 before running IKE or IKEv2. "using IKE" (or "using IKE or IKEv2" according to Mohan's above comment) means that running address configuration methods available within IKE or IKEv2 (i.e., by using modecfg or Configuration Payload). "auto-configures an address" means running stateless auto-configuration before running IKE or IKEv2. RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel mode SA). This may be different from any of above three cases, because DHCP SA is created by "using IKE" but DHCP messages are not carried in IKE payloads. > > > > > In the case of auto-configuration > > (which includes global address or addresses configured as in > > [PRIV]), EP may not know the address assigned to the PaC. > > > > We should qualify which address we are talking about here. I think it is the > > inner IP address. > > > Okay. I will clarify this. > > > Thus, > > it may not be able to setup the SPD entries appropriately before > > IKE exchange starts. As most of the IKE implementations assume > > that the SPD can be consulted during the SA negotiation, it may > > require slightly a different behavior from IKE in the auto- > > configuration case. In the case of auto-configuration, IKE > > should be able to setup the SAs for the traffic selectors > > specified by the PaC without consulting the SPD entry. If there > > is already an SA for the same address, then the SA request MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > for protecting the subsequent data packets. > > > > Does this require any modifications to the IKE protocol, or simply > > implementation modification is sufficient? > > > Implementation should be sufficient. Racoon seems to have this knob. What is the probelm in the case of auto-configuration if IKE is not able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry? > > > The other possibility (in addition to DHCP, IKE, autoconf-based > > configuration) is the statis IP configuration. I guess its handling will be > > same as autoconf one? [In that case, would we still use link-local IP > > address during PANA, or simply use the pre-configured IP address?] > > > > > > As EP and PAA are assumed to be co-located,this might be just an API > > call. > > > > We don't assume that. We just assume EP is co-located with an AR in the > > IPsec-based access control case. PAA might still be hosted on a separate > > node. This shouldn't impact the PANA-IPsec design though. > > > Agreed. I agree, too. > > > > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > Session ID | MSK-ID) > > > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > > another key driven from PANA SA Key??) > > > I have to think more on this to understand the difference. The difference would be whether the IKE pre-shared key and PANA SA key becomes cryptographycally separate or not. By using the MSK, the IKE pre-shared key and PANA SA key are cryptographycally indepenent. Unless there is a specific reason for the two keys to be cryptographycally dependent, I think using the MSK is stronger (and better). Yoshihiro Ohba > > > If the PAA does not verify whether PaC is authorized to use an IP > > address, it is possible for the PaC to steal the traffic destined to > > some other PaC. > > > > Are we talking about the inner IP address or the outer (or both)? > > > This is about the inner address. > > > This should not be a limitation as the link- > > local address is used only by link-local services e.g. > > neighbor/router discovery, which uses a different mechanism to > > protect their traffic. > > > > I think we are referring to the SEND problem here. If so, let's give a > > reference to the current spec. > > > Okay. > > -mohan > > > Thanks. > > > > Alper > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 00:04:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00727 for ; Thu, 15 Jan 2004 00:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzfl-0007cZ-22; Thu, 15 Jan 2004 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzez-0007c2-Tp for pana@optimus.ietf.org; Thu, 15 Jan 2004 00:03:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00683 for ; Thu, 15 Jan 2004 00:03:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agzex-0004hc-00 for pana@ietf.org; Thu, 15 Jan 2004 00:03:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agze0-0004g3-00 for pana@ietf.org; Thu, 15 Jan 2004 00:02:13 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgzdV-0004ep-00 for pana@ietf.org; Thu, 15 Jan 2004 00:01:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0F51cN9007503; Thu, 15 Jan 2004 14:01:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0F51ceQ012144; Thu, 15 Jan 2004 14:01:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id QAA12141 ; Thu, 15 Jan 2004 14:01:37 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id OAA21498; Thu, 15 Jan 2004 14:01:37 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id OAA18321; Thu, 15 Jan 2004 14:01:27 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0F51PXD004776; Thu, 15 Jan 2004 14:01:26 +0900 (JST) Received: from steelhead ([159.119.168.167]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRI007NKLYCVL@tsbpo1.po.toshiba.co.jp>; Thu, 15 Jan 2004 14:01:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgzbN-0001zj-00; Wed, 14 Jan 2004 20:59:29 -0800 Date: Wed, 14 Jan 2004 20:59:29 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <017e01c3db0f$cd01b760$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040115045929.GB7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Please see my other comments below: On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > specified by the PaC without consulting the SPD entry. If there > > is already an SA for the same address, then the SA request MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > for protecting the subsequent data packets. > > The above text seems to prohibit establishing multiple IPsec SAs between a given pair of PaC and EP. I thought we have previously agreed on allowing multiple IPsec SAs to avoid double IPsec encryption in the corporate VPN case (i.e., creating a separate IPsec SA with null encryption for traffic that carries IPsec'ed packets to the corporate VPN gateway.) Is there any issue for allowing the case? During EAP re-authentication, the MSK changes. Whenever the MSK changes, a new value of MSK-ID is established between the PaC and PAA/EP. If there is already an IKE SA established, it can continue to be used till it expires. A change in the value of MSK need not result in re-negotiating a new IKE SA or IPsec SA immediately. But any new negotiation of IKE SA should use the new pre-shared key derived from the latest MSK and is indicated by the MSK-ID in the above equation. I think the above operation needs be specified by using strict language in order to avoid possible non-interoperable implementations. How about this? : During EAP re-authentication, the MSK changes. Whenever the MSK changes, a new value of MSK-ID is established between the PaC and PAA/EP. If there is already an IKE SA established, it MUST continue to be used till it expires. A change in the value of MSK MUST NOT result in re-negotiating a new IKE SA or IPsec SA immediately. But any new negotiation of IKE SA MUST use the new pre-shared key derived from the latest MSK and is indicated by the MSK-ID in the above equation." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 00:05:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00796 for ; Thu, 15 Jan 2004 00:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzgz-0007h2-TW for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 00:05:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F55HPV029571 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 00:05:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzgz-0007gs-PB for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 00:05:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00791 for ; Thu, 15 Jan 2004 00:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agzgx-0004nJ-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 00:05:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agzg0-0004kS-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 00:04:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Agzfl-0004iU-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 00:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzfl-0007cZ-22; Thu, 15 Jan 2004 00:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agzez-0007c2-Tp for pana@optimus.ietf.org; Thu, 15 Jan 2004 00:03:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00683 for ; Thu, 15 Jan 2004 00:03:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agzex-0004hc-00 for pana@ietf.org; Thu, 15 Jan 2004 00:03:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agze0-0004g3-00 for pana@ietf.org; Thu, 15 Jan 2004 00:02:13 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AgzdV-0004ep-00 for pana@ietf.org; Thu, 15 Jan 2004 00:01:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0F51cN9007503; Thu, 15 Jan 2004 14:01:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0F51ceQ012144; Thu, 15 Jan 2004 14:01:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id QAA12141 ; Thu, 15 Jan 2004 14:01:37 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id OAA21498; Thu, 15 Jan 2004 14:01:37 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id OAA18321; Thu, 15 Jan 2004 14:01:27 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0F51PXD004776; Thu, 15 Jan 2004 14:01:26 +0900 (JST) Received: from steelhead ([159.119.168.167]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRI007NKLYCVL@tsbpo1.po.toshiba.co.jp>; Thu, 15 Jan 2004 14:01:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AgzbN-0001zj-00; Wed, 14 Jan 2004 20:59:29 -0800 Date: Wed, 14 Jan 2004 20:59:29 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <017e01c3db0f$cd01b760$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040115045929.GB7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Please see my other comments below: On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > specified by the PaC without consulting the SPD entry. If there > > is already an SA for the same address, then the SA request MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > for protecting the subsequent data packets. > > The above text seems to prohibit establishing multiple IPsec SAs between a given pair of PaC and EP. I thought we have previously agreed on allowing multiple IPsec SAs to avoid double IPsec encryption in the corporate VPN case (i.e., creating a separate IPsec SA with null encryption for traffic that carries IPsec'ed packets to the corporate VPN gateway.) Is there any issue for allowing the case? During EAP re-authentication, the MSK changes. Whenever the MSK changes, a new value of MSK-ID is established between the PaC and PAA/EP. If there is already an IKE SA established, it can continue to be used till it expires. A change in the value of MSK need not result in re-negotiating a new IKE SA or IPsec SA immediately. But any new negotiation of IKE SA should use the new pre-shared key derived from the latest MSK and is indicated by the MSK-ID in the above equation. I think the above operation needs be specified by using strict language in order to avoid possible non-interoperable implementations. How about this? : During EAP re-authentication, the MSK changes. Whenever the MSK changes, a new value of MSK-ID is established between the PaC and PAA/EP. If there is already an IKE SA established, it MUST continue to be used till it expires. A change in the value of MSK MUST NOT result in re-negotiating a new IKE SA or IPsec SA immediately. But any new negotiation of IKE SA MUST use the new pre-shared key derived from the latest MSK and is indicated by the MSK-ID in the above equation." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 06:18:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27926 for ; Thu, 15 Jan 2004 06:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5Vg-0006ME-Uo; Thu, 15 Jan 2004 06:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5VB-0006L8-Ba for pana@optimus.ietf.org; Thu, 15 Jan 2004 06:17:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27834 for ; Thu, 15 Jan 2004 06:17:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah5V7-0006n2-00 for pana@ietf.org; Thu, 15 Jan 2004 06:17:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah5U7-0006k2-00 for pana@ietf.org; Thu, 15 Jan 2004 06:16:23 -0500 Received: from na5.alcatel.fr ([194.133.58.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Ah5TL-0006gP-00 for pana@ietf.org; Thu, 15 Jan 2004 06:15:35 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i0FBErof032634; Thu, 15 Jan 2004 12:14:53 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004011512145135:3160 ; Thu, 15 Jan 2004 12:14:51 +0100 Message-ID: <4006762B.7060904@alcatel.fr> Date: Thu, 15 Jan 2004 12:14:51 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Alper Yegin CC: pana@ietf.org Subject: Re: [Pana] PAA-2-EP SNMP solution References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/15/2004 12:14:51, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/15/2004 12:14:53, Serialize complete at 01/15/2004 12:14:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hello alper, > Hi Yacine, > > I read the draft and I have couple comments. > > Network access enforcement can be provided by one or more > nodes on the same IP subnet as the client (e.g., multiple routers), > or on another subnet in the access domain (e.g., gateway to the > Internet, depending on the network architecture). > > We assume an EP is on the same IP-hop as the PaC. I'd suggest we drop the > second part of the text above. We are not going to design the solution where > the EP might be multiple hops away. agree. the next version will correct this. > Reading the draft, I couldn't figure out how the "PANA Session ID" and "IKE > pre-shared key" are carried in SNMP. Wouldn't we need a MIB for these? > [maybe we are inhereting the IKE key one from IPsec MIB, but how about the > session ID?] if I remember well (I wrote the ID in november...), it's like you said: the pre-shared key provisioning is done using the IPSEC MIB. and the session id needs to be specified in the PANA-specific extention. anyway, there are some syncrho needed with the lattest version pana-ipsec-01, recntly submitted. > > Thank you. > > Alper thanks, yacine > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 06:20:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28010 for ; Thu, 15 Jan 2004 06:20:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5XG-0006Sp-Qk for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 06:19:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FBJcOV024843 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 06:19:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5XG-0006Sc-Me for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 06:19:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27992 for ; Thu, 15 Jan 2004 06:19:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah5XC-0006xZ-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:19:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah5WK-0006tk-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:18:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah5Vh-0006ph-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5Vg-0006ME-Uo; Thu, 15 Jan 2004 06:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah5VB-0006L8-Ba for pana@optimus.ietf.org; Thu, 15 Jan 2004 06:17:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27834 for ; Thu, 15 Jan 2004 06:17:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah5V7-0006n2-00 for pana@ietf.org; Thu, 15 Jan 2004 06:17:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah5U7-0006k2-00 for pana@ietf.org; Thu, 15 Jan 2004 06:16:23 -0500 Received: from na5.alcatel.fr ([194.133.58.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Ah5TL-0006gP-00 for pana@ietf.org; Thu, 15 Jan 2004 06:15:35 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i0FBErof032634; Thu, 15 Jan 2004 12:14:53 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004011512145135:3160 ; Thu, 15 Jan 2004 12:14:51 +0100 Message-ID: <4006762B.7060904@alcatel.fr> Date: Thu, 15 Jan 2004 12:14:51 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Alper Yegin CC: pana@ietf.org Subject: Re: [Pana] PAA-2-EP SNMP solution References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/15/2004 12:14:51, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 01/15/2004 12:14:53, Serialize complete at 01/15/2004 12:14:53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hello alper, > Hi Yacine, > > I read the draft and I have couple comments. > > Network access enforcement can be provided by one or more > nodes on the same IP subnet as the client (e.g., multiple routers), > or on another subnet in the access domain (e.g., gateway to the > Internet, depending on the network architecture). > > We assume an EP is on the same IP-hop as the PaC. I'd suggest we drop the > second part of the text above. We are not going to design the solution where > the EP might be multiple hops away. agree. the next version will correct this. > Reading the draft, I couldn't figure out how the "PANA Session ID" and "IKE > pre-shared key" are carried in SNMP. Wouldn't we need a MIB for these? > [maybe we are inhereting the IKE key one from IPsec MIB, but how about the > session ID?] if I remember well (I wrote the ID in november...), it's like you said: the pre-shared key provisioning is done using the IPSEC MIB. and the session id needs to be specified in the PANA-specific extention. anyway, there are some syncrho needed with the lattest version pana-ipsec-01, recntly submitted. > > Thank you. > > Alper thanks, yacine > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 06:55:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29327 for ; Thu, 15 Jan 2004 06:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah65V-000877-Mf; Thu, 15 Jan 2004 06:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah64Y-00084w-Pl for pana@optimus.ietf.org; Thu, 15 Jan 2004 06:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29135 for ; Thu, 15 Jan 2004 06:53:58 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah64U-00011i-00 for pana@ietf.org; Thu, 15 Jan 2004 06:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah633-0000lU-00 for pana@ietf.org; Thu, 15 Jan 2004 06:52:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah61B-0000QF-00 for pana@ietf.org; Thu, 15 Jan 2004 06:50:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FBo9Y04307 for ; Thu, 15 Jan 2004 13:50:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 13:50:07 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 13:50:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] Issue37: Unknown realm problem propagation Date: Thu, 15 Jan 2004 13:50:06 +0200 Message-ID: Thread-Topic: [Pana] Issue37: Unknown realm problem propagation Thread-Index: AcO5NUZ2r+5gAalJTa+bgXTaJMjZnAiJwnVw To: , X-OriginalArrivalTime: 15 Jan 2004 11:50:07.0523 (UTC) FILETIME=[B8CA8F30:01C3DB5D] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Should this be clarified in the draft? - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Yoshihiro.Ohba@tais.com > Sent: 03 December, 2003 02:27 > To: pana@ietf.org > Subject: [Pana] Issue37: Unknown realm problem propagation >=20 >=20 >=20 > Several comments were made on Issue 37 in the IETF58 PANA meeting. > Here is the summary: >=20 > - It is possible to propagate the event of AAA message=20 > routing error in > PANA message without need to change AAA protocols. >=20 > - If we take a look at another EAP transport protocol, IEEE=20 > 802.1X does not > carry the AAA message routing error. >=20 > - EAP state machines draft does not define an interface to=20 > propagate the > AAA message routing error to EAP transport protocols. As a=20 > result, if PANA > supports propagation of the AAA error, PAA will need to have a direct > interface to AAA protocols, in addition to the interface to=20 > EAP. This will > complicate implementations. >=20 > I prefer not supporting this type of error message in PANA, from > implementation perspective. >=20 > The issue is described in > http://www.danforsberg.info:8080/pana-issues/issue37 >=20 > Any comments? >=20 > Yoshihiro Ohba >=20 >=20 >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 06:57:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29696 for ; Thu, 15 Jan 2004 06:57:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah67s-0008HP-RB for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 06:57:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FBvSko031821 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 06:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah67s-0008HA-Ml for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 06:57:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29680 for ; Thu, 15 Jan 2004 06:57:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah67o-0001Yd-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:57:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah66p-0001RP-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:56:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah65W-0001DD-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 06:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah65V-000877-Mf; Thu, 15 Jan 2004 06:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah64Y-00084w-Pl for pana@optimus.ietf.org; Thu, 15 Jan 2004 06:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29135 for ; Thu, 15 Jan 2004 06:53:58 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah64U-00011i-00 for pana@ietf.org; Thu, 15 Jan 2004 06:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah633-0000lU-00 for pana@ietf.org; Thu, 15 Jan 2004 06:52:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah61B-0000QF-00 for pana@ietf.org; Thu, 15 Jan 2004 06:50:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FBo9Y04307 for ; Thu, 15 Jan 2004 13:50:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 Jan 2004 13:50:07 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 13:50:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pana] Issue37: Unknown realm problem propagation Date: Thu, 15 Jan 2004 13:50:06 +0200 Message-ID: Thread-Topic: [Pana] Issue37: Unknown realm problem propagation Thread-Index: AcO5NUZ2r+5gAalJTa+bgXTaJMjZnAiJwnVw To: , X-OriginalArrivalTime: 15 Jan 2004 11:50:07.0523 (UTC) FILETIME=[B8CA8F30:01C3DB5D] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Should this be clarified in the draft? - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Yoshihiro.Ohba@tais.com > Sent: 03 December, 2003 02:27 > To: pana@ietf.org > Subject: [Pana] Issue37: Unknown realm problem propagation >=20 >=20 >=20 > Several comments were made on Issue 37 in the IETF58 PANA meeting. > Here is the summary: >=20 > - It is possible to propagate the event of AAA message=20 > routing error in > PANA message without need to change AAA protocols. >=20 > - If we take a look at another EAP transport protocol, IEEE=20 > 802.1X does not > carry the AAA message routing error. >=20 > - EAP state machines draft does not define an interface to=20 > propagate the > AAA message routing error to EAP transport protocols. As a=20 > result, if PANA > supports propagation of the AAA error, PAA will need to have a direct > interface to AAA protocols, in addition to the interface to=20 > EAP. This will > complicate implementations. >=20 > I prefer not supporting this type of error message in PANA, from > implementation perspective. >=20 > The issue is described in > http://www.danforsberg.info:8080/pana-issues/issue37 >=20 > Any comments? >=20 > Yoshihiro Ohba >=20 >=20 >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 07:42:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01568 for ; Thu, 15 Jan 2004 07:42:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6oz-00032i-Hq; Thu, 15 Jan 2004 07:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6ow-00031p-Vi for pana@optimus.ietf.org; Thu, 15 Jan 2004 07:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01550 for ; Thu, 15 Jan 2004 07:41:52 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6om-00043p-00 for pana@ietf.org; Thu, 15 Jan 2004 07:41:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah6jX-0003tQ-00 for pana@ietf.org; Thu, 15 Jan 2004 07:36:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6hv-0003l1-00 for pana@ietf.org; Thu, 15 Jan 2004 07:34:43 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FCYW215145 for ; Thu, 15 Jan 2004 14:34:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 14:34:32 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:34:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jan 2004 14:34:31 +0200 Message-ID: Thread-Topic: PANA issue tracking Thread-Index: AcPbY+yx8qUrIz3gRTmL8zKMWrFimw== To: X-OriginalArrivalTime: 15 Jan 2004 12:34:31.0989 (UTC) FILETIME=[ECEFCE50:01C3DB63] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Pana] PANA issue tracking Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi PANA folks, I've been quite a busy lately and thus the=20 time put to the PANA issue tracking has not=20 been enough (I notified the PANA WG chairs=20 about this).=20 Anyway, I've now updated the issue tracking=20 system based on the preliminary version of the=20 PANA protocol draft 03 and mailing list=20 discussions. Please give a look for the current open=20 issues at the URL: http://danforsberg.info:8080/pana-issues/ [The link "Show Open" will only show open=20 issues. The link "Show All" will show all the=20 issues, also the closed, rejected, accepted=20 and closed ones.] Br, - Dan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 07:50:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01825 for ; Thu, 15 Jan 2004 07:50:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6wJ-0003KU-5G for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 07:49:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FCnZmR012795 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 07:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6wI-0003KI-Un for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 07:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01809 for ; Thu, 15 Jan 2004 07:49:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6wD-0004V1-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 07:49:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah6sH-0004GF-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 07:45:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah6pI-00044t-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 07:42:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6oz-00032i-Hq; Thu, 15 Jan 2004 07:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah6ow-00031p-Vi for pana@optimus.ietf.org; Thu, 15 Jan 2004 07:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01550 for ; Thu, 15 Jan 2004 07:41:52 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6om-00043p-00 for pana@ietf.org; Thu, 15 Jan 2004 07:41:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah6jX-0003tQ-00 for pana@ietf.org; Thu, 15 Jan 2004 07:36:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ah6hv-0003l1-00 for pana@ietf.org; Thu, 15 Jan 2004 07:34:43 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FCYW215145 for ; Thu, 15 Jan 2004 14:34:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 14:34:32 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 14:34:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jan 2004 14:34:31 +0200 Message-ID: Thread-Topic: PANA issue tracking Thread-Index: AcPbY+yx8qUrIz3gRTmL8zKMWrFimw== To: X-OriginalArrivalTime: 15 Jan 2004 12:34:31.0989 (UTC) FILETIME=[ECEFCE50:01C3DB63] Content-Transfer-Encoding: quoted-printable Subject: [Pana] PANA issue tracking Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi PANA folks, I've been quite a busy lately and thus the=20 time put to the PANA issue tracking has not=20 been enough (I notified the PANA WG chairs=20 about this).=20 Anyway, I've now updated the issue tracking=20 system based on the preliminary version of the=20 PANA protocol draft 03 and mailing list=20 discussions. Please give a look for the current open=20 issues at the URL: http://danforsberg.info:8080/pana-issues/ [The link "Show Open" will only show open=20 issues. The link "Show All" will show all the=20 issues, also the closed, rejected, accepted=20 and closed ones.] Br, - Dan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 08:52:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05230 for ; Thu, 15 Jan 2004 08:52:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7uj-0007uJ-R0; Thu, 15 Jan 2004 08:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7ua-0007tr-Qa for pana@optimus.ietf.org; Thu, 15 Jan 2004 08:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05217 for ; Thu, 15 Jan 2004 08:51:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7uZ-0001BC-00 for pana@ietf.org; Thu, 15 Jan 2004 08:51:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7u8-00017j-00 for pana@ietf.org; Thu, 15 Jan 2004 08:51:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7ss-00013k-00 for pana@ietf.org; Thu, 15 Jan 2004 08:50:06 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FDntY15408 for ; Thu, 15 Jan 2004 15:49:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 15:49:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 15:49:54 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 15:49:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 15 Jan 2004 15:49:54 +0200 Message-ID: Thread-Topic: [issue42] Text in 4.3 heading and in figures 2 and 3. Thread-Index: AcPbblqizDNzpyJ8QuazFHXHrbl67gAAAHpg To: X-OriginalArrivalTime: 15 Jan 2004 13:49:54.0645 (UTC) FILETIME=[74A65850:01C3DB6E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue42] Text in 4.3 heading and in figures 2 and 3. Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpCYXNlZCBvbiBjb21tZW50cyB0aGF0IEkgaGF2ZSByZWNlaXZlZDoNCg0KLS0tLS0tDQpD aGFuZ2U6DQogIEZpZ3VyZSAyOiBFeGFtcGxlIFNlcXVlbmNlIGZvciBEaXNjb3ZlcnkgYW5kIElu aXRpYWwgSGFuZHNoYWtlIFBoYXNlIA0KDQpUbzoNCiAgRmlndXJlIDI6IEV4YW1wbGUgU2VxdWVu Y2UgZm9yIERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2Ugd2hlbiANCiAgICAg ICAgICAgIFBBTkEtUEFBLWRpc2NvdmVyIGlzIHNlbnQgYnkgUGFDDQoNCi0tLS0tLQ0KQ2hhbmdl OiANCiAgRmlndXJlIDM6IEV4YW1wbGUgU2VxdWVuY2UgZm9yIERpc2NvdmVyeSBhbmQgSW5pdGlh bCBIYW5kc2hha2UgUGhhc2UNCiAgICAgICAgICAgICAgICAgd2hlbiBQQU5BLVBBQS1EaXNjb3Zl ciBpcyBzZW50IGJ5IFBhQw0KDQpUbzoNCiAgRmlndXJlIDM6IEV4YW1wbGUgU2VxdWVuY2UgZm9y IERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2UNCiAgICAgICAgICAgICAgICAg d2hlbiBQQU5BLVBBQS1EaXNjb3ZlciBpcyBzZW50IGJ5IEVQDQoNCi0tLS0tLQ0KQ2hhbmdlOg0K ICAgNC4zIEF1dGhlbnRpY2F0aW9uIFBoYXNlIHdoZW4gUEFOQS1QQUEtRGlzY292ZXIgaXMgc2Vu dCBieSBFUA0KDQpUbzoNCiAgIDQuMyBBdXRoZW50aWNhdGlvbiBQaGFzZQ0KDQotLS0tLS0tLS0t DQpjYXRlZ29yeTogRWRpdG9yaWFsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEtMDIu dHh0DQptZXNzYWdlczogMTY4DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4DQpz dGF0dXM6IFRleHQgUHJvcG9zZWQNCnRpdGxlOiBUZXh0IGluIDQuMyBoZWFkaW5nIGFuZCBpbiBm aWd1cmVzIDIgYW5kIDMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8 aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTQyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 08:54:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05373 for ; Thu, 15 Jan 2004 08:54:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7wQ-00089b-5b for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 08:53:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FDrkIm031343 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 08:53:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7wQ-00089S-03 for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 08:53:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05349 for ; Thu, 15 Jan 2004 08:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7wO-0001HL-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 08:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7vW-0001Em-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 08:52:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah7ul-0001BR-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 08:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7uj-0007uJ-R0; Thu, 15 Jan 2004 08:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah7ua-0007tr-Qa for pana@optimus.ietf.org; Thu, 15 Jan 2004 08:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05217 for ; Thu, 15 Jan 2004 08:51:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7uZ-0001BC-00 for pana@ietf.org; Thu, 15 Jan 2004 08:51:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah7u8-00017j-00 for pana@ietf.org; Thu, 15 Jan 2004 08:51:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ah7ss-00013k-00 for pana@ietf.org; Thu, 15 Jan 2004 08:50:06 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0FDntY15408 for ; Thu, 15 Jan 2004 15:49:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 15 Jan 2004 15:49:55 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 15:49:54 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 15 Jan 2004 15:49:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 15 Jan 2004 15:49:54 +0200 Message-ID: Thread-Topic: [issue42] Text in 4.3 heading and in figures 2 and 3. Thread-Index: AcPbblqizDNzpyJ8QuazFHXHrbl67gAAAHpg To: X-OriginalArrivalTime: 15 Jan 2004 13:49:54.0645 (UTC) FILETIME=[74A65850:01C3DB6E] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue42] Text in 4.3 heading and in figures 2 and 3. Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpCYXNlZCBvbiBjb21tZW50cyB0aGF0IEkgaGF2ZSByZWNlaXZlZDoNCg0KLS0tLS0tDQpD aGFuZ2U6DQogIEZpZ3VyZSAyOiBFeGFtcGxlIFNlcXVlbmNlIGZvciBEaXNjb3ZlcnkgYW5kIElu aXRpYWwgSGFuZHNoYWtlIFBoYXNlIA0KDQpUbzoNCiAgRmlndXJlIDI6IEV4YW1wbGUgU2VxdWVu Y2UgZm9yIERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2Ugd2hlbiANCiAgICAg ICAgICAgIFBBTkEtUEFBLWRpc2NvdmVyIGlzIHNlbnQgYnkgUGFDDQoNCi0tLS0tLQ0KQ2hhbmdl OiANCiAgRmlndXJlIDM6IEV4YW1wbGUgU2VxdWVuY2UgZm9yIERpc2NvdmVyeSBhbmQgSW5pdGlh bCBIYW5kc2hha2UgUGhhc2UNCiAgICAgICAgICAgICAgICAgd2hlbiBQQU5BLVBBQS1EaXNjb3Zl ciBpcyBzZW50IGJ5IFBhQw0KDQpUbzoNCiAgRmlndXJlIDM6IEV4YW1wbGUgU2VxdWVuY2UgZm9y IERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2UNCiAgICAgICAgICAgICAgICAg d2hlbiBQQU5BLVBBQS1EaXNjb3ZlciBpcyBzZW50IGJ5IEVQDQoNCi0tLS0tLQ0KQ2hhbmdlOg0K ICAgNC4zIEF1dGhlbnRpY2F0aW9uIFBoYXNlIHdoZW4gUEFOQS1QQUEtRGlzY292ZXIgaXMgc2Vu dCBieSBFUA0KDQpUbzoNCiAgIDQuMyBBdXRoZW50aWNhdGlvbiBQaGFzZQ0KDQotLS0tLS0tLS0t DQpjYXRlZ29yeTogRWRpdG9yaWFsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEtMDIu dHh0DQptZXNzYWdlczogMTY4DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4DQpz dGF0dXM6IFRleHQgUHJvcG9zZWQNCnRpdGxlOiBUZXh0IGluIDQuMyBoZWFkaW5nIGFuZCBpbiBm aWd1cmVzIDIgYW5kIDMuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8 aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTQyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 13:30:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18700 for ; Thu, 15 Jan 2004 13:30:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCFn-0008Es-OQ; Thu, 15 Jan 2004 13:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCFg-0008EA-Bc for pana@optimus.ietf.org; Thu, 15 Jan 2004 13:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18575 for ; Thu, 15 Jan 2004 13:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhCFW-0000AK-00 for pana@ietf.org; Thu, 15 Jan 2004 13:29:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhCEg-00007n-00 for pana@ietf.org; Thu, 15 Jan 2004 13:28:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhCDy-00003t-00 for pana@ietf.org; Thu, 15 Jan 2004 13:28:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FIS8N9004770; Fri, 16 Jan 2004 03:28:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FIS8Lj001928; Fri, 16 Jan 2004 03:28:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA01927 ; Fri, 16 Jan 2004 03:28:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA02939; Fri, 16 Jan 2004 03:28:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA08506; Fri, 16 Jan 2004 03:28:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FIS5XD023092; Fri, 16 Jan 2004 03:28:05 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00EGKNAM4T@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 03:28:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhCDU-0002E1-00; Thu, 15 Jan 2004 10:27:40 -0800 Date: Thu, 15 Jan 2004 10:27:39 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] Issue37: Unknown realm problem propagation In-reply-to: To: Dan.Forsberg@nokia.com Cc: Yoshihiro.Ohba@tais.com, pana@ietf.org Message-id: <20040115182739.GC7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, Yoshihiro.Ohba@tais.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Dan, I think we don't have to clarify in the draft about why specific feature is unsupported. An exception is Appendix A which discusses why a particular sequenece number method was chosen, which I think is worth describing in the draft since we had a huge, fundamental discussion on this in PANA design team one year ago, and I remember this appendix was also referred to in other WG's discussion. Yoshihiro Ohba On Thu, Jan 15, 2004 at 01:50:06PM +0200, Dan.Forsberg@nokia.com wrote: > Should this be clarified in the draft? > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Yoshihiro.Ohba@tais.com > > Sent: 03 December, 2003 02:27 > > To: pana@ietf.org > > Subject: [Pana] Issue37: Unknown realm problem propagation > > > > > > > > Several comments were made on Issue 37 in the IETF58 PANA meeting. > > Here is the summary: > > > > - It is possible to propagate the event of AAA message > > routing error in > > PANA message without need to change AAA protocols. > > > > - If we take a look at another EAP transport protocol, IEEE > > 802.1X does not > > carry the AAA message routing error. > > > > - EAP state machines draft does not define an interface to > > propagate the > > AAA message routing error to EAP transport protocols. As a > > result, if PANA > > supports propagation of the AAA error, PAA will need to have a direct > > interface to AAA protocols, in addition to the interface to > > EAP. This will > > complicate implementations. > > > > I prefer not supporting this type of error message in PANA, from > > implementation perspective. > > > > The issue is described in > > http://www.danforsberg.info:8080/pana-issues/issue37 > > > > Any comments? > > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 13:33:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18825 for ; Thu, 15 Jan 2004 13:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCHO-0008PZ-BJ for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 13:31:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FIVgtq032332 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 13:31:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCHO-0008PP-5y for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 13:31:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18738 for ; Thu, 15 Jan 2004 13:31:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhCHM-0000FB-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 13:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhCGR-0000DD-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 13:30:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhCFz-0000B7-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 13:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCFn-0008Es-OQ; Thu, 15 Jan 2004 13:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCFg-0008EA-Bc for pana@optimus.ietf.org; Thu, 15 Jan 2004 13:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18575 for ; Thu, 15 Jan 2004 13:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhCFW-0000AK-00 for pana@ietf.org; Thu, 15 Jan 2004 13:29:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhCEg-00007n-00 for pana@ietf.org; Thu, 15 Jan 2004 13:28:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhCDy-00003t-00 for pana@ietf.org; Thu, 15 Jan 2004 13:28:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FIS8N9004770; Fri, 16 Jan 2004 03:28:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FIS8Lj001928; Fri, 16 Jan 2004 03:28:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA01927 ; Fri, 16 Jan 2004 03:28:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA02939; Fri, 16 Jan 2004 03:28:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA08506; Fri, 16 Jan 2004 03:28:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FIS5XD023092; Fri, 16 Jan 2004 03:28:05 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00EGKNAM4T@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 03:28:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhCDU-0002E1-00; Thu, 15 Jan 2004 10:27:40 -0800 Date: Thu, 15 Jan 2004 10:27:39 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] Issue37: Unknown realm problem propagation In-reply-to: To: Dan.Forsberg@nokia.com Cc: Yoshihiro.Ohba@tais.com, pana@ietf.org Message-id: <20040115182739.GC7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, Yoshihiro.Ohba@tais.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dan, I think we don't have to clarify in the draft about why specific feature is unsupported. An exception is Appendix A which discusses why a particular sequenece number method was chosen, which I think is worth describing in the draft since we had a huge, fundamental discussion on this in PANA design team one year ago, and I remember this appendix was also referred to in other WG's discussion. Yoshihiro Ohba On Thu, Jan 15, 2004 at 01:50:06PM +0200, Dan.Forsberg@nokia.com wrote: > Should this be clarified in the draft? > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Yoshihiro.Ohba@tais.com > > Sent: 03 December, 2003 02:27 > > To: pana@ietf.org > > Subject: [Pana] Issue37: Unknown realm problem propagation > > > > > > > > Several comments were made on Issue 37 in the IETF58 PANA meeting. > > Here is the summary: > > > > - It is possible to propagate the event of AAA message > > routing error in > > PANA message without need to change AAA protocols. > > > > - If we take a look at another EAP transport protocol, IEEE > > 802.1X does not > > carry the AAA message routing error. > > > > - EAP state machines draft does not define an interface to > > propagate the > > AAA message routing error to EAP transport protocols. As a > > result, if PANA > > supports propagation of the AAA error, PAA will need to have a direct > > interface to AAA protocols, in addition to the interface to > > EAP. This will > > complicate implementations. > > > > I prefer not supporting this type of error message in PANA, from > > implementation perspective. > > > > The issue is described in > > http://www.danforsberg.info:8080/pana-issues/issue37 > > > > Any comments? > > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 14:27:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21475 for ; Thu, 15 Jan 2004 14:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD7z-0003Hj-7h; Thu, 15 Jan 2004 14:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD7g-0003EX-45 for pana@optimus.ietf.org; Thu, 15 Jan 2004 14:25:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21402 for ; Thu, 15 Jan 2004 14:25:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhD7d-0003JF-00 for pana@ietf.org; Thu, 15 Jan 2004 14:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhD6v-0003Fn-00 for pana@ietf.org; Thu, 15 Jan 2004 14:24:58 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhD64-0003Al-00 for pana@ietf.org; Thu, 15 Jan 2004 14:24:05 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FJO4N9023292 for ; Fri, 16 Jan 2004 04:24:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FJO4V2021607 for ; Fri, 16 Jan 2004 04:24:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA21606 ; Fri, 16 Jan 2004 04:24:03 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA17652; Fri, 16 Jan 2004 04:24:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA08176; Fri, 16 Jan 2004 04:24:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FJO2XD000746 for ; Fri, 16 Jan 2004 04:24:02 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00EXYPW04T@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 16 Jan 2004 04:24:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhD5L-0002LW-00 for ; Thu, 15 Jan 2004 11:23:19 -0800 Date: Thu, 15 Jan 2004 11:23:19 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040115192319.GE7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] Minor issue on cookie Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , In section 4.2 of PANA specification: "A PANA-Start-Request message contains a cookie carried in a Cookie AVP in the payload, respectively." It is better to make it clear that cookie is optional. Also, ", respectively" is not needed. Suggested change: "A PANA-Start-Request message MAY carry a Cookie AVP that contains a cookie." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 14:28:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21583 for ; Thu, 15 Jan 2004 14:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD9j-0003OX-NK for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 14:27:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJRpJi013043 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 14:27:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD9j-0003OI-JK for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 14:27:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21533 for ; Thu, 15 Jan 2004 14:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhD9g-0003Um-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 14:27:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhD8s-0003QC-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 14:26:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhD80-0003M7-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 14:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD7z-0003Hj-7h; Thu, 15 Jan 2004 14:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhD7g-0003EX-45 for pana@optimus.ietf.org; Thu, 15 Jan 2004 14:25:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21402 for ; Thu, 15 Jan 2004 14:25:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhD7d-0003JF-00 for pana@ietf.org; Thu, 15 Jan 2004 14:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhD6v-0003Fn-00 for pana@ietf.org; Thu, 15 Jan 2004 14:24:58 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhD64-0003Al-00 for pana@ietf.org; Thu, 15 Jan 2004 14:24:05 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FJO4N9023292 for ; Fri, 16 Jan 2004 04:24:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FJO4V2021607 for ; Fri, 16 Jan 2004 04:24:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA21606 ; Fri, 16 Jan 2004 04:24:03 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA17652; Fri, 16 Jan 2004 04:24:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA08176; Fri, 16 Jan 2004 04:24:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FJO2XD000746 for ; Fri, 16 Jan 2004 04:24:02 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00EXYPW04T@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 16 Jan 2004 04:24:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhD5L-0002LW-00 for ; Thu, 15 Jan 2004 11:23:19 -0800 Date: Thu, 15 Jan 2004 11:23:19 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040115192319.GE7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] Minor issue on cookie Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In section 4.2 of PANA specification: "A PANA-Start-Request message contains a cookie carried in a Cookie AVP in the payload, respectively." It is better to make it clear that cookie is optional. Also, ", respectively" is not needed. Suggested change: "A PANA-Start-Request message MAY carry a Cookie AVP that contains a cookie." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 16:24:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29342 for ; Thu, 15 Jan 2004 16:24:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyG-0001qQ-Ic; Thu, 15 Jan 2004 16:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDux-0007kP-Nl for pana@optimus.ietf.org; Thu, 15 Jan 2004 15:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26122 for ; Thu, 15 Jan 2004 15:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDuw-0007gx-00 for pana@ietf.org; Thu, 15 Jan 2004 15:16:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDu3-0007eo-00 for pana@ietf.org; Thu, 15 Jan 2004 15:15:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhDt8-0007bK-00 for pana@ietf.org; Thu, 15 Jan 2004 15:14:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FKEiN9007945 for ; Fri, 16 Jan 2004 05:14:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FKEiDP012713 for ; Fri, 16 Jan 2004 05:14:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA12712 ; Fri, 16 Jan 2004 05:14:44 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA03024; Fri, 16 Jan 2004 05:14:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA12643; Fri, 16 Jan 2004 05:14:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FKEgXD009147 for ; Fri, 16 Jan 2004 05:14:42 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00H34S8GHY@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 16 Jan 2004 05:14:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhDrs-0002TV-00 for ; Thu, 15 Jan 2004 12:13:28 -0800 Date: Thu, 15 Jan 2004 12:13:28 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040115201328.GG7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] EAP-Payload in PANA-Start-Request/Answer Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I think the following discussion does not appear on the issue list: http://www1.ietf.org/mail-archive/working-groups/pana/current/msg00122.html Here is the suggested change. In section 4.1, add: "When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. In any case, PANA MUST NOT generate an EAP message on behalf of EAP peer or EAP (pass-through) authenticator." In section 9.3.3, change: " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ]" to: " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ]" In section 9.3.4, change: " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > [ Cookie ] [ ISP-Information ] * [ AVP ]" To: " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > [ Cookie ] [ EAP-Payload ] [ ISP-Information ] * [ AVP ]" In section 9.5, change: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0 | 0 | 1 | 1 | 1 | 0 | 0 |" to: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 |" Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 16:27:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29756 for ; Thu, 15 Jan 2004 16:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhF0w-0002nj-61 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 16:26:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FLQsj3010756 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 16:26:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhF0v-0002nO-RK for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 16:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29674 for ; Thu, 15 Jan 2004 16:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhF0t-0003G9-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 16:26:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhEzX-00032E-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 16:25:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhEyh-0002qg-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 16:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhEyG-0001qQ-Ic; Thu, 15 Jan 2004 16:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhDux-0007kP-Nl for pana@optimus.ietf.org; Thu, 15 Jan 2004 15:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26122 for ; Thu, 15 Jan 2004 15:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhDuw-0007gx-00 for pana@ietf.org; Thu, 15 Jan 2004 15:16:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhDu3-0007eo-00 for pana@ietf.org; Thu, 15 Jan 2004 15:15:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhDt8-0007bK-00 for pana@ietf.org; Thu, 15 Jan 2004 15:14:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FKEiN9007945 for ; Fri, 16 Jan 2004 05:14:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FKEiDP012713 for ; Fri, 16 Jan 2004 05:14:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA12712 ; Fri, 16 Jan 2004 05:14:44 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA03024; Fri, 16 Jan 2004 05:14:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA12643; Fri, 16 Jan 2004 05:14:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FKEgXD009147 for ; Fri, 16 Jan 2004 05:14:42 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00H34S8GHY@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 16 Jan 2004 05:14:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhDrs-0002TV-00 for ; Thu, 15 Jan 2004 12:13:28 -0800 Date: Thu, 15 Jan 2004 12:13:28 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040115201328.GG7429@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] EAP-Payload in PANA-Start-Request/Answer Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think the following discussion does not appear on the issue list: http://www1.ietf.org/mail-archive/working-groups/pana/current/msg00122.html Here is the suggested change. In section 4.1, add: "When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. In any case, PANA MUST NOT generate an EAP message on behalf of EAP peer or EAP (pass-through) authenticator." In section 9.3.3, change: " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ]" to: " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > [ Cookie ] [ EAP-Payload ] [ NAP-Information ] * [ ISP-Information ] * [ AVP ]" In section 9.3.4, change: " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > [ Cookie ] [ ISP-Information ] * [ AVP ]" To: " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > [ Cookie ] [ EAP-Payload ] [ ISP-Information ] * [ AVP ]" In section 9.5, change: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0 | 0 | 1 | 1 | 1 | 0 | 0 |" to: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 |" Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 17:13:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04784 for ; Thu, 15 Jan 2004 17:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFjY-0006cr-Hp; Thu, 15 Jan 2004 17:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFjL-0006b0-R0 for pana@optimus.ietf.org; Thu, 15 Jan 2004 17:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04748 for ; Thu, 15 Jan 2004 17:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFjJ-0000od-00 for pana@ietf.org; Thu, 15 Jan 2004 17:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFiJ-0000lN-00 for pana@ietf.org; Thu, 15 Jan 2004 17:11:44 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AhFhL-0000j5-00 for pana@ietf.org; Thu, 15 Jan 2004 17:10:44 -0500 Date: Thu, 15 Jan 2004 14:10:34 -0800 Subject: Re: [Pana] PANA-IPsec-01 From: Alper Yegin To: Yoshihiro Ohba , Mohan Parthasarathy CC: Message-ID: In-Reply-To: <20040115031503.GC4868@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | >>> Session ID | MSK-ID) >>> >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even >>> another key driven from PANA SA Key??) >>> >> I have to think more on this to understand the difference. > > The difference would be whether the IKE pre-shared key and PANA SA key > becomes cryptographycally separate or not. By using the MSK, the IKE > pre-shared key and PANA SA key are cryptographycally indepenent. > Unless there is a specific reason for the two keys to be > cryptographycally dependent, I think using the MSK is stronger (and > better). Passing the MSK to the EP runs the risk that, any other key derived off of MSK can also be generated by the EP. This is why I was saying maybe we shouldn't even use PANA SA key, but some other key generated from it. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 17:15:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04886 for ; Thu, 15 Jan 2004 17:15:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFlO-0006iz-23 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 17:14:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMEsEg025843 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 17:14:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFlN-0006ik-Qo for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 17:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04856 for ; Thu, 15 Jan 2004 17:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFlL-0000x6-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFkQ-0000tj-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:13:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhFjZ-0000qq-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFjY-0006cr-Hp; Thu, 15 Jan 2004 17:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhFjL-0006b0-R0 for pana@optimus.ietf.org; Thu, 15 Jan 2004 17:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04748 for ; Thu, 15 Jan 2004 17:12:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFjJ-0000od-00 for pana@ietf.org; Thu, 15 Jan 2004 17:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFiJ-0000lN-00 for pana@ietf.org; Thu, 15 Jan 2004 17:11:44 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AhFhL-0000j5-00 for pana@ietf.org; Thu, 15 Jan 2004 17:10:44 -0500 Date: Thu, 15 Jan 2004 14:10:34 -0800 Subject: Re: [Pana] PANA-IPsec-01 From: Alper Yegin To: Yoshihiro Ohba , Mohan Parthasarathy CC: Message-ID: In-Reply-To: <20040115031503.GC4868@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>> >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | >>> Session ID | MSK-ID) >>> >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even >>> another key driven from PANA SA Key??) >>> >> I have to think more on this to understand the difference. > > The difference would be whether the IKE pre-shared key and PANA SA key > becomes cryptographycally separate or not. By using the MSK, the IKE > pre-shared key and PANA SA key are cryptographycally indepenent. > Unless there is a specific reason for the two keys to be > cryptographycally dependent, I think using the MSK is stronger (and > better). Passing the MSK to the EP runs the risk that, any other key derived off of MSK can also be generated by the EP. This is why I was saying maybe we shouldn't even use PANA SA key, but some other key generated from it. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 17:50:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06322 for ; Thu, 15 Jan 2004 17:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGJP-0000LM-Ml; Thu, 15 Jan 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGJB-0000KR-Op for pana@optimus.ietf.org; Thu, 15 Jan 2004 17:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06318 for ; Thu, 15 Jan 2004 17:49:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGJ9-00039y-00 for pana@ietf.org; Thu, 15 Jan 2004 17:49:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGIQ-00038a-00 for pana@ietf.org; Thu, 15 Jan 2004 17:49:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhGHv-00036X-00 for pana@ietf.org; Thu, 15 Jan 2004 17:48:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FMmRN9022008; Fri, 16 Jan 2004 07:48:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FMmRkq013952; Fri, 16 Jan 2004 07:48:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA13951 ; Fri, 16 Jan 2004 07:48:27 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA18696; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA02354; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FMmPXD002281; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00KSMZCNC8@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 07:48:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhGHI-0002nn-00; Thu, 15 Jan 2004 14:47:52 -0800 Date: Thu, 15 Jan 2004 14:47:52 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , Mohan Parthasarathy , pana@ietf.org Message-id: <20040115224752.GB9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Mohan Parthasarathy , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > >>> > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > >>> Session ID | MSK-ID) > >>> > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > >>> another key driven from PANA SA Key??) > >>> > >> I have to think more on this to understand the difference. > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > becomes cryptographycally separate or not. By using the MSK, the IKE > > pre-shared key and PANA SA key are cryptographycally indepenent. > > Unless there is a specific reason for the two keys to be > > cryptographycally dependent, I think using the MSK is stronger (and > > better). > > Passing the MSK to the EP runs the risk that, any other key derived off of > MSK can also be generated by the EP. This is why I was saying maybe we > shouldn't even use PANA SA key, but some other key generated from it. I was thinking that the calculated IKE pre-shared key is passed to EP (over secure SNMPv3 communication) and MSK itself is not passed. Is this danger? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 17:52:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06410 for ; Thu, 15 Jan 2004 17:52:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGLB-0000bU-12 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 17:51:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FMpqn3002314 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 17:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGLA-0000bF-SM for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 17:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06379 for ; Thu, 15 Jan 2004 17:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGL8-0003Fp-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:51:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGKC-0003CG-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:50:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhGJQ-0003AK-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 17:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGJP-0000LM-Ml; Thu, 15 Jan 2004 17:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhGJB-0000KR-Op for pana@optimus.ietf.org; Thu, 15 Jan 2004 17:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06318 for ; Thu, 15 Jan 2004 17:49:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhGJ9-00039y-00 for pana@ietf.org; Thu, 15 Jan 2004 17:49:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhGIQ-00038a-00 for pana@ietf.org; Thu, 15 Jan 2004 17:49:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhGHv-00036X-00 for pana@ietf.org; Thu, 15 Jan 2004 17:48:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0FMmRN9022008; Fri, 16 Jan 2004 07:48:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0FMmRkq013952; Fri, 16 Jan 2004 07:48:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA13951 ; Fri, 16 Jan 2004 07:48:27 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA18696; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA02354; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0FMmPXD002281; Fri, 16 Jan 2004 07:48:26 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRJ00KSMZCNC8@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 07:48:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhGHI-0002nn-00; Thu, 15 Jan 2004 14:47:52 -0800 Date: Thu, 15 Jan 2004 14:47:52 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , Mohan Parthasarathy , pana@ietf.org Message-id: <20040115224752.GB9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Mohan Parthasarathy , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > >>> > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > >>> Session ID | MSK-ID) > >>> > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > >>> another key driven from PANA SA Key??) > >>> > >> I have to think more on this to understand the difference. > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > becomes cryptographycally separate or not. By using the MSK, the IKE > > pre-shared key and PANA SA key are cryptographycally indepenent. > > Unless there is a specific reason for the two keys to be > > cryptographycally dependent, I think using the MSK is stronger (and > > better). > > Passing the MSK to the EP runs the risk that, any other key derived off of > MSK can also be generated by the EP. This is why I was saying maybe we > shouldn't even use PANA SA key, but some other key generated from it. I was thinking that the calculated IKE pre-shared key is passed to EP (over secure SNMPv3 communication) and MSK itself is not passed. Is this danger? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 19:08:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09577 for ; Thu, 15 Jan 2004 19:08:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHWr-0004jO-WA; Thu, 15 Jan 2004 19:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHWf-0004dw-6w for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09559 for ; Thu, 15 Jan 2004 19:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHWb-0006WX-00 for pana@ietf.org; Thu, 15 Jan 2004 19:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHVc-0006UL-00 for pana@ietf.org; Thu, 15 Jan 2004 19:06:45 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1AhHUd-0006Rk-00 for pana@ietf.org; Thu, 15 Jan 2004 19:05:43 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:05:23 -0000 Message-ID: <00b701c3dbc4$7284bac0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:05:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > > > > Hi Mohan, > > > > > > Some comments and questions on the latest draft... > > > > > > In the case of DHCP and IKE, EP can trivially learn the address > > > allocated to the client. > > > > > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > > > within IKEv2 for the latter. You might want to explicitly mention these. > > > > > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. > > Hmm, I was interpretting the previous sentence differently. > > 4) PaC configures a link-local address before the PANA protocol > begins. At the end of authentication, it either acquires a > globally reachable address using [DHCP][DHCPV6] or using IKE or > auto-configures an address using stateless auto-configuration > [IPV6-ND] if IPv6 is being used. > > I think "using [DHCP][DHCPV6]" means using DHCP or DHCPv6 before > running IKE or IKEv2. > > "using IKE" (or "using IKE or IKEv2" according to Mohan's above > comment) means that running address configuration methods available > within IKE or IKEv2 (i.e., by using modecfg or Configuration Payload). > > "auto-configures an address" means running stateless auto-configuration > before running IKE or IKEv2. > Yes, this is what i had in mind. > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > mode SA). This may be different from any of above three cases, > because DHCP SA is created by "using IKE" but DHCP messages are not > carried in IKE payloads. > This is what we have discussed before in a different context. But i am not going to discuss it in this draft. > > > > > > > > > In the case of auto-configuration > > > (which includes global address or addresses configured as in > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > We should qualify which address we are talking about here. I think it is the > > > inner IP address. > > > > > Okay. I will clarify this. > > > > > Thus, > > > it may not be able to setup the SPD entries appropriately before > > > IKE exchange starts. As most of the IKE implementations assume > > > that the SPD can be consulted during the SA negotiation, it may > > > require slightly a different behavior from IKE in the auto- > > > configuration case. In the case of auto-configuration, IKE > > > should be able to setup the SAs for the traffic selectors > > > specified by the PaC without consulting the SPD entry. If there > > > is already an SA for the same address, then the SA request MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > for protecting the subsequent data packets. > > > > > > Does this require any modifications to the IKE protocol, or simply > > > implementation modification is sufficient? > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > What is the probelm in the case of auto-configuration if IKE is not > able to setup the SAs for the traffic selectors specified by the PaC > without consulting the SPD entry? > The one mentioned in the security consideration. EP is blindly trusting what the PaC is saying about the inner addresses i.e clients can spoof. But it is not the same as service theft that we discussed in the threats document. The PaC still needs to have the right keys. And the addresses assigned are temporary. So, i really don't see a big issue with this. > > > > > The other possibility (in addition to DHCP, IKE, autoconf-based > > > configuration) is the statis IP configuration. I guess its handling will be > > > same as autoconf one? [In that case, would we still use link-local IP > > > address during PANA, or simply use the pre-configured IP address?] > > > > > > > > > As EP and PAA are assumed to be co-located,this might be just an API > > > call. > > > > > > We don't assume that. We just assume EP is co-located with an AR in the > > > IPsec-based access control case. PAA might still be hosted on a separate > > > node. This shouldn't impact the PANA-IPsec design though. > > > > > Agreed. > > I agree, too. > > > > > > > > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > Session ID | MSK-ID) > > > > > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > another key driven from PANA SA Key??) > > > > > I have to think more on this to understand the difference. > > The difference would be whether the IKE pre-shared key and PANA SA key > becomes cryptographycally separate or not. By using the MSK, the IKE > pre-shared key and PANA SA key are cryptographycally indepenent. > Unless there is a specific reason for the two keys to be > cryptographycally dependent, I think using the MSK is stronger (and > better). > This is right. This is the same comment i received from another reviewer. Cryptographic separattion is the only thing i can think of. -mohan > Yoshihiro Ohba > > > > > > > If the PAA does not verify whether PaC is authorized to use an IP > > > address, it is possible for the PaC to steal the traffic destined to > > > some other PaC. > > > > > > Are we talking about the inner IP address or the outer (or both)? > > > > > This is about the inner address. > > > > > This should not be a limitation as the link- > > > local address is used only by link-local services e.g. > > > neighbor/router discovery, which uses a different mechanism to > > > protect their traffic. > > > > > > I think we are referring to the SEND problem here. If so, let's give a > > > reference to the current spec. > > > > > Okay. > > > > -mohan > > > > > Thanks. > > > > > > Alper > > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 19:10:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09685 for ; Thu, 15 Jan 2004 19:10:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHYf-0004vz-OD for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:09:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G09rnD018961 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:09:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHYf-0004vk-JD for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:09:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09656 for ; Thu, 15 Jan 2004 19:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHYc-0006cT-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:09:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHXi-0006ac-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:08:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhHWx-0006YL-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHWr-0004jO-WA; Thu, 15 Jan 2004 19:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHWf-0004dw-6w for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09559 for ; Thu, 15 Jan 2004 19:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHWb-0006WX-00 for pana@ietf.org; Thu, 15 Jan 2004 19:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHVc-0006UL-00 for pana@ietf.org; Thu, 15 Jan 2004 19:06:45 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1AhHUd-0006Rk-00 for pana@ietf.org; Thu, 15 Jan 2004 19:05:43 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:05:23 -0000 Message-ID: <00b701c3dbc4$7284bac0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:05:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > > > > Hi Mohan, > > > > > > Some comments and questions on the latest draft... > > > > > > In the case of DHCP and IKE, EP can trivially learn the address > > > allocated to the client. > > > > > > I presume you are referring to RFC3456 for DHCP, and configuring IP address > > > within IKEv2 for the latter. You might want to explicitly mention these. > > > > > It could be IKE or IKEv2. And the previous line should have mentioned this i thought.. > > Hmm, I was interpretting the previous sentence differently. > > 4) PaC configures a link-local address before the PANA protocol > begins. At the end of authentication, it either acquires a > globally reachable address using [DHCP][DHCPV6] or using IKE or > auto-configures an address using stateless auto-configuration > [IPV6-ND] if IPv6 is being used. > > I think "using [DHCP][DHCPV6]" means using DHCP or DHCPv6 before > running IKE or IKEv2. > > "using IKE" (or "using IKE or IKEv2" according to Mohan's above > comment) means that running address configuration methods available > within IKE or IKEv2 (i.e., by using modecfg or Configuration Payload). > > "auto-configures an address" means running stateless auto-configuration > before running IKE or IKEv2. > Yes, this is what i had in mind. > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > mode SA). This may be different from any of above three cases, > because DHCP SA is created by "using IKE" but DHCP messages are not > carried in IKE payloads. > This is what we have discussed before in a different context. But i am not going to discuss it in this draft. > > > > > > > > > In the case of auto-configuration > > > (which includes global address or addresses configured as in > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > We should qualify which address we are talking about here. I think it is the > > > inner IP address. > > > > > Okay. I will clarify this. > > > > > Thus, > > > it may not be able to setup the SPD entries appropriately before > > > IKE exchange starts. As most of the IKE implementations assume > > > that the SPD can be consulted during the SA negotiation, it may > > > require slightly a different behavior from IKE in the auto- > > > configuration case. In the case of auto-configuration, IKE > > > should be able to setup the SAs for the traffic selectors > > > specified by the PaC without consulting the SPD entry. If there > > > is already an SA for the same address, then the SA request MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > for protecting the subsequent data packets. > > > > > > Does this require any modifications to the IKE protocol, or simply > > > implementation modification is sufficient? > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > What is the probelm in the case of auto-configuration if IKE is not > able to setup the SAs for the traffic selectors specified by the PaC > without consulting the SPD entry? > The one mentioned in the security consideration. EP is blindly trusting what the PaC is saying about the inner addresses i.e clients can spoof. But it is not the same as service theft that we discussed in the threats document. The PaC still needs to have the right keys. And the addresses assigned are temporary. So, i really don't see a big issue with this. > > > > > The other possibility (in addition to DHCP, IKE, autoconf-based > > > configuration) is the statis IP configuration. I guess its handling will be > > > same as autoconf one? [In that case, would we still use link-local IP > > > address during PANA, or simply use the pre-configured IP address?] > > > > > > > > > As EP and PAA are assumed to be co-located,this might be just an API > > > call. > > > > > > We don't assume that. We just assume EP is co-located with an AR in the > > > IPsec-based access control case. PAA might still be hosted on a separate > > > node. This shouldn't impact the PANA-IPsec design though. > > > > > Agreed. > > I agree, too. > > > > > > > > > IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > Session ID | MSK-ID) > > > > > > I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > another key driven from PANA SA Key??) > > > > > I have to think more on this to understand the difference. > > The difference would be whether the IKE pre-shared key and PANA SA key > becomes cryptographycally separate or not. By using the MSK, the IKE > pre-shared key and PANA SA key are cryptographycally indepenent. > Unless there is a specific reason for the two keys to be > cryptographycally dependent, I think using the MSK is stronger (and > better). > This is right. This is the same comment i received from another reviewer. Cryptographic separattion is the only thing i can think of. -mohan > Yoshihiro Ohba > > > > > > > If the PAA does not verify whether PaC is authorized to use an IP > > > address, it is possible for the PaC to steal the traffic destined to > > > some other PaC. > > > > > > Are we talking about the inner IP address or the outer (or both)? > > > > > This is about the inner address. > > > > > This should not be a limitation as the link- > > > local address is used only by link-local services e.g. > > > neighbor/router discovery, which uses a different mechanism to > > > protect their traffic. > > > > > > I think we are referring to the SEND problem here. If so, let's give a > > > reference to the current spec. > > > > > Okay. > > > > -mohan > > > > > Thanks. > > > > > > Alper > > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 19:14:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09844 for ; Thu, 15 Jan 2004 19:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHcf-000545-6m; Thu, 15 Jan 2004 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHce-00053j-Af for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:14:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09841 for ; Thu, 15 Jan 2004 19:13:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHcc-0006rA-00 for pana@ietf.org; Thu, 15 Jan 2004 19:13:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHbg-0006nd-00 for pana@ietf.org; Thu, 15 Jan 2004 19:13:00 -0500 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1AhHbL-0006kZ-00 for pana@ietf.org; Thu, 15 Jan 2004 19:12:39 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:12:33 -0000 Message-ID: <00c701c3dbc5$72b12c80$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: "Yoshihiro Ohba" , References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:12:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > >>> > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > >>> Session ID | MSK-ID) > > >>> > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > >>> another key driven from PANA SA Key??) > > >>> > > >> I have to think more on this to understand the difference. > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > Unless there is a specific reason for the two keys to be > > > cryptographycally dependent, I think using the MSK is stronger (and > > > better). > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > MSK can also be generated by the EP. This is why I was saying maybe we > > shouldn't even use PANA SA key, but some other key generated from it. > > I was thinking that the calculated IKE pre-shared key is passed to EP > (over secure SNMPv3 communication) and MSK itself is not passed. > Is this danger? > This is what is mentioned in the IPsec draft in section 4.0. -mohan > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 19:16:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09982 for ; Thu, 15 Jan 2004 19:16:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHeT-000596-Sr for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:15:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0FrAN019774 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHeT-00058r-OD for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09955 for ; Thu, 15 Jan 2004 19:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHeS-0006xj-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:15:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHdZ-0006vC-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:14:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhHcf-0006rk-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHcf-000545-6m; Thu, 15 Jan 2004 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHce-00053j-Af for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:14:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09841 for ; Thu, 15 Jan 2004 19:13:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHcc-0006rA-00 for pana@ietf.org; Thu, 15 Jan 2004 19:13:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHbg-0006nd-00 for pana@ietf.org; Thu, 15 Jan 2004 19:13:00 -0500 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1AhHbL-0006kZ-00 for pana@ietf.org; Thu, 15 Jan 2004 19:12:39 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:12:33 -0000 Message-ID: <00c701c3dbc5$72b12c80$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: "Yoshihiro Ohba" , References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:12:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > >>> > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > >>> Session ID | MSK-ID) > > >>> > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > >>> another key driven from PANA SA Key??) > > >>> > > >> I have to think more on this to understand the difference. > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > Unless there is a specific reason for the two keys to be > > > cryptographycally dependent, I think using the MSK is stronger (and > > > better). > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > MSK can also be generated by the EP. This is why I was saying maybe we > > shouldn't even use PANA SA key, but some other key generated from it. > > I was thinking that the calculated IKE pre-shared key is passed to EP > (over secure SNMPv3 communication) and MSK itself is not passed. > Is this danger? > This is what is mentioned in the IPsec draft in section 4.0. -mohan > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 19:26:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10233 for ; Thu, 15 Jan 2004 19:26:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHoI-0005Za-AT; Thu, 15 Jan 2004 19:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHo4-0005XM-Cn for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:25:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10230 for ; Thu, 15 Jan 2004 19:25:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHo2-0007M0-00 for pana@ietf.org; Thu, 15 Jan 2004 19:25:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHn8-0007KC-00 for pana@ietf.org; Thu, 15 Jan 2004 19:24:51 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AhHmF-0007I5-00 for pana@ietf.org; Thu, 15 Jan 2004 19:23:55 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:10:17 -0000 Message-ID: <00bd01c3dbc5$214312f0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115045929.GB7429@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:10:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Please see my other comments below: > > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > specified by the PaC without consulting the SPD entry. If there > > > is already an SA for the same address, then the SA request MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > for protecting the subsequent data packets. > > > > > The above text seems to prohibit establishing multiple IPsec SAs > between a given pair of PaC and EP. I thought we have previously > agreed on allowing multiple IPsec SAs to avoid double IPsec encryption > in the corporate VPN case (i.e., creating a separate IPsec SA with > null encryption for traffic that carries IPsec'ed packets to the > corporate VPN gateway.) Is there any issue for allowing the case? > I want to keep the draft simple. But we can make sure that it can support your case also by mentioning that the same address is not used by a different session i.e you reject if the same address is proposed by a different session-ID present in the ID_KEY_ID payload. Would it suffice ? > > During EAP re-authentication, the MSK changes. Whenever the MSK > changes, a new value of MSK-ID is established between the PaC and > PAA/EP. If there is already an IKE SA established, it can continue to > be used till it expires. A change in the value of MSK need not result > in re-negotiating a new IKE SA or IPsec SA immediately. But any new > negotiation of IKE SA should use the new pre-shared key derived from > the latest MSK and is indicated by the MSK-ID in the above equation. > > I think the above operation needs be specified by using strict > language in order to avoid possible non-interoperable implementations. > > How about this? : > > During EAP re-authentication, the MSK changes. Whenever the MSK > changes, a new value of MSK-ID is established between the PaC and > PAA/EP. If there is already an IKE SA established, it MUST continue to > be used till it expires. A change in the value of MSK MUST NOT result > in re-negotiating a new IKE SA or IPsec SA immediately. But any new > negotiation of IKE SA MUST use the new pre-shared key derived from > the latest MSK and is indicated by the MSK-ID in the above equation." > Agreed. -mohan > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 19:28:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10272 for ; Thu, 15 Jan 2004 19:28:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHq5-0005eS-Ha for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:27:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0Rr3k021718 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHq5-0005eD-D7 for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:27:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10260 for ; Thu, 15 Jan 2004 19:27:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHq3-0007Qm-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHp4-0007Oh-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:26:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhHoJ-0007N5-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHoI-0005Za-AT; Thu, 15 Jan 2004 19:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhHo4-0005XM-Cn for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:25:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10230 for ; Thu, 15 Jan 2004 19:25:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHo2-0007M0-00 for pana@ietf.org; Thu, 15 Jan 2004 19:25:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHn8-0007KC-00 for pana@ietf.org; Thu, 15 Jan 2004 19:24:51 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AhHmF-0007I5-00 for pana@ietf.org; Thu, 15 Jan 2004 19:23:55 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 00:10:17 -0000 Message-ID: <00bd01c3dbc5$214312f0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115045929.GB7429@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 15 Jan 2004 16:10:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Please see my other comments below: > > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > specified by the PaC without consulting the SPD entry. If there > > > is already an SA for the same address, then the SA request MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > for protecting the subsequent data packets. > > > > > The above text seems to prohibit establishing multiple IPsec SAs > between a given pair of PaC and EP. I thought we have previously > agreed on allowing multiple IPsec SAs to avoid double IPsec encryption > in the corporate VPN case (i.e., creating a separate IPsec SA with > null encryption for traffic that carries IPsec'ed packets to the > corporate VPN gateway.) Is there any issue for allowing the case? > I want to keep the draft simple. But we can make sure that it can support your case also by mentioning that the same address is not used by a different session i.e you reject if the same address is proposed by a different session-ID present in the ID_KEY_ID payload. Would it suffice ? > > During EAP re-authentication, the MSK changes. Whenever the MSK > changes, a new value of MSK-ID is established between the PaC and > PAA/EP. If there is already an IKE SA established, it can continue to > be used till it expires. A change in the value of MSK need not result > in re-negotiating a new IKE SA or IPsec SA immediately. But any new > negotiation of IKE SA should use the new pre-shared key derived from > the latest MSK and is indicated by the MSK-ID in the above equation. > > I think the above operation needs be specified by using strict > language in order to avoid possible non-interoperable implementations. > > How about this? : > > During EAP re-authentication, the MSK changes. Whenever the MSK > changes, a new value of MSK-ID is established between the PaC and > PAA/EP. If there is already an IKE SA established, it MUST continue to > be used till it expires. A change in the value of MSK MUST NOT result > in re-negotiating a new IKE SA or IPsec SA immediately. But any new > negotiation of IKE SA MUST use the new pre-shared key derived from > the latest MSK and is indicated by the MSK-ID in the above equation." > Agreed. -mohan > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 19:43:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10825 for ; Thu, 15 Jan 2004 19:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI4j-0006QH-6Q; Thu, 15 Jan 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI4V-0006PV-TH for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:42:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10795 for ; Thu, 15 Jan 2004 19:42:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhI4U-00006W-00 for pana@ietf.org; Thu, 15 Jan 2004 19:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhI3Y-000057-00 for pana@ietf.org; Thu, 15 Jan 2004 19:41:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhI2d-00003y-00 for pana@ietf.org; Thu, 15 Jan 2004 19:40:51 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0G0emN9024406; Fri, 16 Jan 2004 09:40:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0G0eldc002368; Fri, 16 Jan 2004 09:40:47 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA02364 ; Fri, 16 Jan 2004 09:40:47 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA04557; Fri, 16 Jan 2004 09:40:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA20472; Fri, 16 Jan 2004 09:35:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0G0ZkXD005730; Fri, 16 Jan 2004 09:35:46 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRK003UL4BKJ9@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 09:35:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhHw9-000313-00; Thu, 15 Jan 2004 16:34:09 -0800 Date: Thu, 15 Jan 2004 16:34:09 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00bd01c3dbc5$214312f0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116003409.GD9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115045929.GB7429@steelhead> <00bd01c3dbc5$214312f0$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 15, 2004 at 04:10:20PM -0800, Mohan Parthasarathy wrote: > > > > > Please see my other comments below: > > > > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > specified by the PaC without consulting the SPD entry. If there > > > > is already an SA for the same address, then the SA request MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > for protecting the subsequent data packets. > > > > > > > > The above text seems to prohibit establishing multiple IPsec SAs > > between a given pair of PaC and EP. I thought we have previously > > agreed on allowing multiple IPsec SAs to avoid double IPsec encryption > > in the corporate VPN case (i.e., creating a separate IPsec SA with > > null encryption for traffic that carries IPsec'ed packets to the > > corporate VPN gateway.) Is there any issue for allowing the case? > > > I want to keep the draft simple. But we can make sure that it can support your > case also by mentioning that the same address is not used by a different > session i.e you reject if the same address is proposed by a different session-ID > present in the ID_KEY_ID payload. Would it suffice ? I believe double IPsec encryption avoidance is something we should provide. And I like your suggested scheme of using "inner IP address + session-ID" to reject IPsec SA for the same inner address, for protection against the "inner address theft" attack. That seems still simple to me. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 19:45:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10887 for ; Thu, 15 Jan 2004 19:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI6V-0006UV-AX for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:44:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0ipom024945 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:44:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI6V-0006UG-29 for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10864 for ; Thu, 15 Jan 2004 19:44:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhI6T-0000C3-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhI5Y-00009w-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:43:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhI4j-00008B-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI4j-0006QH-6Q; Thu, 15 Jan 2004 19:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhI4V-0006PV-TH for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:42:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10795 for ; Thu, 15 Jan 2004 19:42:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhI4U-00006W-00 for pana@ietf.org; Thu, 15 Jan 2004 19:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhI3Y-000057-00 for pana@ietf.org; Thu, 15 Jan 2004 19:41:48 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhI2d-00003y-00 for pana@ietf.org; Thu, 15 Jan 2004 19:40:51 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0G0emN9024406; Fri, 16 Jan 2004 09:40:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0G0eldc002368; Fri, 16 Jan 2004 09:40:47 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA02364 ; Fri, 16 Jan 2004 09:40:47 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA04557; Fri, 16 Jan 2004 09:40:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA20472; Fri, 16 Jan 2004 09:35:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0G0ZkXD005730; Fri, 16 Jan 2004 09:35:46 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRK003UL4BKJ9@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 09:35:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhHw9-000313-00; Thu, 15 Jan 2004 16:34:09 -0800 Date: Thu, 15 Jan 2004 16:34:09 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00bd01c3dbc5$214312f0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116003409.GD9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115045929.GB7429@steelhead> <00bd01c3dbc5$214312f0$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, Jan 15, 2004 at 04:10:20PM -0800, Mohan Parthasarathy wrote: > > > > > Please see my other comments below: > > > > On Wed, Jan 14, 2004 at 06:32:20PM -0800, Mohan Parthasarathy wrote: > > > > specified by the PaC without consulting the SPD entry. If there > > > > is already an SA for the same address, then the SA request MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > for protecting the subsequent data packets. > > > > > > > > The above text seems to prohibit establishing multiple IPsec SAs > > between a given pair of PaC and EP. I thought we have previously > > agreed on allowing multiple IPsec SAs to avoid double IPsec encryption > > in the corporate VPN case (i.e., creating a separate IPsec SA with > > null encryption for traffic that carries IPsec'ed packets to the > > corporate VPN gateway.) Is there any issue for allowing the case? > > > I want to keep the draft simple. But we can make sure that it can support your > case also by mentioning that the same address is not used by a different > session i.e you reject if the same address is proposed by a different session-ID > present in the ID_KEY_ID payload. Would it suffice ? I believe double IPsec encryption avoidance is something we should provide. And I like your suggested scheme of using "inner IP address + session-ID" to reject IPsec SA for the same inner address, for protection against the "inner address theft" attack. That seems still simple to me. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 15 19:58:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11378 for ; Thu, 15 Jan 2004 19:58:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIJF-0007Ni-Cq; Thu, 15 Jan 2004 19:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIJ7-0007Mr-5u for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11310 for ; Thu, 15 Jan 2004 19:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIJ5-0000rg-00 for pana@ietf.org; Thu, 15 Jan 2004 19:57:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhII8-0000p8-00 for pana@ietf.org; Thu, 15 Jan 2004 19:56:53 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhIHI-0000nD-00 for pana@ietf.org; Thu, 15 Jan 2004 19:56:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0G0tvN9005434; Fri, 16 Jan 2004 09:55:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0G0tvlQ023534; Fri, 16 Jan 2004 09:55:57 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA23531 ; Fri, 16 Jan 2004 09:55:57 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA18537; Fri, 16 Jan 2004 09:55:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA00934; Fri, 16 Jan 2004 09:55:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0G0tpXD012852; Fri, 16 Jan 2004 09:55:52 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRK006M0591D7@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 09:55:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhIFZ-00034A-00; Thu, 15 Jan 2004 16:54:13 -0800 Date: Thu, 15 Jan 2004 16:54:13 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00b701c3dbc4$7284bac0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116005413.GE9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Mohan, On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > mode SA). This may be different from any of above three cases, > > because DHCP SA is created by "using IKE" but DHCP messages are not > > carried in IKE payloads. > > > This is what we have discussed before in a different context. But i am not > going to discuss it in this draft. Any specific reason for not discussing RFC 3456 in this draft? Otherwise, I prefer mention it to cover possible cases as much as possible. > > > > > > > > > > > > > > In the case of auto-configuration > > > > (which includes global address or addresses configured as in > > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > > > We should qualify which address we are talking about here. I think it is the > > > > inner IP address. > > > > > > > Okay. I will clarify this. > > > > > > > Thus, > > > > it may not be able to setup the SPD entries appropriately before > > > > IKE exchange starts. As most of the IKE implementations assume > > > > that the SPD can be consulted during the SA negotiation, it may > > > > require slightly a different behavior from IKE in the auto- > > > > configuration case. In the case of auto-configuration, IKE > > > > should be able to setup the SAs for the traffic selectors > > > > specified by the PaC without consulting the SPD entry. If there > > > > is already an SA for the same address, then the SA request MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > for protecting the subsequent data packets. > > > > > > > > Does this require any modifications to the IKE protocol, or simply > > > > implementation modification is sufficient? > > > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > > > What is the probelm in the case of auto-configuration if IKE is not > > able to setup the SAs for the traffic selectors specified by the PaC > > without consulting the SPD entry? > > > The one mentioned in the security consideration. EP is blindly trusting > what the PaC is saying about the inner addresses i.e clients can spoof. > But it is not the same as service theft that we discussed in the > threats document. The PaC still needs to have the right keys. And > the addresses assigned are temporary. So, i really don't see a big > issue with this. > > I think "consulting the SPD entry" is too concise to understand that it is related to the inner address theft attack. How about this? "consulting the SPD entry in order to make sure that the specified inner address is not used by other PaC." Also: "In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. " ^^^^^^^ Do you mean "with" here? Because according to the discussion, SPD entry check is something needs to be performed to protect from "inner address theft" attack. Or I may be misunderstanding something. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 15 20:00:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11441 for ; Thu, 15 Jan 2004 20:00:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIL0-0007SQ-Fz for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:59:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G0xo6w028660 for pana-archive@odin.ietf.org; Thu, 15 Jan 2004 19:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIL0-0007SB-BI for pana-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 19:59:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11405 for ; Thu, 15 Jan 2004 19:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIKy-0000yM-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:59:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhIK5-0000vY-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:58:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhIJG-0000tT-00 for pana-web-archive@ietf.org; Thu, 15 Jan 2004 19:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIJF-0007Ni-Cq; Thu, 15 Jan 2004 19:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhIJ7-0007Mr-5u for pana@optimus.ietf.org; Thu, 15 Jan 2004 19:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11310 for ; Thu, 15 Jan 2004 19:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhIJ5-0000rg-00 for pana@ietf.org; Thu, 15 Jan 2004 19:57:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhII8-0000p8-00 for pana@ietf.org; Thu, 15 Jan 2004 19:56:53 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhIHI-0000nD-00 for pana@ietf.org; Thu, 15 Jan 2004 19:56:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0G0tvN9005434; Fri, 16 Jan 2004 09:55:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0G0tvlQ023534; Fri, 16 Jan 2004 09:55:57 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA23531 ; Fri, 16 Jan 2004 09:55:57 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA18537; Fri, 16 Jan 2004 09:55:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA00934; Fri, 16 Jan 2004 09:55:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0G0tpXD012852; Fri, 16 Jan 2004 09:55:52 +0900 (JST) Received: from steelhead ([159.119.168.147]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRK006M0591D7@tsbpo1.po.toshiba.co.jp>; Fri, 16 Jan 2004 09:55:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhIFZ-00034A-00; Thu, 15 Jan 2004 16:54:13 -0800 Date: Thu, 15 Jan 2004 16:54:13 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00b701c3dbc4$7284bac0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116005413.GE9900@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Mohan, On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > mode SA). This may be different from any of above three cases, > > because DHCP SA is created by "using IKE" but DHCP messages are not > > carried in IKE payloads. > > > This is what we have discussed before in a different context. But i am not > going to discuss it in this draft. Any specific reason for not discussing RFC 3456 in this draft? Otherwise, I prefer mention it to cover possible cases as much as possible. > > > > > > > > > > > > > > In the case of auto-configuration > > > > (which includes global address or addresses configured as in > > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > > > We should qualify which address we are talking about here. I think it is the > > > > inner IP address. > > > > > > > Okay. I will clarify this. > > > > > > > Thus, > > > > it may not be able to setup the SPD entries appropriately before > > > > IKE exchange starts. As most of the IKE implementations assume > > > > that the SPD can be consulted during the SA negotiation, it may > > > > require slightly a different behavior from IKE in the auto- > > > > configuration case. In the case of auto-configuration, IKE > > > > should be able to setup the SAs for the traffic selectors > > > > specified by the PaC without consulting the SPD entry. If there > > > > is already an SA for the same address, then the SA request MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > for protecting the subsequent data packets. > > > > > > > > Does this require any modifications to the IKE protocol, or simply > > > > implementation modification is sufficient? > > > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > > > What is the probelm in the case of auto-configuration if IKE is not > > able to setup the SAs for the traffic selectors specified by the PaC > > without consulting the SPD entry? > > > The one mentioned in the security consideration. EP is blindly trusting > what the PaC is saying about the inner addresses i.e clients can spoof. > But it is not the same as service theft that we discussed in the > threats document. The PaC still needs to have the right keys. And > the addresses assigned are temporary. So, i really don't see a big > issue with this. > > I think "consulting the SPD entry" is too concise to understand that it is related to the inner address theft attack. How about this? "consulting the SPD entry in order to make sure that the specified inner address is not used by other PaC." Also: "In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. " ^^^^^^^ Do you mean "with" here? Because according to the discussion, SPD entry check is something needs to be performed to protect from "inner address theft" attack. Or I may be misunderstanding something. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 00:33:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17684 for ; Fri, 16 Jan 2004 00:33:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMbN-00025o-6i; Fri, 16 Jan 2004 00:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMbK-00025Y-Jj for pana@optimus.ietf.org; Fri, 16 Jan 2004 00:32:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17668 for ; Fri, 16 Jan 2004 00:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhMbI-000392-00 for pana@ietf.org; Fri, 16 Jan 2004 00:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhMaK-00037r-00 for pana@ietf.org; Fri, 16 Jan 2004 00:31:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AhMZj-00036e-00 for pana@ietf.org; Fri, 16 Jan 2004 00:31:19 -0500 Date: Thu, 15 Jan 2004 21:31:10 -0800 Subject: Re: [Pana] PANA-IPsec-01 From: Alper Yegin To: Yoshihiro Ohba CC: Mohan Parthasarathy , Message-ID: In-Reply-To: <20040115224752.GB9900@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> Passing the MSK to the EP runs the risk that, any other key derived off of >> MSK can also be generated by the EP. This is why I was saying maybe we >> shouldn't even use PANA SA key, but some other key generated from it. > > I was thinking that the calculated IKE pre-shared key is passed to EP > (over secure SNMPv3 communication) and MSK itself is not passed. > Is this danger? OK, I thought we were passing the MSK to EP. That's not the case, hence use of MSK in the calculation should be fine. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 00:35:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17775 for ; Fri, 16 Jan 2004 00:35:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMdI-0002Dt-1j for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 00:35:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G5Z0xW008539 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 00:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMdH-0002De-RO for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 00:34:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17713 for ; Fri, 16 Jan 2004 00:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhMdF-0003F1-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 00:34:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhMcI-0003B7-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 00:33:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhMbQ-00039Q-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 00:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMbN-00025o-6i; Fri, 16 Jan 2004 00:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhMbK-00025Y-Jj for pana@optimus.ietf.org; Fri, 16 Jan 2004 00:32:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17668 for ; Fri, 16 Jan 2004 00:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhMbI-000392-00 for pana@ietf.org; Fri, 16 Jan 2004 00:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhMaK-00037r-00 for pana@ietf.org; Fri, 16 Jan 2004 00:31:57 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AhMZj-00036e-00 for pana@ietf.org; Fri, 16 Jan 2004 00:31:19 -0500 Date: Thu, 15 Jan 2004 21:31:10 -0800 Subject: Re: [Pana] PANA-IPsec-01 From: Alper Yegin To: Yoshihiro Ohba CC: Mohan Parthasarathy , Message-ID: In-Reply-To: <20040115224752.GB9900@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> Passing the MSK to the EP runs the risk that, any other key derived off of >> MSK can also be generated by the EP. This is why I was saying maybe we >> shouldn't even use PANA SA key, but some other key generated from it. > > I was thinking that the calculated IKE pre-shared key is passed to EP > (over secure SNMPv3 communication) and MSK itself is not passed. > Is this danger? OK, I thought we were passing the MSK to EP. That's not the case, hence use of MSK in the calculation should be fine. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 04:24:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06362 for ; Fri, 16 Jan 2004 04:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQCv-0007Bq-Dq; Fri, 16 Jan 2004 04:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQC2-0007AI-5A for pana@optimus.ietf.org; Fri, 16 Jan 2004 04:23:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06343 for ; Fri, 16 Jan 2004 04:23:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhQBz-0005Yz-00 for pana@ietf.org; Fri, 16 Jan 2004 04:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhQB1-0005XV-00 for pana@ietf.org; Fri, 16 Jan 2004 04:22:03 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AhQAK-0005WG-00 for pana@ietf.org; Fri, 16 Jan 2004 04:21:21 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0G9LLY12104 for ; Fri, 16 Jan 2004 11:21:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 Jan 2004 11:21:18 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 11:21:21 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 11:21:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PANA-Start-Request/Answer Date: Fri, 16 Jan 2004 11:21:20 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PANA-Start-Request/Answer Thread-Index: AcPbrgCGj0V2agLvSvCeedT5GjafJwAY/bWw To: , X-OriginalArrivalTime: 16 Jan 2004 09:21:20.0872 (UTC) FILETIME=[1A817680:01C3DC12] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Yoshi, It's now on the issue tracker: http://danforsberg.info:8080/pana-issues/issue44 I agree on the proposed text. Br, - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 15 January, 2004 22:13 > To: pana@ietf.org > Subject: [Pana] EAP-Payload in PANA-Start-Request/Answer > > > I think the following discussion does not appear on the issue list: > > http://www1.ietf.org/mail-archive/working-groups/pana/current/ > msg00122.html > > Here is the suggested change. > > In section 4.1, add: > > "When a Cookie-AVP is carried in a PANA-Start-Request message, the > initial EAP Request MUST NOT be carried in the PANA-Start-Request > message in order for the PAA to be stateless. > > When a Cookie-AVP is not carried in a PANA-Start-Request message, > the PAA does not need to be stateless. In this case, the initial EAP > Request message MAY be carried in the PANA-Start-Request message. > > If the initial EAP Request message is carried in the > PANA-Start-Request message, an EAP Response message MUST be carried in > the PANA-Start-Answer message returned to the PAA. > > In any case, PANA MUST NOT generate an EAP message on behalf of EAP > peer or EAP (pass-through) authenticator." > > In section 9.3.3, change: > > " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ]" > > to: > > " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ]" > > > > In section 9.3.4, change: > > " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > > [ Cookie ] > [ ISP-Information ] > * [ AVP ]" > > > To: > > " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ ISP-Information ] > * [ AVP ]" > > > > In section 9.5, change: > > " +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0 | 0 | 1 | 1 | 1 | 0 | 0 |" > > > to: > > " +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 |" > > > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 04:26:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06401 for ; Fri, 16 Jan 2004 04:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQEv-0007HN-9p for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 04:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0G9Q5RK027982 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 04:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQEu-0007HF-PB for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 04:26:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06389 for ; Fri, 16 Jan 2004 04:26:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhQEs-0005dm-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 04:26:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhQDt-0005cA-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 04:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhQCw-0005aW-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 04:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQCv-0007Bq-Dq; Fri, 16 Jan 2004 04:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhQC2-0007AI-5A for pana@optimus.ietf.org; Fri, 16 Jan 2004 04:23:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06343 for ; Fri, 16 Jan 2004 04:23:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhQBz-0005Yz-00 for pana@ietf.org; Fri, 16 Jan 2004 04:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhQB1-0005XV-00 for pana@ietf.org; Fri, 16 Jan 2004 04:22:03 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AhQAK-0005WG-00 for pana@ietf.org; Fri, 16 Jan 2004 04:21:21 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0G9LLY12104 for ; Fri, 16 Jan 2004 11:21:21 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 16 Jan 2004 11:21:18 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 11:21:21 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 16 Jan 2004 11:21:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PANA-Start-Request/Answer Date: Fri, 16 Jan 2004 11:21:20 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PANA-Start-Request/Answer Thread-Index: AcPbrgCGj0V2agLvSvCeedT5GjafJwAY/bWw To: , X-OriginalArrivalTime: 16 Jan 2004 09:21:20.0872 (UTC) FILETIME=[1A817680:01C3DC12] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Yoshi, It's now on the issue tracker: http://danforsberg.info:8080/pana-issues/issue44 I agree on the proposed text. Br, - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 15 January, 2004 22:13 > To: pana@ietf.org > Subject: [Pana] EAP-Payload in PANA-Start-Request/Answer > > > I think the following discussion does not appear on the issue list: > > http://www1.ietf.org/mail-archive/working-groups/pana/current/ > msg00122.html > > Here is the suggested change. > > In section 4.1, add: > > "When a Cookie-AVP is carried in a PANA-Start-Request message, the > initial EAP Request MUST NOT be carried in the PANA-Start-Request > message in order for the PAA to be stateless. > > When a Cookie-AVP is not carried in a PANA-Start-Request message, > the PAA does not need to be stateless. In this case, the initial EAP > Request message MAY be carried in the PANA-Start-Request message. > > If the initial EAP Request message is carried in the > PANA-Start-Request message, an EAP Response message MUST be carried in > the PANA-Start-Answer message returned to the PAA. > > In any case, PANA MUST NOT generate an EAP message on behalf of EAP > peer or EAP (pass-through) authenticator." > > In section 9.3.3, change: > > " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ]" > > to: > > " PANA-Start-Request ::= < PANA-Header: 2, REQ [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ NAP-Information ] > * [ ISP-Information ] > * [ AVP ]" > > > > In section 9.3.4, change: > > " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > > [ Cookie ] > [ ISP-Information ] > * [ AVP ]" > > > To: > > " PANA-Start-Answer ::= < PANA-Header: 2 [SEP] > > [ Cookie ] > [ EAP-Payload ] > [ ISP-Information ] > * [ AVP ]" > > > > In section 9.5, change: > > " +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0 | 0 | 1 | 1 | 1 | 0 | 0 |" > > > to: > > " +-----------------------------------------+ > | Message | > | Type | > +-----+-----+-----+-----+-----+-----+-----+ > Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | > --------------------+-----+-----+-----+-----+-----+-----+-----+ > Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | > Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0 | > Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 |" > > > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 12:17:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21836 for ; Fri, 16 Jan 2004 12:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXae-0005pR-Vf; Fri, 16 Jan 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXZW-0005mH-2x for pana@optimus.ietf.org; Fri, 16 Jan 2004 12:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21798 for ; Fri, 16 Jan 2004 12:15:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXZK-00019w-00 for pana@ietf.org; Fri, 16 Jan 2004 12:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXWr-00013D-00 for pana@ietf.org; Fri, 16 Jan 2004 12:13:06 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhXUs-0000xU-00 for pana@ietf.org; Fri, 16 Jan 2004 12:11:02 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0GHATN9019589; Sat, 17 Jan 2004 02:10:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0GHAT40005010; Sat, 17 Jan 2004 02:10:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA05009 ; Sat, 17 Jan 2004 02:10:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA29503; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA29906; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0GHARXD012333; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from steelhead ([159.119.168.63]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00C19EDDW1@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 02:10:26 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhXOa-0003mG-00; Fri, 16 Jan 2004 09:04:32 -0800 Date: Fri, 16 Jan 2004 09:04:32 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00c701c3dbc5$72b12c80$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116170432.GB14453@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Mohan, I have one more comment. According to the current IKE pre-shared key derivation algorithm, when the PAA controls multiple EPs, the same IKE pre-shared key for a particular PANA session will be shared one or more EPs. I think this is not desirable from the viewpoint of key management philosophy. So, it might be better to include EP device identifier in the key computation algorithm. What do you think? Yoshihiro Ohba On Thu, Jan 15, 2004 at 04:12:37PM -0800, Mohan Parthasarathy wrote: > > > > > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > > >>> > > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > >>> Session ID | MSK-ID) > > > >>> > > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > >>> another key driven from PANA SA Key??) > > > >>> > > > >> I have to think more on this to understand the difference. > > > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > > Unless there is a specific reason for the two keys to be > > > > cryptographycally dependent, I think using the MSK is stronger (and > > > > better). > > > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > > MSK can also be generated by the EP. This is why I was saying maybe we > > > shouldn't even use PANA SA key, but some other key generated from it. > > > > I was thinking that the calculated IKE pre-shared key is passed to EP > > (over secure SNMPv3 communication) and MSK itself is not passed. > > Is this danger? > > > This is what is mentioned in the IPsec draft in section 4.0. > > -mohan > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 12:22:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21951 for ; Fri, 16 Jan 2004 12:22:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXfK-0005zk-76 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 12:21:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GHLo8s023040 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 12:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXfJ-0005zX-W9 for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 12:21:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21938 for ; Fri, 16 Jan 2004 12:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXfD-0001Ss-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 12:21:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXdS-0001KL-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 12:19:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhXb2-0001Do-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 12:17:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXae-0005pR-Vf; Fri, 16 Jan 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhXZW-0005mH-2x for pana@optimus.ietf.org; Fri, 16 Jan 2004 12:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21798 for ; Fri, 16 Jan 2004 12:15:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhXZK-00019w-00 for pana@ietf.org; Fri, 16 Jan 2004 12:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhXWr-00013D-00 for pana@ietf.org; Fri, 16 Jan 2004 12:13:06 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhXUs-0000xU-00 for pana@ietf.org; Fri, 16 Jan 2004 12:11:02 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0GHATN9019589; Sat, 17 Jan 2004 02:10:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0GHAT40005010; Sat, 17 Jan 2004 02:10:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA05009 ; Sat, 17 Jan 2004 02:10:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA29503; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA29906; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0GHARXD012333; Sat, 17 Jan 2004 02:10:28 +0900 (JST) Received: from steelhead ([159.119.168.63]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00C19EDDW1@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 02:10:26 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhXOa-0003mG-00; Fri, 16 Jan 2004 09:04:32 -0800 Date: Fri, 16 Jan 2004 09:04:32 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00c701c3dbc5$72b12c80$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040116170432.GB14453@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Mohan, I have one more comment. According to the current IKE pre-shared key derivation algorithm, when the PAA controls multiple EPs, the same IKE pre-shared key for a particular PANA session will be shared one or more EPs. I think this is not desirable from the viewpoint of key management philosophy. So, it might be better to include EP device identifier in the key computation algorithm. What do you think? Yoshihiro Ohba On Thu, Jan 15, 2004 at 04:12:37PM -0800, Mohan Parthasarathy wrote: > > > > > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > > >>> > > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > >>> Session ID | MSK-ID) > > > >>> > > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > >>> another key driven from PANA SA Key??) > > > >>> > > > >> I have to think more on this to understand the difference. > > > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > > Unless there is a specific reason for the two keys to be > > > > cryptographycally dependent, I think using the MSK is stronger (and > > > > better). > > > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > > MSK can also be generated by the EP. This is why I was saying maybe we > > > shouldn't even use PANA SA key, but some other key generated from it. > > > > I was thinking that the calculated IKE pre-shared key is passed to EP > > (over secure SNMPv3 communication) and MSK itself is not passed. > > Is this danger? > > > This is what is mentioned in the IPsec draft in section 4.0. > > -mohan > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 16:50:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01337 for ; Fri, 16 Jan 2004 16:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahbqs-0006du-QG; Fri, 16 Jan 2004 16:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbqL-0006cw-Sb for pana@optimus.ietf.org; Fri, 16 Jan 2004 16:49:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01287 for ; Fri, 16 Jan 2004 16:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhbqJ-00074h-00 for pana@ietf.org; Fri, 16 Jan 2004 16:49:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhbpP-00072R-00 for pana@ietf.org; Fri, 16 Jan 2004 16:48:31 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1Ahbol-00070I-00 for pana@ietf.org; Fri, 16 Jan 2004 16:47:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 21:47:49 -0000 Message-ID: <006201c3dc7a$61d1b500$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Fri, 16 Jan 2004 13:47:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hi Mohan, > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > mode SA). This may be different from any of above three cases, > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > carried in IKE payloads. > > > > > This is what we have discussed before in a different context. But i am not > > going to discuss it in this draft. > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > I prefer mention it to cover possible cases as much as possible. > I thought a bit about this. These are the two methods. 1st method. --------------- 1) Authenticate using PANA (link-local address is used for communication) 2) Client does DHCP to get an inner address. Create state about what address was assigned to the PaC i.e " IP address - SessionID" mapping so that it can ve verified later as explained below. 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification as mentioned in step (2) before setting up the SAs. 2nd method (RFC 3456) ----------------- 1) Authenticate using PANA (link-local address is used for communication) 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this SA to get an IP address. 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. If we have to mention both, we need to specify more details like the above. Is that what you are suggesting ? > > > > > > > > > > > > > > > > > > > In the case of auto-configuration > > > > > (which includes global address or addresses configured as in > > > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > > > > > We should qualify which address we are talking about here. I think it is the > > > > > inner IP address. > > > > > > > > > Okay. I will clarify this. > > > > > > > > > Thus, > > > > > it may not be able to setup the SPD entries appropriately before > > > > > IKE exchange starts. As most of the IKE implementations assume > > > > > that the SPD can be consulted during the SA negotiation, it may > > > > > require slightly a different behavior from IKE in the auto- > > > > > configuration case. In the case of auto-configuration, IKE > > > > > should be able to setup the SAs for the traffic selectors > > > > > specified by the PaC without consulting the SPD entry. If there > > > > > is already an SA for the same address, then the SA request MUST > > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > > authenticates itself successfully, EP should add the SPD entry > > > > > for protecting the subsequent data packets. > > > > > > > > > > Does this require any modifications to the IKE protocol, or simply > > > > > implementation modification is sufficient? > > > > > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > > > > > What is the probelm in the case of auto-configuration if IKE is not > > > able to setup the SAs for the traffic selectors specified by the PaC > > > without consulting the SPD entry? > > > > > The one mentioned in the security consideration. EP is blindly trusting > > what the PaC is saying about the inner addresses i.e clients can spoof. > > But it is not the same as service theft that we discussed in the > > threats document. The PaC still needs to have the right keys. And > > the addresses assigned are temporary. So, i really don't see a big > > issue with this. > > > > > > I think "consulting the SPD entry" is too concise to understand that it is > related to the inner address theft attack. > > How about this? > > "consulting the SPD entry in order to make sure that the specified > inner address is not used by other PaC." > Okay. > Also: > > "In the case of auto-configuration, IKE > should be able to setup the SAs for the traffic selectors > specified by the PaC without consulting the SPD entry. " > ^^^^^^^ > > Do you mean "with" here? Because according to the discussion, SPD > entry check is something needs to be performed to protect from "inner address > theft" attack. Or I may be misunderstanding something. > I think it is a bit confusing. At the beginning, there are really no SPD entries. When the first client authenticates, you still consult the SPD table but it has no entry. SPD entries are created dynamically for this client and subsequent ones. So, the above is trying to say that there is no pre-configured entry for the client in the SPD that is doing the IKE/IPsec negotiation. But you have to consult the SPD so that there is no such entry already there. Perhaps it needs some more wording. Makes sense ? -mohan > Yoshihiro Ohba > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 16:53:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01410 for ; Fri, 16 Jan 2004 16:53:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahbtc-0006mA-29 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 16:52:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0GLqqKc026042 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 16:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahbtb-0006lx-Ob for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 16:52:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01403 for ; Fri, 16 Jan 2004 16:52:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhbtU-0007Cf-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 16:52:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhbrM-00078S-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 16:50:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ahbqx-00076D-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 16:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahbqs-0006du-QG; Fri, 16 Jan 2004 16:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhbqL-0006cw-Sb for pana@optimus.ietf.org; Fri, 16 Jan 2004 16:49:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01287 for ; Fri, 16 Jan 2004 16:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhbqJ-00074h-00 for pana@ietf.org; Fri, 16 Jan 2004 16:49:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhbpP-00072R-00 for pana@ietf.org; Fri, 16 Jan 2004 16:48:31 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1Ahbol-00070I-00 for pana@ietf.org; Fri, 16 Jan 2004 16:47:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 16 Jan 2004 21:47:49 -0000 Message-ID: <006201c3dc7a$61d1b500$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Fri, 16 Jan 2004 13:47:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hi Mohan, > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > mode SA). This may be different from any of above three cases, > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > carried in IKE payloads. > > > > > This is what we have discussed before in a different context. But i am not > > going to discuss it in this draft. > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > I prefer mention it to cover possible cases as much as possible. > I thought a bit about this. These are the two methods. 1st method. --------------- 1) Authenticate using PANA (link-local address is used for communication) 2) Client does DHCP to get an inner address. Create state about what address was assigned to the PaC i.e " IP address - SessionID" mapping so that it can ve verified later as explained below. 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification as mentioned in step (2) before setting up the SAs. 2nd method (RFC 3456) ----------------- 1) Authenticate using PANA (link-local address is used for communication) 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this SA to get an IP address. 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. If we have to mention both, we need to specify more details like the above. Is that what you are suggesting ? > > > > > > > > > > > > > > > > > > > In the case of auto-configuration > > > > > (which includes global address or addresses configured as in > > > > > [PRIV]), EP may not know the address assigned to the PaC. > > > > > > > > > > We should qualify which address we are talking about here. I think it is the > > > > > inner IP address. > > > > > > > > > Okay. I will clarify this. > > > > > > > > > Thus, > > > > > it may not be able to setup the SPD entries appropriately before > > > > > IKE exchange starts. As most of the IKE implementations assume > > > > > that the SPD can be consulted during the SA negotiation, it may > > > > > require slightly a different behavior from IKE in the auto- > > > > > configuration case. In the case of auto-configuration, IKE > > > > > should be able to setup the SAs for the traffic selectors > > > > > specified by the PaC without consulting the SPD entry. If there > > > > > is already an SA for the same address, then the SA request MUST > > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > > authenticates itself successfully, EP should add the SPD entry > > > > > for protecting the subsequent data packets. > > > > > > > > > > Does this require any modifications to the IKE protocol, or simply > > > > > implementation modification is sufficient? > > > > > > > > > Implementation should be sufficient. Racoon seems to have this knob. > > > > > > What is the probelm in the case of auto-configuration if IKE is not > > > able to setup the SAs for the traffic selectors specified by the PaC > > > without consulting the SPD entry? > > > > > The one mentioned in the security consideration. EP is blindly trusting > > what the PaC is saying about the inner addresses i.e clients can spoof. > > But it is not the same as service theft that we discussed in the > > threats document. The PaC still needs to have the right keys. And > > the addresses assigned are temporary. So, i really don't see a big > > issue with this. > > > > > > I think "consulting the SPD entry" is too concise to understand that it is > related to the inner address theft attack. > > How about this? > > "consulting the SPD entry in order to make sure that the specified > inner address is not used by other PaC." > Okay. > Also: > > "In the case of auto-configuration, IKE > should be able to setup the SAs for the traffic selectors > specified by the PaC without consulting the SPD entry. " > ^^^^^^^ > > Do you mean "with" here? Because according to the discussion, SPD > entry check is something needs to be performed to protect from "inner address > theft" attack. Or I may be misunderstanding something. > I think it is a bit confusing. At the beginning, there are really no SPD entries. When the first client authenticates, you still consult the SPD table but it has no entry. SPD entries are created dynamically for this client and subsequent ones. So, the above is trying to say that there is no pre-configured entry for the client in the SPD that is doing the IKE/IPsec negotiation. But you have to consult the SPD so that there is no such entry already there. Perhaps it needs some more wording. Makes sense ? -mohan > Yoshihiro Ohba > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 19:49:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07904 for ; Fri, 16 Jan 2004 19:49:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahed7-0008Nw-3r; Fri, 16 Jan 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheck-0008NH-0F for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07860 for ; Fri, 16 Jan 2004 19:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aheci-0000om-00 for pana@ietf.org; Fri, 16 Jan 2004 19:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahebl-0000mM-00 for pana@ietf.org; Fri, 16 Jan 2004 19:46:38 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1Aheaz-0000kA-00 for pana@ietf.org; Fri, 16 Jan 2004 19:45:49 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 17 Jan 2004 00:45:45 -0000 Message-ID: <016401c3dc93$3d0e81d0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> <20040116170432.GB14453@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Fri, 16 Jan 2004 16:45:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hi Mohan, > > I have one more comment. > > According to the current IKE pre-shared key derivation algorithm, when > the PAA controls multiple EPs, the same IKE pre-shared key for a > particular PANA session will be shared one or more EPs. I think this > is not desirable from the viewpoint of key management philosophy. So, > it might be better to include EP device identifier in the key > computation algorithm. > > What do you think? > Agreed. The one that needs inclusion in the derivation is IP address of the EP that PaC learns before the IKE exchange starts. I guess it is the same as the device identifier of EP that you mention. -mohan > Yoshihiro Ohba > > > On Thu, Jan 15, 2004 at 04:12:37PM -0800, Mohan Parthasarathy wrote: > > > > > > > > > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > > > >>> > > > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > > >>> Session ID | MSK-ID) > > > > >>> > > > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > > >>> another key driven from PANA SA Key??) > > > > >>> > > > > >> I have to think more on this to understand the difference. > > > > > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > > > Unless there is a specific reason for the two keys to be > > > > > cryptographycally dependent, I think using the MSK is stronger (and > > > > > better). > > > > > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > > > MSK can also be generated by the EP. This is why I was saying maybe we > > > > shouldn't even use PANA SA key, but some other key generated from it. > > > > > > I was thinking that the calculated IKE pre-shared key is passed to EP > > > (over secure SNMPv3 communication) and MSK itself is not passed. > > > Is this danger? > > > > > This is what is mentioned in the IPsec draft in section 4.0. > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 19:50:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08017 for ; Fri, 16 Jan 2004 19:50:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheek-0008W3-M8 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 19:49:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H0ngNg032731 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 19:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheek-0008Vq-IR for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 19:49:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07983 for ; Fri, 16 Jan 2004 19:49:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aheei-0000xW-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahedl-0000sz-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:48:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ahed8-0000pk-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahed6-0008No-RN; Fri, 16 Jan 2004 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahecg-0008NC-O0 for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07848 for ; Fri, 16 Jan 2004 19:47:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahece-0000oI-00 for pana@ietf.org; Fri, 16 Jan 2004 19:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahebg-0000lW-00 for pana@ietf.org; Fri, 16 Jan 2004 19:46:32 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aheak-0000iv-00 for pana@ietf.org; Fri, 16 Jan 2004 19:45:34 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0jWN9009869; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0jWB4026195; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA26194 ; Sat, 17 Jan 2004 09:45:32 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA01640; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA10370; Sat, 17 Jan 2004 09:45:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0jTXD025625; Sat, 17 Jan 2004 09:45:30 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00M68ZFSKZ@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:45:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AheZE-0004jr-00; Fri, 16 Jan 2004 16:44:00 -0800 Date: Fri, 16 Jan 2004 16:44:00 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040117004400.GF17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] EAP-Payload in PBR (new issue) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In the current PANA spec, EAP-Payload AVP is a required AVP for PANA-Bind-Request. However, it is possible that EAP conversation fails without generating a EAP-Success or EAP-Failure message, specifically when a AAA timeout occurs (please see EAP Full Authenticator State Machine diagram in the EAP state machines draft, pdf version). Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 19:50:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08034 for ; Fri, 16 Jan 2004 19:50:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheel-0008WN-9b for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 19:49:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H0nhCH032749 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 19:49:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheel-0008W8-58 for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 19:49:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07987 for ; Fri, 16 Jan 2004 19:49:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aheej-0000xb-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:49:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahedm-0000t7-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:48:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ahed8-0000pl-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 19:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahed7-0008Nw-3r; Fri, 16 Jan 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheck-0008NH-0F for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:47:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07860 for ; Fri, 16 Jan 2004 19:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aheci-0000om-00 for pana@ietf.org; Fri, 16 Jan 2004 19:47:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahebl-0000mM-00 for pana@ietf.org; Fri, 16 Jan 2004 19:46:38 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1Aheaz-0000kA-00 for pana@ietf.org; Fri, 16 Jan 2004 19:45:49 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 17 Jan 2004 00:45:45 -0000 Message-ID: <016401c3dc93$3d0e81d0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> <20040116170432.GB14453@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Fri, 16 Jan 2004 16:45:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hi Mohan, > > I have one more comment. > > According to the current IKE pre-shared key derivation algorithm, when > the PAA controls multiple EPs, the same IKE pre-shared key for a > particular PANA session will be shared one or more EPs. I think this > is not desirable from the viewpoint of key management philosophy. So, > it might be better to include EP device identifier in the key > computation algorithm. > > What do you think? > Agreed. The one that needs inclusion in the derivation is IP address of the EP that PaC learns before the IKE exchange starts. I guess it is the same as the device identifier of EP that you mention. -mohan > Yoshihiro Ohba > > > On Thu, Jan 15, 2004 at 04:12:37PM -0800, Mohan Parthasarathy wrote: > > > > > > > > > On Thu, Jan 15, 2004 at 02:10:34PM -0800, Alper Yegin wrote: > > > > >>> > > > > >>> IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | > > > > >>> Session ID | MSK-ID) > > > > >>> > > > > >>> I think we should be using PANA SA Key instead of MSK. (or, maybe even > > > > >>> another key driven from PANA SA Key??) > > > > >>> > > > > >> I have to think more on this to understand the difference. > > > > > > > > > > The difference would be whether the IKE pre-shared key and PANA SA key > > > > > becomes cryptographycally separate or not. By using the MSK, the IKE > > > > > pre-shared key and PANA SA key are cryptographycally indepenent. > > > > > Unless there is a specific reason for the two keys to be > > > > > cryptographycally dependent, I think using the MSK is stronger (and > > > > > better). > > > > > > > > Passing the MSK to the EP runs the risk that, any other key derived off of > > > > MSK can also be generated by the EP. This is why I was saying maybe we > > > > shouldn't even use PANA SA key, but some other key generated from it. > > > > > > I was thinking that the calculated IKE pre-shared key is passed to EP > > > (over secure SNMPv3 communication) and MSK itself is not passed. > > > Is this danger? > > > > > This is what is mentioned in the IPsec draft in section 4.0. > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 20:00:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08202 for ; Fri, 16 Jan 2004 20:00:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheom-0000b2-0I; Fri, 16 Jan 2004 20:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahenl-0000Sb-J1 for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08161 for ; Fri, 16 Jan 2004 19:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahene-0001KB-00 for pana@ietf.org; Fri, 16 Jan 2004 19:58:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhelF-0001EM-00 for pana@ietf.org; Fri, 16 Jan 2004 19:56:26 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhejN-00019Q-00 for pana@ietf.org; Fri, 16 Jan 2004 19:54:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0sHN9012244; Sat, 17 Jan 2004 09:54:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0sHIl000043; Sat, 17 Jan 2004 09:54:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA00042 ; Sat, 17 Jan 2004 09:54:17 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA04526; Sat, 17 Jan 2004 09:54:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA23063; Sat, 17 Jan 2004 09:54:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0sEXD027026; Sat, 17 Jan 2004 09:54:14 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00M1VZUCP2@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:54:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AheiI-0004lX-00; Fri, 16 Jan 2004 16:53:22 -0800 Date: Fri, 16 Jan 2004 16:53:22 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <016401c3dc93$3d0e81d0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040117005322.GG17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> <20040116170432.GB14453@steelhead> <016401c3dc93$3d0e81d0$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Jan 16, 2004 at 04:45:43PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > I have one more comment. > > > > According to the current IKE pre-shared key derivation algorithm, when > > the PAA controls multiple EPs, the same IKE pre-shared key for a > > particular PANA session will be shared one or more EPs. I think this > > is not desirable from the viewpoint of key management philosophy. So, > > it might be better to include EP device identifier in the key > > computation algorithm. > > > > What do you think? > > > Agreed. The one that needs inclusion in the derivation is IP address of the EP that > PaC learns before the IKE exchange starts. I guess it is the same as the device > identifier of EP that you mention. Yes, that's what I meant. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 20:06:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08367 for ; Fri, 16 Jan 2004 20:06:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheun-0000yG-9p for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 20:06:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H16HiA003726 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 20:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheun-0000y1-5P for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 20:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08352 for ; Fri, 16 Jan 2004 20:06:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aheug-0001hV-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 20:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahers-0001Wf-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 20:03:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ahep6-0001OQ-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 20:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aheom-0000b2-0I; Fri, 16 Jan 2004 20:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahenl-0000Sb-J1 for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08161 for ; Fri, 16 Jan 2004 19:58:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahene-0001KB-00 for pana@ietf.org; Fri, 16 Jan 2004 19:58:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhelF-0001EM-00 for pana@ietf.org; Fri, 16 Jan 2004 19:56:26 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhejN-00019Q-00 for pana@ietf.org; Fri, 16 Jan 2004 19:54:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0sHN9012244; Sat, 17 Jan 2004 09:54:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0sHIl000043; Sat, 17 Jan 2004 09:54:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA00042 ; Sat, 17 Jan 2004 09:54:17 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA04526; Sat, 17 Jan 2004 09:54:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA23063; Sat, 17 Jan 2004 09:54:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0sEXD027026; Sat, 17 Jan 2004 09:54:14 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00M1VZUCP2@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:54:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AheiI-0004lX-00; Fri, 16 Jan 2004 16:53:22 -0800 Date: Fri, 16 Jan 2004 16:53:22 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <016401c3dc93$3d0e81d0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040117005322.GG17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040115031503.GC4868@steelhead> <20040115224752.GB9900@steelhead> <00c701c3dbc5$72b12c80$c91167c0@adithya> <20040116170432.GB14453@steelhead> <016401c3dc93$3d0e81d0$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, Jan 16, 2004 at 04:45:43PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > I have one more comment. > > > > According to the current IKE pre-shared key derivation algorithm, when > > the PAA controls multiple EPs, the same IKE pre-shared key for a > > particular PANA session will be shared one or more EPs. I think this > > is not desirable from the viewpoint of key management philosophy. So, > > it might be better to include EP device identifier in the key > > computation algorithm. > > > > What do you think? > > > Agreed. The one that needs inclusion in the derivation is IP address of the EP that > PaC learns before the IKE exchange starts. I guess it is the same as the device > identifier of EP that you mention. Yes, that's what I meant. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 20:38:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07905 for ; Fri, 16 Jan 2004 19:49:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahed6-0008No-RN; Fri, 16 Jan 2004 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ahecg-0008NC-O0 for pana@optimus.ietf.org; Fri, 16 Jan 2004 19:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07848 for ; Fri, 16 Jan 2004 19:47:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahece-0000oI-00 for pana@ietf.org; Fri, 16 Jan 2004 19:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahebg-0000lW-00 for pana@ietf.org; Fri, 16 Jan 2004 19:46:32 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aheak-0000iv-00 for pana@ietf.org; Fri, 16 Jan 2004 19:45:34 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H0jWN9009869; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H0jWB4026195; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA26194 ; Sat, 17 Jan 2004 09:45:32 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA01640; Sat, 17 Jan 2004 09:45:32 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA10370; Sat, 17 Jan 2004 09:45:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H0jTXD025625; Sat, 17 Jan 2004 09:45:30 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRL00M68ZFSKZ@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 09:45:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AheZE-0004jr-00; Fri, 16 Jan 2004 16:44:00 -0800 Date: Fri, 16 Jan 2004 16:44:00 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040117004400.GF17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] EAP-Payload in PBR (new issue) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , In the current PANA spec, EAP-Payload AVP is a required AVP for PANA-Bind-Request. However, it is possible that EAP conversation fails without generating a EAP-Success or EAP-Failure message, specifically when a AAA timeout occurs (please see EAP Full Authenticator State Machine diagram in the EAP state machines draft, pdf version). Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 16 21:42:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10450 for ; Fri, 16 Jan 2004 21:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgPR-0005L9-De; Fri, 16 Jan 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgP5-0005KL-Rp for pana@optimus.ietf.org; Fri, 16 Jan 2004 21:41:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10418 for ; Fri, 16 Jan 2004 21:41:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhgP3-0005QW-00 for pana@ietf.org; Fri, 16 Jan 2004 21:41:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhgOA-0005O9-00 for pana@ietf.org; Fri, 16 Jan 2004 21:40:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhgNM-0005M2-00 for pana@ietf.org; Fri, 16 Jan 2004 21:39:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H2dnN9016475; Sat, 17 Jan 2004 11:39:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H2dnjh023857; Sat, 17 Jan 2004 11:39:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA23856 ; Sat, 17 Jan 2004 11:39:48 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA12948; Sat, 17 Jan 2004 11:39:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA06587; Sat, 17 Jan 2004 11:39:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H2dkXD014010; Sat, 17 Jan 2004 11:39:46 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRM0032S4Q8WQ@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 11:39:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhgMC-0004zb-00; Fri, 16 Jan 2004 18:38:40 -0800 Date: Fri, 16 Jan 2004 18:38:40 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <006201c3dc7a$61d1b500$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040117023840.GH17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Jan 16, 2004 at 01:47:46PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > > mode SA). This may be different from any of above three cases, > > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > > carried in IKE payloads. > > > > > > > This is what we have discussed before in a different context. But i am not > > > going to discuss it in this draft. > > > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > > I prefer mention it to cover possible cases as much as possible. > > > I thought a bit about this. These are the two methods. > > 1st method. > --------------- > 1) Authenticate using PANA (link-local address is used for communication) > 2) Client does DHCP to get an inner address. Create state about what address > was assigned to the PaC i.e " IP address - SessionID" mapping so that it > can ve verified later as explained below. > 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification > as mentioned in step (2) before setting up the SAs. > > 2nd method (RFC 3456) > ----------------- > 1) Authenticate using PANA (link-local address is used for communication) > 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this > SA to get an IP address. > 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. > > If we have to mention both, we need to specify more details like the above. > Is that what you are suggesting ? I don't think we need more details like. My suggestion is that just mentioning all the four possible cases including RFC 3456 might be sufficient. I have some suggested text for it: "4) PaC configures a link-local address before the PANA protocol begins. At the end of authentication, it either acquires a globally reachable address using [DHCP][DHCPV6] before running IKE or IKEv2, running address configuration methods available within IKE or IKEv2 by using Configuration Payload or equivalent, running DHCP over a special IPsec tunnel mode SA [RFC3456], or auto-configures an address using stateless auto-configuration [IPV6-ND] before running IKE or IKEv2 if IPv6 is being used." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 16 21:44:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10522 for ; Fri, 16 Jan 2004 21:44:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgRB-0005Zb-NY for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 21:43:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0H2hnHc021417 for pana-archive@odin.ietf.org; Fri, 16 Jan 2004 21:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgRB-0005ZM-Gk for pana-web-archive@optimus.ietf.org; Fri, 16 Jan 2004 21:43:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10498 for ; Fri, 16 Jan 2004 21:43:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhgR8-0005Z9-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 21:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhgQ8-0005V2-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 21:42:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhgPS-0005Ru-00 for pana-web-archive@ietf.org; Fri, 16 Jan 2004 21:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgPR-0005L9-De; Fri, 16 Jan 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhgP5-0005KL-Rp for pana@optimus.ietf.org; Fri, 16 Jan 2004 21:41:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10418 for ; Fri, 16 Jan 2004 21:41:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhgP3-0005QW-00 for pana@ietf.org; Fri, 16 Jan 2004 21:41:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhgOA-0005O9-00 for pana@ietf.org; Fri, 16 Jan 2004 21:40:43 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AhgNM-0005M2-00 for pana@ietf.org; Fri, 16 Jan 2004 21:39:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0H2dnN9016475; Sat, 17 Jan 2004 11:39:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0H2dnjh023857; Sat, 17 Jan 2004 11:39:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA23856 ; Sat, 17 Jan 2004 11:39:48 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA12948; Sat, 17 Jan 2004 11:39:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA06587; Sat, 17 Jan 2004 11:39:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0H2dkXD014010; Sat, 17 Jan 2004 11:39:46 +0900 (JST) Received: from steelhead ([159.119.168.169]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRM0032S4Q8WQ@tsbpo1.po.toshiba.co.jp>; Sat, 17 Jan 2004 11:39:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AhgMC-0004zb-00; Fri, 16 Jan 2004 18:38:40 -0800 Date: Fri, 16 Jan 2004 18:38:40 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <006201c3dc7a$61d1b500$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040117023840.GH17343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Fri, Jan 16, 2004 at 01:47:46PM -0800, Mohan Parthasarathy wrote: > > > > Hi Mohan, > > > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > > mode SA). This may be different from any of above three cases, > > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > > carried in IKE payloads. > > > > > > > This is what we have discussed before in a different context. But i am not > > > going to discuss it in this draft. > > > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > > I prefer mention it to cover possible cases as much as possible. > > > I thought a bit about this. These are the two methods. > > 1st method. > --------------- > 1) Authenticate using PANA (link-local address is used for communication) > 2) Client does DHCP to get an inner address. Create state about what address > was assigned to the PaC i.e " IP address - SessionID" mapping so that it > can ve verified later as explained below. > 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification > as mentioned in step (2) before setting up the SAs. > > 2nd method (RFC 3456) > ----------------- > 1) Authenticate using PANA (link-local address is used for communication) > 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this > SA to get an IP address. > 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. > > If we have to mention both, we need to specify more details like the above. > Is that what you are suggesting ? I don't think we need more details like. My suggestion is that just mentioning all the four possible cases including RFC 3456 might be sufficient. I have some suggested text for it: "4) PaC configures a link-local address before the PANA protocol begins. At the end of authentication, it either acquires a globally reachable address using [DHCP][DHCPV6] before running IKE or IKEv2, running address configuration methods available within IKE or IKEv2 by using Configuration Payload or equivalent, running DHCP over a special IPsec tunnel mode SA [RFC3456], or auto-configures an address using stateless auto-configuration [IPV6-ND] before running IKE or IKEv2 if IPv6 is being used." Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 19 17:40:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12972 for ; Mon, 19 Jan 2004 17:40:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii3t-0001Bp-Jh; Mon, 19 Jan 2004 17:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii3h-0001BE-IS for pana@optimus.ietf.org; Mon, 19 Jan 2004 17:39:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12966 for ; Mon, 19 Jan 2004 17:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aii3f-00046r-00 for pana@ietf.org; Mon, 19 Jan 2004 17:39:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aii2j-000453-00 for pana@ietf.org; Mon, 19 Jan 2004 17:38:50 -0500 Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx with smtp (Exim 4.12) id 1Aii1m-00043A-00 for pana@ietf.org; Mon, 19 Jan 2004 17:37:50 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 19 Jan 2004 22:37:49 -0000 Message-ID: <015001c3dedc$ddfe2e60$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <20040117023840.GH17343@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Mon, 19 Jan 2004 14:37:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Fri, Jan 16, 2004 at 01:47:46PM -0800, Mohan Parthasarathy wrote: > > > > > > > Hi Mohan, > > > > > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > > > mode SA). This may be different from any of above three cases, > > > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > > > carried in IKE payloads. > > > > > > > > > This is what we have discussed before in a different context. But i am not > > > > going to discuss it in this draft. > > > > > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > > > I prefer mention it to cover possible cases as much as possible. > > > > > I thought a bit about this. These are the two methods. > > > > 1st method. > > --------------- > > 1) Authenticate using PANA (link-local address is used for communication) > > 2) Client does DHCP to get an inner address. Create state about what address > > was assigned to the PaC i.e " IP address - SessionID" mapping so that it > > can ve verified later as explained below. > > 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification > > as mentioned in step (2) before setting up the SAs. > > > > 2nd method (RFC 3456) > > ----------------- > > 1) Authenticate using PANA (link-local address is used for communication) > > 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this > > SA to get an IP address. > > 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. > > > > If we have to mention both, we need to specify more details like the above. > > Is that what you are suggesting ? > > > I don't think we need more details like. My suggestion is that > just mentioning all the four possible cases including RFC 3456 might > be sufficient. I have some suggested text for it: > > > "4) PaC configures a link-local address before the PANA protocol > begins. At the end of authentication, it either acquires a > globally reachable address using [DHCP][DHCPV6] before > running IKE or IKEv2, running address configuration > methods available within IKE or IKEv2 by using Configuration > Payload or equivalent, running DHCP over a > special IPsec tunnel mode SA [RFC3456], or auto-configures an > address using stateless auto-configuration [IPV6-ND] before > running IKE or IKEv2 if IPv6 is being used." > Ok. I am fine with this. -mohan -mohan > > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 19 17:42:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13055 for ; Mon, 19 Jan 2004 17:42:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii5e-0001IL-Rl for pana-archive@odin.ietf.org; Mon, 19 Jan 2004 17:41:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JMfocn004971 for pana-archive@odin.ietf.org; Mon, 19 Jan 2004 17:41:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii5e-0001I6-MT for pana-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 17:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13036 for ; Mon, 19 Jan 2004 17:41:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aii5c-0004DE-00 for pana-web-archive@ietf.org; Mon, 19 Jan 2004 17:41:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aii4i-0004Ah-00 for pana-web-archive@ietf.org; Mon, 19 Jan 2004 17:40:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aii3w-00048N-00 for pana-web-archive@ietf.org; Mon, 19 Jan 2004 17:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii3t-0001Bp-Jh; Mon, 19 Jan 2004 17:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aii3h-0001BE-IS for pana@optimus.ietf.org; Mon, 19 Jan 2004 17:39:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12966 for ; Mon, 19 Jan 2004 17:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aii3f-00046r-00 for pana@ietf.org; Mon, 19 Jan 2004 17:39:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aii2j-000453-00 for pana@ietf.org; Mon, 19 Jan 2004 17:38:50 -0500 Received: from smtp803.mail.sc5.yahoo.com ([66.163.168.182]) by ietf-mx with smtp (Exim 4.12) id 1Aii1m-00043A-00 for pana@ietf.org; Mon, 19 Jan 2004 17:37:50 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 19 Jan 2004 22:37:49 -0000 Message-ID: <015001c3dedc$ddfe2e60$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <20040117023840.GH17343@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Mon, 19 Jan 2004 14:37:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Fri, Jan 16, 2004 at 01:47:46PM -0800, Mohan Parthasarathy wrote: > > > > > > > Hi Mohan, > > > > > > On Thu, Jan 15, 2004 at 04:05:27PM -0800, Mohan Parthasarathy wrote: > > > > > RFC 3456 talks about running DHCP over DHCP SA (i.e., an IPsec tunnel > > > > > mode SA). This may be different from any of above three cases, > > > > > because DHCP SA is created by "using IKE" but DHCP messages are not > > > > > carried in IKE payloads. > > > > > > > > > This is what we have discussed before in a different context. But i am not > > > > going to discuss it in this draft. > > > > > > Any specific reason for not discussing RFC 3456 in this draft? Otherwise, > > > I prefer mention it to cover possible cases as much as possible. > > > > > I thought a bit about this. These are the two methods. > > > > 1st method. > > --------------- > > 1) Authenticate using PANA (link-local address is used for communication) > > 2) Client does DHCP to get an inner address. Create state about what address > > was assigned to the PaC i.e " IP address - SessionID" mapping so that it > > can ve verified later as explained below. > > 3) IKE, IPsec using phase 2 IDs as addresses obtained in (2). IKE does verification > > as mentioned in step (2) before setting up the SAs. > > > > 2nd method (RFC 3456) > > ----------------- > > 1) Authenticate using PANA (link-local address is used for communication) > > 2) setup DHCP IPsec SA where phase 2 IDs are 0/0. Run DHCP using this > > SA to get an IP address. > > 3) Setup another IPsec SA for the IP address obtained in step (2) using DHCP. > > > > If we have to mention both, we need to specify more details like the above. > > Is that what you are suggesting ? > > > I don't think we need more details like. My suggestion is that > just mentioning all the four possible cases including RFC 3456 might > be sufficient. I have some suggested text for it: > > > "4) PaC configures a link-local address before the PANA protocol > begins. At the end of authentication, it either acquires a > globally reachable address using [DHCP][DHCPV6] before > running IKE or IKEv2, running address configuration > methods available within IKE or IKEv2 by using Configuration > Payload or equivalent, running DHCP over a > special IPsec tunnel mode SA [RFC3456], or auto-configures an > address using stateless auto-configuration [IPV6-ND] before > running IKE or IKEv2 if IPv6 is being used." > Ok. I am fine with this. -mohan -mohan > > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 20 12:08:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12949 for ; Tue, 20 Jan 2004 12:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizM8-0002DL-L0; Tue, 20 Jan 2004 12:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AizLY-00022V-Bb for pana@optimus.ietf.org; Tue, 20 Jan 2004 12:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12865 for ; Tue, 20 Jan 2004 12:07:21 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AizLX-0006eF-00 for pana@ietf.org; Tue, 20 Jan 2004 12:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AizKY-0006Zd-00 for pana@ietf.org; Tue, 20 Jan 2004 12:06:23 -0500 Received: from [198.169.113.254] (helo=craig) by ietf-mx with smtp (Exim 4.12) id 1AizJZ-0006T6-00 for pana@ietf.org; Tue, 20 Jan 2004 12:05:22 -0500 Date: Tue, 20 Jan 2004 11:05:41 -0600 To: pana@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------642168640581286" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=MICROSOFT_EXECUTABLE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Pana] Hi Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , ----------642168640581286 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) rqbwqntfmxwelho -- Test, yep. ----------642168640581286 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: lxdo.exe, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ----------642168640581286-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 20 16:51:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27128 for ; Tue, 20 Jan 2004 16:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3m0-0004CJ-VR; Tue, 20 Jan 2004 16:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3la-0004BU-Tl for pana@optimus.ietf.org; Tue, 20 Jan 2004 16:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27061 for ; Tue, 20 Jan 2004 16:50:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3lY-0007a1-00 for pana@ietf.org; Tue, 20 Jan 2004 16:50:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3kc-0007W2-00 for pana@ietf.org; Tue, 20 Jan 2004 16:49:35 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3jl-0007SI-00 for pana@ietf.org; Tue, 20 Jan 2004 16:48:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0KLmcN9024467; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0KLmcr1021041; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA21039 ; Wed, 21 Jan 2004 06:48:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA23061; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA26852; Wed, 21 Jan 2004 06:48:37 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0KLma0j004215; Wed, 21 Jan 2004 06:48:36 +0900 (JST) Received: from steelhead ([159.119.168.65]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRT00F6M5WY34@tsbpo1.po.toshiba.co.jp>; Wed, 21 Jan 2004 06:48:35 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aj3iz-00014P-00; Tue, 20 Jan 2004 13:47:53 -0800 Date: Tue, 20 Jan 2004 13:47:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 28 (state machine) In-reply-to: <57050-220041314141553116@M2W044.mail2web.com> To: "vfajardo@optonline.net" Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040120214753.GJ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: "vfajardo@optonline.net" , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <57050-220041314141553116@M2W044.mail2web.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , OK. I'll try to create an ascii state table, and let's see how the table will look like. Yoshihiro Ohba On Wed, Jan 14, 2004 at 09:15:53AM -0500, vfajardo@optonline.net wrote: > > I have non-technical questions about PANA state machines. > > > > - Should it be included in the PANA specification draft or described > > in a separate draft? > > From an implementation perspective, the PANA state machine might merit > inclusion into the draft itself because it provides a more concise/complete > depiction of states and message exchanges for all events than the sample > scenario of Section 4.6 of the draft. > > > > > - What is the format of the diagrams, complex ascii-art, a table of > > (state, condition/event, action, next state) tuples in ascii text, or > > having a PostScript (or PDF) versions of draft to include diagrams in > > picture image? In the third alternative, text version of draft will > > only have text descriptions about state variables, interface variables > > and state transition conditions, like the current EAP state machine > > draft does. > > I think your second proposal is best, an ascii state table (with state, > condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the > diameter RFC (rfc3588). A text diagram (or other formats) would be more > complex to introduce and would have provided the same amount of information. > > -- victor fajardo > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 20 16:53:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27203 for ; Tue, 20 Jan 2004 16:53:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3nc-0004KF-1N for pana-archive@odin.ietf.org; Tue, 20 Jan 2004 16:52:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KLqeNW016621 for pana-archive@odin.ietf.org; Tue, 20 Jan 2004 16:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3nb-0004K0-Rz for pana-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 16:52:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27200 for ; Tue, 20 Jan 2004 16:52:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3nZ-0007hf-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 16:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3mg-0007fQ-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 16:51:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj3m4-0007cZ-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 16:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3m0-0004CJ-VR; Tue, 20 Jan 2004 16:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3la-0004BU-Tl for pana@optimus.ietf.org; Tue, 20 Jan 2004 16:50:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27061 for ; Tue, 20 Jan 2004 16:50:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3lY-0007a1-00 for pana@ietf.org; Tue, 20 Jan 2004 16:50:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3kc-0007W2-00 for pana@ietf.org; Tue, 20 Jan 2004 16:49:35 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3jl-0007SI-00 for pana@ietf.org; Tue, 20 Jan 2004 16:48:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0KLmcN9024467; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0KLmcr1021041; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA21039 ; Wed, 21 Jan 2004 06:48:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA23061; Wed, 21 Jan 2004 06:48:38 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA26852; Wed, 21 Jan 2004 06:48:37 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0KLma0j004215; Wed, 21 Jan 2004 06:48:36 +0900 (JST) Received: from steelhead ([159.119.168.65]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRT00F6M5WY34@tsbpo1.po.toshiba.co.jp>; Wed, 21 Jan 2004 06:48:35 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aj3iz-00014P-00; Tue, 20 Jan 2004 13:47:53 -0800 Date: Tue, 20 Jan 2004 13:47:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 28 (state machine) In-reply-to: <57050-220041314141553116@M2W044.mail2web.com> To: "vfajardo@optonline.net" Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040120214753.GJ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: "vfajardo@optonline.net" , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <57050-220041314141553116@M2W044.mail2web.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 OK. I'll try to create an ascii state table, and let's see how the table will look like. Yoshihiro Ohba On Wed, Jan 14, 2004 at 09:15:53AM -0500, vfajardo@optonline.net wrote: > > I have non-technical questions about PANA state machines. > > > > - Should it be included in the PANA specification draft or described > > in a separate draft? > > From an implementation perspective, the PANA state machine might merit > inclusion into the draft itself because it provides a more concise/complete > depiction of states and message exchanges for all events than the sample > scenario of Section 4.6 of the draft. > > > > > - What is the format of the diagrams, complex ascii-art, a table of > > (state, condition/event, action, next state) tuples in ascii text, or > > having a PostScript (or PDF) versions of draft to include diagrams in > > picture image? In the third alternative, text version of draft will > > only have text descriptions about state variables, interface variables > > and state transition conditions, like the current EAP state machine > > draft does. > > I think your second proposal is best, an ascii state table (with state, > condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the > diameter RFC (rfc3588). A text diagram (or other formats) would be more > complex to introduce and would have provided the same amount of information. > > -- victor fajardo > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 20 17:04:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27853 for ; Tue, 20 Jan 2004 17:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3yc-0004yV-EG; Tue, 20 Jan 2004 17:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3yD-0004vt-Ia for pana@optimus.ietf.org; Tue, 20 Jan 2004 17:03:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27832 for ; Tue, 20 Jan 2004 17:03:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3yB-0000oi-00 for pana@ietf.org; Tue, 20 Jan 2004 17:03:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3xK-0000iB-00 for pana@ietf.org; Tue, 20 Jan 2004 17:02:43 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1Aj3w2-0000VK-00 for pana@ietf.org; Tue, 20 Jan 2004 17:01:22 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 20 Jan 2004 22:01:21 -0000 Message-ID: <012301c3dfa0$f0236a00$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> Subject: Re: [Pana] PANA-IPsec-01 Date: Tue, 20 Jan 2004 14:01:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Also: > > > > "In the case of auto-configuration, IKE > > should be able to setup the SAs for the traffic selectors > > specified by the PaC without consulting the SPD entry. " > > ^^^^^^^ > > > > Do you mean "with" here? Because according to the discussion, SPD > > entry check is something needs to be performed to protect from "inner address > > theft" attack. Or I may be misunderstanding something. > > > I think it is a bit confusing. At the beginning, there are really no SPD entries. > When the first client authenticates, you still consult the SPD table but it has > no entry. SPD entries are created dynamically for this client and subsequent ones. > So, the above is trying to say that there is no pre-configured entry for the client > in the SPD that is doing the IKE/IPsec negotiation. But you have to consult the > SPD so that there is no such entry already there. Perhaps it needs some more > wording. Makes sense ? > Here is the proposed text : The old text : "Thus, it may not be able to setup the SPD entries appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require slightly a different behavior from IKE in the auto- configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. If there is already an SA for the same address, then the SA request MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry for protecting the subsequent data packets." New text: Thus, it may not be able to setup the SPD entries for the PaC appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require a different behavior from IKE in the auto-configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors (which contain the PaC auto-configured address) specified by the PaC without requiring a corresponding entry in the SPD. If there is already an SA for the same address with a different identity (specified in the ID_KEY_ID payload), then the SA MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry corresponding to the traffic selectors specified by PaC for protecting the subsequent data packets." Comments ? -mohan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 20 17:06:08 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27923 for ; Tue, 20 Jan 2004 17:06:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj40C-000539-Un for pana-archive@odin.ietf.org; Tue, 20 Jan 2004 17:05:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KM5ePa019405 for pana-archive@odin.ietf.org; Tue, 20 Jan 2004 17:05:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj40C-00052u-QK for pana-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 17:05:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27920 for ; Tue, 20 Jan 2004 17:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj40A-0000uZ-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 17:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3zF-0000sK-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 17:04:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj3ye-0000pj-00 for pana-web-archive@ietf.org; Tue, 20 Jan 2004 17:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3yc-0004yV-EG; Tue, 20 Jan 2004 17:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj3yD-0004vt-Ia for pana@optimus.ietf.org; Tue, 20 Jan 2004 17:03:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27832 for ; Tue, 20 Jan 2004 17:03:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj3yB-0000oi-00 for pana@ietf.org; Tue, 20 Jan 2004 17:03:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj3xK-0000iB-00 for pana@ietf.org; Tue, 20 Jan 2004 17:02:43 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1Aj3w2-0000VK-00 for pana@ietf.org; Tue, 20 Jan 2004 17:01:22 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 20 Jan 2004 22:01:21 -0000 Message-ID: <012301c3dfa0$f0236a00$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> Subject: Re: [Pana] PANA-IPsec-01 Date: Tue, 20 Jan 2004 14:01:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Also: > > > > "In the case of auto-configuration, IKE > > should be able to setup the SAs for the traffic selectors > > specified by the PaC without consulting the SPD entry. " > > ^^^^^^^ > > > > Do you mean "with" here? Because according to the discussion, SPD > > entry check is something needs to be performed to protect from "inner address > > theft" attack. Or I may be misunderstanding something. > > > I think it is a bit confusing. At the beginning, there are really no SPD entries. > When the first client authenticates, you still consult the SPD table but it has > no entry. SPD entries are created dynamically for this client and subsequent ones. > So, the above is trying to say that there is no pre-configured entry for the client > in the SPD that is doing the IKE/IPsec negotiation. But you have to consult the > SPD so that there is no such entry already there. Perhaps it needs some more > wording. Makes sense ? > Here is the proposed text : The old text : "Thus, it may not be able to setup the SPD entries appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require slightly a different behavior from IKE in the auto- configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors specified by the PaC without consulting the SPD entry. If there is already an SA for the same address, then the SA request MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry for protecting the subsequent data packets." New text: Thus, it may not be able to setup the SPD entries for the PaC appropriately before IKE exchange starts. As most of the IKE implementations assume that the SPD can be consulted during the SA negotiation, it may require a different behavior from IKE in the auto-configuration case. In the case of auto-configuration, IKE should be able to setup the SAs for the traffic selectors (which contain the PaC auto-configured address) specified by the PaC without requiring a corresponding entry in the SPD. If there is already an SA for the same address with a different identity (specified in the ID_KEY_ID payload), then the SA MUST be rejected with INVALID-ID-INFORMATION [IKE]. If PaC authenticates itself successfully, EP should add the SPD entry corresponding to the traffic selectors specified by PaC for protecting the subsequent data packets." Comments ? -mohan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 02:56:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11065 for ; Wed, 21 Jan 2004 02:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDDW-0007zM-0K; Wed, 21 Jan 2004 02:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDDR-0007yv-MI for pana@optimus.ietf.org; Wed, 21 Jan 2004 02:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11044 for ; Wed, 21 Jan 2004 02:55:54 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjDDN-0004m8-00 for pana@ietf.org; Wed, 21 Jan 2004 02:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjDCQ-0004kR-00 for pana@ietf.org; Wed, 21 Jan 2004 02:54:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjDC4-0004ij-00 for pana@ietf.org; Wed, 21 Jan 2004 02:54:32 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0L7sWY12836 for ; Wed, 21 Jan 2004 09:54:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 09:54:30 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 09:54:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 28 (state machine) Date: Wed, 21 Jan 2004 09:54:29 +0200 Message-ID: Thread-Topic: [Pana] issue 28 (state machine) Thread-Index: AcPfn67AnSzDuFWtQ3ynt9ep7zuocwAU+J2w To: Cc: X-OriginalArrivalTime: 21 Jan 2004 07:54:30.0037 (UTC) FILETIME=[CCABE450:01C3DFF3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Yoshi! Let's put the ascii tables into the issue28 on the tracker. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 20 January, 2004 23:48 > To: vfajardo@optonline.net > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] issue 28 (state machine) > > > OK. I'll try to create an ascii state table, and let's see how the > table will look like. > > Yoshihiro Ohba > > > On Wed, Jan 14, 2004 at 09:15:53AM -0500, > vfajardo@optonline.net wrote: > > > I have non-technical questions about PANA state machines. > > > > > > - Should it be included in the PANA specification draft > or described > > > in a separate draft? > > > > From an implementation perspective, the PANA state machine > might merit > > inclusion into the draft itself because it provides a more > concise/complete > > depiction of states and message exchanges for all events > than the sample > > scenario of Section 4.6 of the draft. > > > > > > > > - What is the format of the diagrams, complex ascii-art, > a table of > > > (state, condition/event, action, next state) tuples in > ascii text, or > > > having a PostScript (or PDF) versions of draft to include > diagrams in > > > picture image? In the third alternative, text version of > draft will > > > only have text descriptions about state variables, > interface variables > > > and state transition conditions, like the current EAP > state machine > > > draft does. > > > > I think your second proposal is best, an ascii state table > (with state, > > condition/event, action, next state) similar to Sec. 8.1, > 8.2 etc. of the > > diameter RFC (rfc3588). A text diagram (or other formats) > would be more > > complex to introduce and would have provided the same > amount of information. > > > > -- victor fajardo > > > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://mail2web.com/ . > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 02:58:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11115 for ; Wed, 21 Jan 2004 02:58:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDFX-00086q-Ty for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 02:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L7w7aM031167 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 02:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDFX-00086Z-6l for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 02:58:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11104 for ; Wed, 21 Jan 2004 02:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjDFT-0004pw-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 02:58:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjDEM-0004oR-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 02:56:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjDDV-0004mh-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 02:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDDW-0007zM-0K; Wed, 21 Jan 2004 02:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjDDR-0007yv-MI for pana@optimus.ietf.org; Wed, 21 Jan 2004 02:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11044 for ; Wed, 21 Jan 2004 02:55:54 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjDDN-0004m8-00 for pana@ietf.org; Wed, 21 Jan 2004 02:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjDCQ-0004kR-00 for pana@ietf.org; Wed, 21 Jan 2004 02:54:54 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AjDC4-0004ij-00 for pana@ietf.org; Wed, 21 Jan 2004 02:54:32 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0L7sWY12836 for ; Wed, 21 Jan 2004 09:54:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 21 Jan 2004 09:54:30 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 21 Jan 2004 09:54:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 28 (state machine) Date: Wed, 21 Jan 2004 09:54:29 +0200 Message-ID: Thread-Topic: [Pana] issue 28 (state machine) Thread-Index: AcPfn67AnSzDuFWtQ3ynt9ep7zuocwAU+J2w To: Cc: X-OriginalArrivalTime: 21 Jan 2004 07:54:30.0037 (UTC) FILETIME=[CCABE450:01C3DFF3] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Yoshi! Let's put the ascii tables into the issue28 on the tracker. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 20 January, 2004 23:48 > To: vfajardo@optonline.net > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] issue 28 (state machine) > > > OK. I'll try to create an ascii state table, and let's see how the > table will look like. > > Yoshihiro Ohba > > > On Wed, Jan 14, 2004 at 09:15:53AM -0500, > vfajardo@optonline.net wrote: > > > I have non-technical questions about PANA state machines. > > > > > > - Should it be included in the PANA specification draft > or described > > > in a separate draft? > > > > From an implementation perspective, the PANA state machine > might merit > > inclusion into the draft itself because it provides a more > concise/complete > > depiction of states and message exchanges for all events > than the sample > > scenario of Section 4.6 of the draft. > > > > > > > > - What is the format of the diagrams, complex ascii-art, > a table of > > > (state, condition/event, action, next state) tuples in > ascii text, or > > > having a PostScript (or PDF) versions of draft to include > diagrams in > > > picture image? In the third alternative, text version of > draft will > > > only have text descriptions about state variables, > interface variables > > > and state transition conditions, like the current EAP > state machine > > > draft does. > > > > I think your second proposal is best, an ascii state table > (with state, > > condition/event, action, next state) similar to Sec. 8.1, > 8.2 etc. of the > > diameter RFC (rfc3588). A text diagram (or other formats) > would be more > > complex to introduce and would have provided the same > amount of information. > > > > -- victor fajardo > > > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://mail2web.com/ . > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 12:48:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01495 for ; Wed, 21 Jan 2004 12:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMSP-00083n-7I; Wed, 21 Jan 2004 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMRb-000822-JD for pana@optimus.ietf.org; Wed, 21 Jan 2004 12:47:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01469 for ; Wed, 21 Jan 2004 12:47:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMRZ-0001uP-00 for pana@ietf.org; Wed, 21 Jan 2004 12:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMQe-0001ta-00 for pana@ietf.org; Wed, 21 Jan 2004 12:46:13 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjMQK-0001sI-00 for pana@ietf.org; Wed, 21 Jan 2004 12:45:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LHjpN9019243 for ; Thu, 22 Jan 2004 02:45:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LHjpxr006283 for ; Thu, 22 Jan 2004 02:45:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA06282 ; Thu, 22 Jan 2004 02:45:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07291; Thu, 22 Jan 2004 02:45:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA22396; Thu, 22 Jan 2004 02:45:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LHjn0j016674 for ; Thu, 22 Jan 2004 02:45:49 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00AAIPC750@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 22 Jan 2004 02:45:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjMOn-00024c-00 for ; Wed, 21 Jan 2004 09:44:17 -0800 Date: Wed, 21 Jan 2004 09:44:17 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121174417.GT26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 39 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I agree with the proposed change on issue 39. http://www.danforsberg.info:8080/pana-issues/issue39 Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 12:49:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01555 for ; Wed, 21 Jan 2004 12:49:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMTb-00087m-OA for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 12:49:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LHnFIu031231 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 12:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMTb-00087e-KQ for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 12:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01546 for ; Wed, 21 Jan 2004 12:49:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMTZ-0001xo-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:49:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMSb-0001wC-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:48:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjMSR-0001un-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMSP-00083n-7I; Wed, 21 Jan 2004 12:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMRb-000822-JD for pana@optimus.ietf.org; Wed, 21 Jan 2004 12:47:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01469 for ; Wed, 21 Jan 2004 12:47:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMRZ-0001uP-00 for pana@ietf.org; Wed, 21 Jan 2004 12:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMQe-0001ta-00 for pana@ietf.org; Wed, 21 Jan 2004 12:46:13 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjMQK-0001sI-00 for pana@ietf.org; Wed, 21 Jan 2004 12:45:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LHjpN9019243 for ; Thu, 22 Jan 2004 02:45:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LHjpxr006283 for ; Thu, 22 Jan 2004 02:45:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA06282 ; Thu, 22 Jan 2004 02:45:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07291; Thu, 22 Jan 2004 02:45:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA22396; Thu, 22 Jan 2004 02:45:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LHjn0j016674 for ; Thu, 22 Jan 2004 02:45:49 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00AAIPC750@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 22 Jan 2004 02:45:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjMOn-00024c-00 for ; Wed, 21 Jan 2004 09:44:17 -0800 Date: Wed, 21 Jan 2004 09:44:17 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121174417.GT26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 39 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I agree with the proposed change on issue 39. http://www.danforsberg.info:8080/pana-issues/issue39 Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 12:51:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01623 for ; Wed, 21 Jan 2004 12:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMVH-0008AD-VB; Wed, 21 Jan 2004 12:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMUZ-00089B-EI for pana@optimus.ietf.org; Wed, 21 Jan 2004 12:50:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01584 for ; Wed, 21 Jan 2004 12:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMUX-00020O-00 for pana@ietf.org; Wed, 21 Jan 2004 12:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMTb-0001y9-00 for pana@ietf.org; Wed, 21 Jan 2004 12:49:16 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjMSv-0001wP-00 for pana@ietf.org; Wed, 21 Jan 2004 12:48:33 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LHmWN9019872 for ; Thu, 22 Jan 2004 02:48:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LHmW2l007049 for ; Thu, 22 Jan 2004 02:48:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA07048 ; Thu, 22 Jan 2004 02:48:32 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07902; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA26097; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LHmU0j017114 for ; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00ABHPGS50@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 22 Jan 2004 02:48:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjMSB-000257-00 for ; Wed, 21 Jan 2004 09:47:47 -0800 Date: Wed, 21 Jan 2004 09:47:47 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121174747.GU26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 38 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , http://www.danforsberg.info:8080/pana-issues/issue38 It is true that in sectionm 9.4.1, multiple hash algorithms are supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. There is also an issue of whether PANA should allow negotiation of MAC algorithm. I think PANA should not allow algorithm negotiation, since there is a possible downgrading attack if negotiation is allowed. Instead, the PAA should specify which algorithm is used. As a result, the PaC either accepts the specified algorithm or fails to complete authentication successfully. Here is suggested text: In section 4.1.6, change: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0." to: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0. PANA_MAC_PRF represents the pseudo random function corresponding to the MAC algorithm specified in the MAC AVP. In this version of draft, PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST use the same algorithm to calculate a MAC AVP they originate and receive. The algorithm is determined by the PAA when a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not support the MAC algorithm specified in the PANA-Bind-Request message, it MUST silently discard the message. The PAA MUST NOT change the MAC algorithm throughout the continuation of the PANA session." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 12:52:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01671 for ; Wed, 21 Jan 2004 12:52:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMWX-0008ET-Qv for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 12:52:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LHqHtL031639 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 12:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMWX-0008EE-MG for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 12:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01668 for ; Wed, 21 Jan 2004 12:52:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMWW-00026a-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:52:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMVc-00024K-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:51:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjMVI-00021n-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 12:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMVH-0008AD-VB; Wed, 21 Jan 2004 12:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjMUZ-00089B-EI for pana@optimus.ietf.org; Wed, 21 Jan 2004 12:50:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01584 for ; Wed, 21 Jan 2004 12:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjMUX-00020O-00 for pana@ietf.org; Wed, 21 Jan 2004 12:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjMTb-0001y9-00 for pana@ietf.org; Wed, 21 Jan 2004 12:49:16 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjMSv-0001wP-00 for pana@ietf.org; Wed, 21 Jan 2004 12:48:33 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LHmWN9019872 for ; Thu, 22 Jan 2004 02:48:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LHmW2l007049 for ; Thu, 22 Jan 2004 02:48:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA07048 ; Thu, 22 Jan 2004 02:48:32 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07902; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA26097; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LHmU0j017114 for ; Thu, 22 Jan 2004 02:48:31 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00ABHPGS50@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 22 Jan 2004 02:48:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjMSB-000257-00 for ; Wed, 21 Jan 2004 09:47:47 -0800 Date: Wed, 21 Jan 2004 09:47:47 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121174747.GU26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 38 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 http://www.danforsberg.info:8080/pana-issues/issue38 It is true that in sectionm 9.4.1, multiple hash algorithms are supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. There is also an issue of whether PANA should allow negotiation of MAC algorithm. I think PANA should not allow algorithm negotiation, since there is a possible downgrading attack if negotiation is allowed. Instead, the PAA should specify which algorithm is used. As a result, the PaC either accepts the specified algorithm or fails to complete authentication successfully. Here is suggested text: In section 4.1.6, change: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0." to: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0. PANA_MAC_PRF represents the pseudo random function corresponding to the MAC algorithm specified in the MAC AVP. In this version of draft, PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST use the same algorithm to calculate a MAC AVP they originate and receive. The algorithm is determined by the PAA when a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not support the MAC algorithm specified in the PANA-Bind-Request message, it MUST silently discard the message. The PAA MUST NOT change the MAC algorithm throughout the continuation of the PANA session." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 14:30:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04423 for ; Wed, 21 Jan 2004 14:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO38-0005fw-H9; Wed, 21 Jan 2004 14:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO2Q-0005eH-HR for pana@optimus.ietf.org; Wed, 21 Jan 2004 14:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04347 for ; Wed, 21 Jan 2004 14:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjO2N-0005Ur-00 for pana@ietf.org; Wed, 21 Jan 2004 14:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjO1R-0005TD-00 for pana@ietf.org; Wed, 21 Jan 2004 14:28:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjO18-0005Rf-00 for pana@ietf.org; Wed, 21 Jan 2004 14:27:58 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LJRsN9011550; Thu, 22 Jan 2004 04:27:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LJRsei003643; Thu, 22 Jan 2004 04:27:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA03638 ; Thu, 22 Jan 2004 04:27:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA27227; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA14580; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LJRq0j001104; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00C7EU2EWJ@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 04:27:51 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjO0Z-0002Jl-00; Wed, 21 Jan 2004 11:27:23 -0800 Date: Wed, 21 Jan 2004 11:27:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <012301c3dfa0$f0236a00$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040121192723.GX26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Mohan, Looks better. I think that relying solely on the SPD consulting might not prevent a DoS attack where a malicous client performs IKE with spoofing an inner address *before* the legitimate client does IKE with the inner address. If this is true, we might want to mention it somewhere in the draft. Yoshihiro Ohba On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > New text: > Thus, it may not be able to setup the SPD entries for the PaC appropriately > before IKE exchange starts. As most of the IKE implementations assume > that the SPD can be consulted during the SA negotiation, it may > require a different behavior from IKE in the auto-configuration case. > In the case of auto-configuration, IKE should be able to setup the SAs > for the traffic selectors (which contain the PaC auto-configured address) > specified by the PaC without requiring a corresponding entry in the SPD. > If there is already an SA for the same address with a different identity > (specified in the ID_KEY_ID payload), then the SA MUST > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > authenticates itself successfully, EP should add the SPD entry > corresponding to the traffic selectors specified by PaC > for protecting the subsequent data packets." > > Comments ? > > -mohan > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 14:31:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04475 for ; Wed, 21 Jan 2004 14:31:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO4O-0005na-Hn for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 14:31:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LJVKoj022289 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 14:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO4O-0005nQ-DQ for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 14:31:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04470 for ; Wed, 21 Jan 2004 14:31:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjO4L-0005Zv-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:31:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjO3R-0005Y0-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:30:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjO39-0005Vq-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO38-0005fw-H9; Wed, 21 Jan 2004 14:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjO2Q-0005eH-HR for pana@optimus.ietf.org; Wed, 21 Jan 2004 14:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04347 for ; Wed, 21 Jan 2004 14:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjO2N-0005Ur-00 for pana@ietf.org; Wed, 21 Jan 2004 14:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjO1R-0005TD-00 for pana@ietf.org; Wed, 21 Jan 2004 14:28:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjO18-0005Rf-00 for pana@ietf.org; Wed, 21 Jan 2004 14:27:58 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LJRsN9011550; Thu, 22 Jan 2004 04:27:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LJRsei003643; Thu, 22 Jan 2004 04:27:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA03638 ; Thu, 22 Jan 2004 04:27:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA27227; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA14580; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LJRq0j001104; Thu, 22 Jan 2004 04:27:53 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00C7EU2EWJ@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 04:27:51 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjO0Z-0002Jl-00; Wed, 21 Jan 2004 11:27:23 -0800 Date: Wed, 21 Jan 2004 11:27:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <012301c3dfa0$f0236a00$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040121192723.GX26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Mohan, Looks better. I think that relying solely on the SPD consulting might not prevent a DoS attack where a malicous client performs IKE with spoofing an inner address *before* the legitimate client does IKE with the inner address. If this is true, we might want to mention it somewhere in the draft. Yoshihiro Ohba On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > New text: > Thus, it may not be able to setup the SPD entries for the PaC appropriately > before IKE exchange starts. As most of the IKE implementations assume > that the SPD can be consulted during the SA negotiation, it may > require a different behavior from IKE in the auto-configuration case. > In the case of auto-configuration, IKE should be able to setup the SAs > for the traffic selectors (which contain the PaC auto-configured address) > specified by the PaC without requiring a corresponding entry in the SPD. > If there is already an SA for the same address with a different identity > (specified in the ID_KEY_ID payload), then the SA MUST > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > authenticates itself successfully, EP should add the SPD entry > corresponding to the traffic selectors specified by PaC > for protecting the subsequent data packets." > > Comments ? > > -mohan > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 14:43:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04908 for ; Wed, 21 Jan 2004 14:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOFh-0006fM-C8; Wed, 21 Jan 2004 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOEz-0006bV-AV for pana@optimus.ietf.org; Wed, 21 Jan 2004 14:42:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04879 for ; Wed, 21 Jan 2004 14:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjOEw-00061b-00 for pana@ietf.org; Wed, 21 Jan 2004 14:42:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjODz-00060P-00 for pana@ietf.org; Wed, 21 Jan 2004 14:41:15 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjODq-0005zJ-00 for pana@ietf.org; Wed, 21 Jan 2004 14:41:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LJf5N9014946; Thu, 22 Jan 2004 04:41:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LJf5R2008032; Thu, 22 Jan 2004 04:41:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA08031 ; Thu, 22 Jan 2004 04:41:05 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA00317; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA25512; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LJf30j002869; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00CEFUODWJ@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 04:41:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjOC3-0002LR-00; Wed, 21 Jan 2004 11:39:15 -0800 Date: Wed, 21 Jan 2004 11:39:15 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121193915.GY26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , In section 6 of pana-ipsec draft: " IPv4/IPv6 header (source = PAC-LINK-LOCAL, destination = EP-LINK-LOCAL) ESP header IPv4/IPv6 header (source = PAC-GLOBAL-ADDR, destination = END-ADDR) Following is the packet format on the wire for packets sent from EP to PaC: IPv4/IPv6 header (source = EP-LINK-LOCAL, destination = PAC-LINK-LOCAL) ESP header IPv4/IPv6 header (source = END-ADDR, destination = PAC-GLOBAL-ADDR)" I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it mean IPv4 link-local address specified in draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft explcitly says: "This document does not recommend that Link-Local IPv4 addresses and routable addresses be configured simultaneously on the same interface." and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL in the case of IPv4. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 14:44:44 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04949 for ; Wed, 21 Jan 2004 14:44:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOGv-0006iu-Hk for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 14:44:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LJiHBF025838 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 14:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOGv-0006if-E9 for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 14:44:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04938 for ; Wed, 21 Jan 2004 14:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjOGs-00065x-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:44:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjOFz-00064T-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:43:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjOFj-00062n-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 14:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOFh-0006fM-C8; Wed, 21 Jan 2004 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjOEz-0006bV-AV for pana@optimus.ietf.org; Wed, 21 Jan 2004 14:42:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04879 for ; Wed, 21 Jan 2004 14:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjOEw-00061b-00 for pana@ietf.org; Wed, 21 Jan 2004 14:42:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjODz-00060P-00 for pana@ietf.org; Wed, 21 Jan 2004 14:41:15 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjODq-0005zJ-00 for pana@ietf.org; Wed, 21 Jan 2004 14:41:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0LJf5N9014946; Thu, 22 Jan 2004 04:41:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0LJf5R2008032; Thu, 22 Jan 2004 04:41:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA08031 ; Thu, 22 Jan 2004 04:41:05 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA00317; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA25512; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0LJf30j002869; Thu, 22 Jan 2004 04:41:04 +0900 (JST) Received: from steelhead ([159.119.168.57]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRU00CEFUODWJ@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 04:41:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjOC3-0002LR-00; Wed, 21 Jan 2004 11:39:15 -0800 Date: Wed, 21 Jan 2004 11:39:15 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040121193915.GY26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In section 6 of pana-ipsec draft: " IPv4/IPv6 header (source = PAC-LINK-LOCAL, destination = EP-LINK-LOCAL) ESP header IPv4/IPv6 header (source = PAC-GLOBAL-ADDR, destination = END-ADDR) Following is the packet format on the wire for packets sent from EP to PaC: IPv4/IPv6 header (source = EP-LINK-LOCAL, destination = PAC-LINK-LOCAL) ESP header IPv4/IPv6 header (source = END-ADDR, destination = PAC-GLOBAL-ADDR)" I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it mean IPv4 link-local address specified in draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft explcitly says: "This document does not recommend that Link-Local IPv4 addresses and routable addresses be configured simultaneously on the same interface." and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL in the case of IPv4. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 16:06:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08496 for ; Wed, 21 Jan 2004 16:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPY1-0003xv-G3; Wed, 21 Jan 2004 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPXO-0003vl-JC for pana@optimus.ietf.org; Wed, 21 Jan 2004 16:05:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08456 for ; Wed, 21 Jan 2004 16:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPXK-0001X8-00 for pana@ietf.org; Wed, 21 Jan 2004 16:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPWO-0001Vg-00 for pana@ietf.org; Wed, 21 Jan 2004 16:04:21 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjPVh-0001U6-00 for pana@ietf.org; Wed, 21 Jan 2004 16:03:37 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 21 Jan 2004 21:03:36 -0000 Message-ID: <00e101c3e062$0a051d30$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Wed, 21 Jan 2004 13:03:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Looks better. > > I think that relying solely on the SPD consulting might not prevent a > DoS attack where a malicous client performs IKE with spoofing an inner > address *before* the legitimate client does IKE with the inner > address. > Malicious client who successfully authenticated using PANA can launch this attack. But it is the same as the DoS attack that could happen with DAD. > If this is true, we might want to mention it somewhere in the draft. > It is mentioned in the security considerations section. Please see whether it is enough. -mohan > Yoshihiro Ohba > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > New text: > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > before IKE exchange starts. As most of the IKE implementations assume > > that the SPD can be consulted during the SA negotiation, it may > > require a different behavior from IKE in the auto-configuration case. > > In the case of auto-configuration, IKE should be able to setup the SAs > > for the traffic selectors (which contain the PaC auto-configured address) > > specified by the PaC without requiring a corresponding entry in the SPD. > > If there is already an SA for the same address with a different identity > > (specified in the ID_KEY_ID payload), then the SA MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > corresponding to the traffic selectors specified by PaC > > for protecting the subsequent data packets." > > > > Comments ? > > > > -mohan > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 16:07:50 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08549 for ; Wed, 21 Jan 2004 16:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPZJ-00049l-Jx for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 16:07:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LL7LXq015969 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 16:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPZJ-00049U-1v for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:07:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08538 for ; Wed, 21 Jan 2004 16:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPZH-0001bz-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:07:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPYN-0001aD-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:06:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPY3-0001YF-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPY1-0003xv-G3; Wed, 21 Jan 2004 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPXO-0003vl-JC for pana@optimus.ietf.org; Wed, 21 Jan 2004 16:05:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08456 for ; Wed, 21 Jan 2004 16:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPXK-0001X8-00 for pana@ietf.org; Wed, 21 Jan 2004 16:05:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPWO-0001Vg-00 for pana@ietf.org; Wed, 21 Jan 2004 16:04:21 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjPVh-0001U6-00 for pana@ietf.org; Wed, 21 Jan 2004 16:03:37 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 21 Jan 2004 21:03:36 -0000 Message-ID: <00e101c3e062$0a051d30$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Wed, 21 Jan 2004 13:03:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Looks better. > > I think that relying solely on the SPD consulting might not prevent a > DoS attack where a malicous client performs IKE with spoofing an inner > address *before* the legitimate client does IKE with the inner > address. > Malicious client who successfully authenticated using PANA can launch this attack. But it is the same as the DoS attack that could happen with DAD. > If this is true, we might want to mention it somewhere in the draft. > It is mentioned in the security considerations section. Please see whether it is enough. -mohan > Yoshihiro Ohba > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > New text: > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > before IKE exchange starts. As most of the IKE implementations assume > > that the SPD can be consulted during the SA negotiation, it may > > require a different behavior from IKE in the auto-configuration case. > > In the case of auto-configuration, IKE should be able to setup the SAs > > for the traffic selectors (which contain the PaC auto-configured address) > > specified by the PaC without requiring a corresponding entry in the SPD. > > If there is already an SA for the same address with a different identity > > (specified in the ID_KEY_ID payload), then the SA MUST > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > authenticates itself successfully, EP should add the SPD entry > > corresponding to the traffic selectors specified by PaC > > for protecting the subsequent data packets." > > > > Comments ? > > > > -mohan > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 16:09:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08609 for ; Wed, 21 Jan 2004 16:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPau-0004Sc-Mm; Wed, 21 Jan 2004 16:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPaJ-0004Rw-Ez for pana@optimus.ietf.org; Wed, 21 Jan 2004 16:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08590 for ; Wed, 21 Jan 2004 16:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPaH-0001eY-00 for pana@ietf.org; Wed, 21 Jan 2004 16:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPZL-0001cn-00 for pana@ietf.org; Wed, 21 Jan 2004 16:07:24 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjPZ9-0001ah-00 for pana@ietf.org; Wed, 21 Jan 2004 16:07:11 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 21 Jan 2004 21:07:11 -0000 Message-ID: <00e701c3e062$89a7fad0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , References: <20040121193915.GY26285@steelhead> Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Wed, 21 Jan 2004 13:07:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In section 6 of pana-ipsec draft: > > " IPv4/IPv6 header (source = PAC-LINK-LOCAL, > destination = EP-LINK-LOCAL) > ESP header > IPv4/IPv6 header (source = PAC-GLOBAL-ADDR, > destination = END-ADDR) > > Following is the packet format on the wire for packets sent from EP > to PaC: > > > IPv4/IPv6 header (source = EP-LINK-LOCAL, > destination = PAC-LINK-LOCAL) > ESP header > IPv4/IPv6 header (source = END-ADDR, > destination = PAC-GLOBAL-ADDR)" > > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > mean IPv4 link-local address specified in > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > explcitly says: > Yes, that's what i meant. > "This > document does not recommend that Link-Local IPv4 addresses and > routable addresses be configured simultaneously on the same > interface." > > and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL > in the case of IPv4. > I agree with this. Most of the current implementations use only one of them. You try to configure a global and if you don't get one, try the link-local. I will modify the draft accordingly for IPv4 drafts. thanks -mohan > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 16:10:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08657 for ; Wed, 21 Jan 2004 16:10:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPcD-0004WH-Dd for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 16:10:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLALhH017367 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 16:10:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPcD-0004W2-9Q for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:10:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08645 for ; Wed, 21 Jan 2004 16:10:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPcB-0001j8-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:10:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPbE-0001h7-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:09:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPav-0001fP-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 16:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPau-0004Sc-Mm; Wed, 21 Jan 2004 16:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPaJ-0004Rw-Ez for pana@optimus.ietf.org; Wed, 21 Jan 2004 16:08:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08590 for ; Wed, 21 Jan 2004 16:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPaH-0001eY-00 for pana@ietf.org; Wed, 21 Jan 2004 16:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPZL-0001cn-00 for pana@ietf.org; Wed, 21 Jan 2004 16:07:24 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjPZ9-0001ah-00 for pana@ietf.org; Wed, 21 Jan 2004 16:07:11 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 21 Jan 2004 21:07:11 -0000 Message-ID: <00e701c3e062$89a7fad0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , References: <20040121193915.GY26285@steelhead> Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Wed, 21 Jan 2004 13:07:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In section 6 of pana-ipsec draft: > > " IPv4/IPv6 header (source = PAC-LINK-LOCAL, > destination = EP-LINK-LOCAL) > ESP header > IPv4/IPv6 header (source = PAC-GLOBAL-ADDR, > destination = END-ADDR) > > Following is the packet format on the wire for packets sent from EP > to PaC: > > > IPv4/IPv6 header (source = EP-LINK-LOCAL, > destination = PAC-LINK-LOCAL) > ESP header > IPv4/IPv6 header (source = END-ADDR, > destination = PAC-GLOBAL-ADDR)" > > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > mean IPv4 link-local address specified in > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > explcitly says: > Yes, that's what i meant. > "This > document does not recommend that Link-Local IPv4 addresses and > routable addresses be configured simultaneously on the same > interface." > > and I think PAC-GLOBAL-ADDR should be used instead of PAC-LINK-LOCAL > in the case of IPv4. > I agree with this. Most of the current implementations use only one of them. You try to configure a global and if you don't get one, try the link-local. I will modify the draft accordingly for IPv4 drafts. thanks -mohan > Regards, > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 20:33:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20776 for ; Wed, 21 Jan 2004 20:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTiP-0006zx-7K; Wed, 21 Jan 2004 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjThr-0006ys-Bo for pana@optimus.ietf.org; Wed, 21 Jan 2004 20:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20733 for ; Wed, 21 Jan 2004 20:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjThp-0007Kw-00 for pana@ietf.org; Wed, 21 Jan 2004 20:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTgq-0007Jk-00 for pana@ietf.org; Wed, 21 Jan 2004 20:31:25 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjTgh-0007Ip-00 for pana@ietf.org; Wed, 21 Jan 2004 20:31:15 -0500 Date: Wed, 21 Jan 2004 17:31:11 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040121193915.GY26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > mean IPv4 link-local address specified in > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > explcitly says: > > "This > document does not recommend that Link-Local IPv4 addresses and > routable addresses be configured simultaneously on the same > interface." I don't think it should be a problem to use the link-local address as the tunnel end point, and the global address inside the tunnel. I don't think this is what the zeroconf draft is prohibiting. Nevertheless, we can consider using the same global IP address as the tunnel end point and as the inner IP address as soon as the PaC gets one. Any pros and cons here? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 20:34:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20803 for ; Wed, 21 Jan 2004 20:34:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTjm-000734-GP for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 20:34:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M1YQ2i027088 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 20:34:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTjm-00072p-A5 for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 20:34:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20798 for ; Wed, 21 Jan 2004 20:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjTjk-0007OP-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 20:34:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTiq-0007NP-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 20:33:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjTiQ-0007M3-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 20:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjTiP-0006zx-7K; Wed, 21 Jan 2004 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjThr-0006ys-Bo for pana@optimus.ietf.org; Wed, 21 Jan 2004 20:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20733 for ; Wed, 21 Jan 2004 20:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjThp-0007Kw-00 for pana@ietf.org; Wed, 21 Jan 2004 20:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjTgq-0007Jk-00 for pana@ietf.org; Wed, 21 Jan 2004 20:31:25 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjTgh-0007Ip-00 for pana@ietf.org; Wed, 21 Jan 2004 20:31:15 -0500 Date: Wed, 21 Jan 2004 17:31:11 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040121193915.GY26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > mean IPv4 link-local address specified in > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > explcitly says: > > "This > document does not recommend that Link-Local IPv4 addresses and > routable addresses be configured simultaneously on the same > interface." I don't think it should be a problem to use the link-local address as the tunnel end point, and the global address inside the tunnel. I don't think this is what the zeroconf draft is prohibiting. Nevertheless, we can consider using the same global IP address as the tunnel end point and as the inner IP address as soon as the PaC gets one. Any pros and cons here? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 21:41:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23153 for ; Wed, 21 Jan 2004 21:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUmC-0002xA-Ht; Wed, 21 Jan 2004 21:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUll-0002vq-W7 for pana@optimus.ietf.org; Wed, 21 Jan 2004 21:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23138 for ; Wed, 21 Jan 2004 21:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjUlj-0002hS-00 for pana@ietf.org; Wed, 21 Jan 2004 21:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjUkp-0002ff-00 for pana@ietf.org; Wed, 21 Jan 2004 21:39:36 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjUkL-0002dR-00 for pana@ietf.org; Wed, 21 Jan 2004 21:39:05 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0M2d2N9001361; Thu, 22 Jan 2004 11:39:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0M2d1tM026788; Thu, 22 Jan 2004 11:39:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA26780 ; Thu, 22 Jan 2004 11:39:01 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA08099; Thu, 22 Jan 2004 11:39:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA07550; Thu, 22 Jan 2004 11:38:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0M2cw0j025065; Thu, 22 Jan 2004 11:38:59 +0900 (JST) Received: from steelhead ([159.119.168.86]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRV00GLME0WCC@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 11:38:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjUjf-0003E3-00; Wed, 21 Jan 2004 18:38:23 -0800 Date: Wed, 21 Jan 2004 18:38:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040122023823.GK26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040121193915.GY26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Jan 21, 2004 at 05:31:11PM -0800, Alper Yegin wrote: > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > > mean IPv4 link-local address specified in > > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > > explcitly says: > > > > "This > > document does not recommend that Link-Local IPv4 addresses and > > routable addresses be configured simultaneously on the same > > interface." > > I don't think it should be a problem to use the link-local address as the > tunnel end point, and the global address inside the tunnel. I don't think > this is what the zeroconf draft is prohibiting. OK, I see what you mean. > > Nevertheless, we can consider using the same global IP address as the tunnel > end point and as the inner IP address as soon as the PaC gets one. Any pros > and cons here? At least Windows 2000 and XP implementations, link-local address is available only after performing DHCP and the DHCP has been failed. It takes long time (about 30 seconds in my measurement) until DHCP fails, which is unacceptable. In the same implementations, if DHCP succeeds, link-local address is not available as Mohan mentioned. An advantage would be that only one stateful configuration protocol operation is needed for obtaining the inner addres. On the other hand, if we use global IP address as the outer address, unauthenticated DHCP would be performed to obtain a pre-PANA address. In an environment where the post-PANA address (i.e, the global address) is assigned to authenticated clients only, the pre-PANA and post-PANA addresses will be different. This means that two stateful configuration protocol operations will be needed, one for pre-PANA address and the other for the post-PANA address. But this is much better than waiting for lengty DHCP timeout to configure an IPv4 link-local address. Yoshihiro Ohba > > Alper > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 21:43:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23190 for ; Wed, 21 Jan 2004 21:43:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUng-00034b-JJ for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 21:42:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M2gWAB011798 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 21:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUng-00034D-Dx for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 21:42:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23186 for ; Wed, 21 Jan 2004 21:42:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjUnd-0002lT-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 21:42:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjUmg-0002jl-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 21:41:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjUmD-0002i6-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 21:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUmC-0002xA-Ht; Wed, 21 Jan 2004 21:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjUll-0002vq-W7 for pana@optimus.ietf.org; Wed, 21 Jan 2004 21:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23138 for ; Wed, 21 Jan 2004 21:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjUlj-0002hS-00 for pana@ietf.org; Wed, 21 Jan 2004 21:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjUkp-0002ff-00 for pana@ietf.org; Wed, 21 Jan 2004 21:39:36 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjUkL-0002dR-00 for pana@ietf.org; Wed, 21 Jan 2004 21:39:05 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0M2d2N9001361; Thu, 22 Jan 2004 11:39:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0M2d1tM026788; Thu, 22 Jan 2004 11:39:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA26780 ; Thu, 22 Jan 2004 11:39:01 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA08099; Thu, 22 Jan 2004 11:39:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA07550; Thu, 22 Jan 2004 11:38:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0M2cw0j025065; Thu, 22 Jan 2004 11:38:59 +0900 (JST) Received: from steelhead ([159.119.168.86]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRV00GLME0WCC@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 11:38:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjUjf-0003E3-00; Wed, 21 Jan 2004 18:38:23 -0800 Date: Wed, 21 Jan 2004 18:38:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040122023823.GK26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040121193915.GY26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Jan 21, 2004 at 05:31:11PM -0800, Alper Yegin wrote: > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > > mean IPv4 link-local address specified in > > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > > explcitly says: > > > > "This > > document does not recommend that Link-Local IPv4 addresses and > > routable addresses be configured simultaneously on the same > > interface." > > I don't think it should be a problem to use the link-local address as the > tunnel end point, and the global address inside the tunnel. I don't think > this is what the zeroconf draft is prohibiting. OK, I see what you mean. > > Nevertheless, we can consider using the same global IP address as the tunnel > end point and as the inner IP address as soon as the PaC gets one. Any pros > and cons here? At least Windows 2000 and XP implementations, link-local address is available only after performing DHCP and the DHCP has been failed. It takes long time (about 30 seconds in my measurement) until DHCP fails, which is unacceptable. In the same implementations, if DHCP succeeds, link-local address is not available as Mohan mentioned. An advantage would be that only one stateful configuration protocol operation is needed for obtaining the inner addres. On the other hand, if we use global IP address as the outer address, unauthenticated DHCP would be performed to obtain a pre-PANA address. In an environment where the post-PANA address (i.e, the global address) is assigned to authenticated clients only, the pre-PANA and post-PANA addresses will be different. This means that two stateful configuration protocol operations will be needed, one for pre-PANA address and the other for the post-PANA address. But this is much better than waiting for lengty DHCP timeout to configure an IPv4 link-local address. Yoshihiro Ohba > > Alper > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 21 23:00:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24954 for ; Wed, 21 Jan 2004 23:00:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW0k-0000bU-Cm; Wed, 21 Jan 2004 23:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW0C-0000a2-1x for pana@optimus.ietf.org; Wed, 21 Jan 2004 22:59:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24899 for ; Wed, 21 Jan 2004 22:59:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjW08-0005dx-00 for pana@ietf.org; Wed, 21 Jan 2004 22:59:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjVzA-0005bi-00 for pana@ietf.org; Wed, 21 Jan 2004 22:58:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjVyD-0005Z9-00 for pana@ietf.org; Wed, 21 Jan 2004 22:57:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0M3vQN9018931; Thu, 22 Jan 2004 12:57:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0M3vPnE019848; Thu, 22 Jan 2004 12:57:25 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA19844 ; Thu, 22 Jan 2004 12:57:25 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA04299; Thu, 22 Jan 2004 12:57:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA10450; Thu, 22 Jan 2004 12:57:24 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0M3vM0j021604; Thu, 22 Jan 2004 12:57:23 +0900 (JST) Received: from steelhead ([159.119.168.86]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRV007R4HNL3L@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 12:57:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjVvl-0003NZ-00; Wed, 21 Jan 2004 19:54:57 -0800 Date: Wed, 21 Jan 2004 19:54:57 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00e101c3e062$0a051d30$681067c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040122035457.GN26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> <00e101c3e062$0a051d30$681067c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Jan 21, 2004 at 01:03:37PM -0800, Mohan Parthasarathy wrote: > > > > Looks better. > > > > I think that relying solely on the SPD consulting might not prevent a > > DoS attack where a malicous client performs IKE with spoofing an inner > > address *before* the legitimate client does IKE with the inner > > address. > > > Malicious client who successfully authenticated using PANA can launch > this attack. But it is the same as the DoS attack that could happen with > DAD. Yes. > > > If this is true, we might want to mention it somewhere in the draft. > > > It is mentioned in the security considerations section. Please see whether it > is enough. For more clarification, I'd suggest updating the following paragraph of the security considerations section from: "If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. The use of IPsec does not prevent this attack. PAA may use other mechanisms to prevent this attack." to: "If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. Although Section 3 describes an inner address verification method based on SPD consulting, it is still possible for an authenticated PaC to launch this attack. PAA may use other mechanisms to prevent this attack." Regards, Yoshihiro Ohba > > -mohan > > > Yoshihiro Ohba > > > > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > > New text: > > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > > before IKE exchange starts. As most of the IKE implementations assume > > > that the SPD can be consulted during the SA negotiation, it may > > > require a different behavior from IKE in the auto-configuration case. > > > In the case of auto-configuration, IKE should be able to setup the SAs > > > for the traffic selectors (which contain the PaC auto-configured address) > > > specified by the PaC without requiring a corresponding entry in the SPD. > > > If there is already an SA for the same address with a different identity > > > (specified in the ID_KEY_ID payload), then the SA MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > corresponding to the traffic selectors specified by PaC > > > for protecting the subsequent data packets." > > > > > > Comments ? > > > > > > -mohan > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 21 23:02:07 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24997 for ; Wed, 21 Jan 2004 23:02:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW2F-0000gh-M8 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 23:01:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0M41cdm002636 for pana-archive@odin.ietf.org; Wed, 21 Jan 2004 23:01:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW2D-0000gR-L9 for pana-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 23:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24993 for ; Wed, 21 Jan 2004 23:01:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjW2A-0005jV-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 23:01:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjW1F-0005hc-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 23:00:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjW0m-0005fQ-00 for pana-web-archive@ietf.org; Wed, 21 Jan 2004 23:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW0k-0000bU-Cm; Wed, 21 Jan 2004 23:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjW0C-0000a2-1x for pana@optimus.ietf.org; Wed, 21 Jan 2004 22:59:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24899 for ; Wed, 21 Jan 2004 22:59:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjW08-0005dx-00 for pana@ietf.org; Wed, 21 Jan 2004 22:59:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjVzA-0005bi-00 for pana@ietf.org; Wed, 21 Jan 2004 22:58:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjVyD-0005Z9-00 for pana@ietf.org; Wed, 21 Jan 2004 22:57:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0M3vQN9018931; Thu, 22 Jan 2004 12:57:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0M3vPnE019848; Thu, 22 Jan 2004 12:57:25 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA19844 ; Thu, 22 Jan 2004 12:57:25 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA04299; Thu, 22 Jan 2004 12:57:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA10450; Thu, 22 Jan 2004 12:57:24 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0M3vM0j021604; Thu, 22 Jan 2004 12:57:23 +0900 (JST) Received: from steelhead ([159.119.168.86]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRV007R4HNL3L@tsbpo1.po.toshiba.co.jp>; Thu, 22 Jan 2004 12:57:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjVvl-0003NZ-00; Wed, 21 Jan 2004 19:54:57 -0800 Date: Wed, 21 Jan 2004 19:54:57 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] PANA-IPsec-01 In-reply-to: <00e101c3e062$0a051d30$681067c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040122035457.GN26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> <00e101c3e062$0a051d30$681067c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Jan 21, 2004 at 01:03:37PM -0800, Mohan Parthasarathy wrote: > > > > Looks better. > > > > I think that relying solely on the SPD consulting might not prevent a > > DoS attack where a malicous client performs IKE with spoofing an inner > > address *before* the legitimate client does IKE with the inner > > address. > > > Malicious client who successfully authenticated using PANA can launch > this attack. But it is the same as the DoS attack that could happen with > DAD. Yes. > > > If this is true, we might want to mention it somewhere in the draft. > > > It is mentioned in the security considerations section. Please see whether it > is enough. For more clarification, I'd suggest updating the following paragraph of the security considerations section from: "If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. The use of IPsec does not prevent this attack. PAA may use other mechanisms to prevent this attack." to: "If the PAA does not verify whether PaC is authorized to use an IP address, it is possible for the PaC to steal the traffic destined to some other PaC. Although Section 3 describes an inner address verification method based on SPD consulting, it is still possible for an authenticated PaC to launch this attack. PAA may use other mechanisms to prevent this attack." Regards, Yoshihiro Ohba > > -mohan > > > Yoshihiro Ohba > > > > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > > New text: > > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > > before IKE exchange starts. As most of the IKE implementations assume > > > that the SPD can be consulted during the SA negotiation, it may > > > require a different behavior from IKE in the auto-configuration case. > > > In the case of auto-configuration, IKE should be able to setup the SAs > > > for the traffic selectors (which contain the PaC auto-configured address) > > > specified by the PaC without requiring a corresponding entry in the SPD. > > > If there is already an SA for the same address with a different identity > > > (specified in the ID_KEY_ID payload), then the SA MUST > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > authenticates itself successfully, EP should add the SPD entry > > > corresponding to the traffic selectors specified by PaC > > > for protecting the subsequent data packets." > > > > > > Comments ? > > > > > > -mohan > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 06:53:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17522 for ; Thu, 22 Jan 2004 06:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdOP-0003WK-OJ; Thu, 22 Jan 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdOC-0003W5-Nr for pana@optimus.ietf.org; Thu, 22 Jan 2004 06:52:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17511 for ; Thu, 22 Jan 2004 06:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjdO8-000584-00 for pana@ietf.org; Thu, 22 Jan 2004 06:52:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjdNF-000570-00 for pana@ietf.org; Thu, 22 Jan 2004 06:51:49 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AjdN0-00055L-00 for pana@ietf.org; Thu, 22 Jan 2004 06:51:35 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 38C2A34069; Thu, 22 Jan 2004 12:35:57 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 1FE9F3F4B9; Thu, 22 Jan 2004 12:35:56 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012212355630674 ; Thu, 22 Jan 2004 12:35:56 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 65FDC3F4B3; Thu, 22 Jan 2004 12:35:56 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Ajd5w-000C21-Mc; Thu, 22 Jan 2004 12:33:56 +0100 Date: Thu, 22 Jan 2004 12:33:56 +0100 From: Julien Bournelle To: pana@ietf.org Cc: yohba@tari.toshiba.com Subject: Re: [Pana] issue 38 Message-ID: <20040122113356.GJ43575@ipv6-5.int-evry.fr> References: <20040121174747.GU26285@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040121174747.GU26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi, please see comments inline, On Wed, Jan 21, 2004 at 09:47:47AM -0800, Yoshihiro Ohba wrote: > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. I'm not totally convinced by this argument, if we negotiate only strong algorithms, we'll not have weak algorithm. Do I miss something ? However I agree that it will add complexity and I'm not in favor of adding this feature. I agree with your text. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 06:55:22 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17557 for ; Thu, 22 Jan 2004 06:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdQG-0003hj-3r for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 06:54:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MBsugw014208 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 06:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdQF-0003gm-QO for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 06:54:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17545 for ; Thu, 22 Jan 2004 06:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjdQB-0005FC-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 06:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjdPG-0005BC-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 06:53:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjdOO-00058S-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 06:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdOP-0003WK-OJ; Thu, 22 Jan 2004 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjdOC-0003W5-Nr for pana@optimus.ietf.org; Thu, 22 Jan 2004 06:52:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17511 for ; Thu, 22 Jan 2004 06:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjdO8-000584-00 for pana@ietf.org; Thu, 22 Jan 2004 06:52:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjdNF-000570-00 for pana@ietf.org; Thu, 22 Jan 2004 06:51:49 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AjdN0-00055L-00 for pana@ietf.org; Thu, 22 Jan 2004 06:51:35 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 38C2A34069; Thu, 22 Jan 2004 12:35:57 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 1FE9F3F4B9; Thu, 22 Jan 2004 12:35:56 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012212355630674 ; Thu, 22 Jan 2004 12:35:56 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 65FDC3F4B3; Thu, 22 Jan 2004 12:35:56 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Ajd5w-000C21-Mc; Thu, 22 Jan 2004 12:33:56 +0100 Date: Thu, 22 Jan 2004 12:33:56 +0100 From: Julien Bournelle To: pana@ietf.org Cc: yohba@tari.toshiba.com Subject: Re: [Pana] issue 38 Message-ID: <20040122113356.GJ43575@ipv6-5.int-evry.fr> References: <20040121174747.GU26285@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040121174747.GU26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, please see comments inline, On Wed, Jan 21, 2004 at 09:47:47AM -0800, Yoshihiro Ohba wrote: > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. I'm not totally convinced by this argument, if we negotiate only strong algorithms, we'll not have weak algorithm. Do I miss something ? However I agree that it will add complexity and I'm not in favor of adding this feature. I agree with your text. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 10:38:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25251 for ; Thu, 22 Jan 2004 10:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjguA-0005rS-LF; Thu, 22 Jan 2004 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgu1-0005lx-AT for pana@optimus.ietf.org; Thu, 22 Jan 2004 10:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25181 for ; Thu, 22 Jan 2004 10:37:46 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgtj-0007Gw-00 for pana@ietf.org; Thu, 22 Jan 2004 10:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjgsG-0007C7-00 for pana@ietf.org; Thu, 22 Jan 2004 10:36:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AjgqX-00075W-00 for pana@ietf.org; Thu, 22 Jan 2004 10:34:17 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0MFY5V28775 for ; Thu, 22 Jan 2004 17:34:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Jan 2004 17:33:41 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 17:33:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 38 Date: Thu, 22 Jan 2004 17:33:40 +0200 Message-ID: Thread-Topic: [Pana] issue 38 Thread-Index: AcPgR0Hw21wNaA9MSqyAp+lkRUbgYQAtcj4Q To: , X-OriginalArrivalTime: 22 Jan 2004 15:33:40.0890 (UTC) FILETIME=[1CAC2FA0:01C3E0FD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This becomes a MUST requirement for PaC and PAA to support both MAC algorithms.. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 21 January, 2004 19:48 > To: pana@ietf.org > Subject: [Pana] issue 38 > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified > section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. > Instead, the PAA should specify which algorithm is used. As a result, > the PaC either accepts the specified algorithm or fails to complete > authentication successfully. > > Here is suggested text: > > In section 4.1.6, change: > > "When a MAC AVP is included in a PANA message, the value > field of the > MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0." > > > to: > > "When a MAC AVP is included in a PANA message, the value > field of the > MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > represents the pseudo random function corresponding to the MAC > algorithm specified in the MAC AVP. In this version of draft, > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > use the same algorithm to calculate a MAC AVP they originate and > receive. The algorithm is determined by the PAA when > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > support the MAC algorithm specified in the PANA-Bind-Request > message, it MUST silently discard the message. The PAA MUST NOT > change the MAC algorithm throughout the continuation of the PANA > session." > > > Regards, > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 10:39:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25399 for ; Thu, 22 Jan 2004 10:39:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgv6-0006HQ-0w; Thu, 22 Jan 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgv0-0006Ft-I9 for pana@optimus.ietf.org; Thu, 22 Jan 2004 10:38:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25311 for ; Thu, 22 Jan 2004 10:38:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajguy-0007Nw-00 for pana@ietf.org; Thu, 22 Jan 2004 10:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajgtz-0007Ir-00 for pana@ietf.org; Thu, 22 Jan 2004 10:37:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgt5-0007Cq-00 for pana@ietf.org; Thu, 22 Jan 2004 10:36:55 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0MFahV02086 for ; Thu, 22 Jan 2004 17:36:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Jan 2004 17:36:40 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 17:36:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Thu, 22 Jan 2004 17:36:40 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPck5gopOsZxxTSQCyk7Bz4IPb8twEadx2g To: , X-OriginalArrivalTime: 22 Jan 2004 15:36:40.0823 (UTC) FILETIME=[87EBC870:01C3E0FD] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess an error should be sent instead then, not the PBR msg. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 17 January, 2004 02:44 > To: pana@ietf.org > Subject: [Pana] EAP-Payload in PBR (new issue) > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > PANA-Bind-Request. However, it is possible that EAP conversation > fails without generating a EAP-Success or EAP-Failure message, > specifically when a AAA timeout occurs (please see EAP Full > Authenticator State Machine diagram in the EAP state machines draft, > pdf version). > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 10:40:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25468 for ; Thu, 22 Jan 2004 10:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjgwA-0006WB-JE for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 10:40:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFe665025043 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 10:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgw8-0006Vf-VE for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 10:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25449 for ; Thu, 22 Jan 2004 10:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgw6-0007UN-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:40:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajgv9-0007Py-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjguB-0007Kn-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjguA-0005rS-LF; Thu, 22 Jan 2004 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgu1-0005lx-AT for pana@optimus.ietf.org; Thu, 22 Jan 2004 10:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25181 for ; Thu, 22 Jan 2004 10:37:46 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgtj-0007Gw-00 for pana@ietf.org; Thu, 22 Jan 2004 10:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjgsG-0007C7-00 for pana@ietf.org; Thu, 22 Jan 2004 10:36:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AjgqX-00075W-00 for pana@ietf.org; Thu, 22 Jan 2004 10:34:17 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0MFY5V28775 for ; Thu, 22 Jan 2004 17:34:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Jan 2004 17:33:41 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 17:33:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 38 Date: Thu, 22 Jan 2004 17:33:40 +0200 Message-ID: Thread-Topic: [Pana] issue 38 Thread-Index: AcPgR0Hw21wNaA9MSqyAp+lkRUbgYQAtcj4Q To: , X-OriginalArrivalTime: 22 Jan 2004 15:33:40.0890 (UTC) FILETIME=[1CAC2FA0:01C3E0FD] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This becomes a MUST requirement for PaC and PAA to support both MAC algorithms.. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 21 January, 2004 19:48 > To: pana@ietf.org > Subject: [Pana] issue 38 > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified > section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. > Instead, the PAA should specify which algorithm is used. As a result, > the PaC either accepts the specified algorithm or fails to complete > authentication successfully. > > Here is suggested text: > > In section 4.1.6, change: > > "When a MAC AVP is included in a PANA message, the value > field of the > MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0." > > > to: > > "When a MAC AVP is included in a PANA message, the value > field of the > MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > represents the pseudo random function corresponding to the MAC > algorithm specified in the MAC AVP. In this version of draft, > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > use the same algorithm to calculate a MAC AVP they originate and > receive. The algorithm is determined by the PAA when > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > support the MAC algorithm specified in the PANA-Bind-Request > message, it MUST silently discard the message. The PAA MUST NOT > change the MAC algorithm throughout the continuation of the PANA > session." > > > Regards, > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 10:41:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25555 for ; Thu, 22 Jan 2004 10:41:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgwy-0006cs-Tp for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 10:40:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MFeuj9025462 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 10:40:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgwy-0006cb-PX for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 10:40:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25510 for ; Thu, 22 Jan 2004 10:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgww-0007Wi-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:40:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajgvz-0007TD-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:39:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajgv4-0007Oz-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 10:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgv6-0006HQ-0w; Thu, 22 Jan 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajgv0-0006Ft-I9 for pana@optimus.ietf.org; Thu, 22 Jan 2004 10:38:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25311 for ; Thu, 22 Jan 2004 10:38:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajguy-0007Nw-00 for pana@ietf.org; Thu, 22 Jan 2004 10:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajgtz-0007Ir-00 for pana@ietf.org; Thu, 22 Jan 2004 10:37:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Ajgt5-0007Cq-00 for pana@ietf.org; Thu, 22 Jan 2004 10:36:55 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0MFahV02086 for ; Thu, 22 Jan 2004 17:36:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 22 Jan 2004 17:36:40 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 22 Jan 2004 17:36:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Thu, 22 Jan 2004 17:36:40 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPck5gopOsZxxTSQCyk7Bz4IPb8twEadx2g To: , X-OriginalArrivalTime: 22 Jan 2004 15:36:40.0823 (UTC) FILETIME=[87EBC870:01C3E0FD] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I guess an error should be sent instead then, not the PBR msg. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 17 January, 2004 02:44 > To: pana@ietf.org > Subject: [Pana] EAP-Payload in PBR (new issue) > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > PANA-Bind-Request. However, it is possible that EAP conversation > fails without generating a EAP-Success or EAP-Failure message, > specifically when a AAA timeout occurs (please see EAP Full > Authenticator State Machine diagram in the EAP state machines draft, > pdf version). > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 11:45:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28321 for ; Thu, 22 Jan 2004 11:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajhx0-0004hy-Gp; Thu, 22 Jan 2004 11:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajhw6-0004cN-Sx for pana@optimus.ietf.org; Thu, 22 Jan 2004 11:44:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27926 for ; Thu, 22 Jan 2004 11:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajhw5-0004Mu-00 for pana@ietf.org; Thu, 22 Jan 2004 11:44:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajhqr-0003dt-00 for pana@ietf.org; Thu, 22 Jan 2004 11:38:42 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ajhc7-0002qs-00 for pana@ietf.org; Thu, 22 Jan 2004 11:23:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MGN0N9013018; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MGN0JL008238; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA08237 ; Fri, 23 Jan 2004 01:23:00 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA01084; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25153; Fri, 23 Jan 2004 01:22:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MGMw0j011529; Fri, 23 Jan 2004 01:22:59 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW0094LG681M@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 01:22:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjhYm-0003jP-00; Thu, 22 Jan 2004 08:20:00 -0800 Date: Thu, 22 Jan 2004 08:19:59 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040122161959.GO26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 22, 2004 at 05:33:40PM +0200, Dan.Forsberg@nokia.com wrote: > This becomes a MUST requirement for PaC and PAA to support both MAC algorithms.. Could you elaborate on this? Yoshihiro Ohba > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > Behalf Of ext Yoshihiro Ohba > > Sent: 21 January, 2004 19:48 > > To: pana@ietf.org > > Subject: [Pana] issue 38 > > > > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > > > It is true that in sectionm 9.4.1, multiple hash algorithms are > > supported for MAC AVP, while only HMAC-SHA1 is specified > > section 4.1.6. > > > > There is also an issue of whether PANA should allow negotiation of MAC > > algorithm. I think PANA should not allow algorithm negotiation, since > > there is a possible downgrading attack if negotiation is allowed. > > Instead, the PAA should specify which algorithm is used. As a result, > > the PaC either accepts the specified algorithm or fails to complete > > authentication successfully. > > > > Here is suggested text: > > > > In section 4.1.6, change: > > > > "When a MAC AVP is included in a PANA message, the value > > field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the > > following way: > > > > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0." > > > > > > to: > > > > "When a MAC AVP is included in a PANA message, the value > > field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the > > following way: > > > > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > represents the pseudo random function corresponding to the MAC > > algorithm specified in the MAC AVP. In this version of draft, > > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > > use the same algorithm to calculate a MAC AVP they originate and > > receive. The algorithm is determined by the PAA when > > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > > support the MAC algorithm specified in the PANA-Bind-Request > > message, it MUST silently discard the message. The PAA MUST NOT > > change the MAC algorithm throughout the continuation of the PANA > > session." > > > > > > Regards, > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 11:49:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29016 for ; Thu, 22 Jan 2004 11:49:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aji0e-0005E3-Rm for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 11:48:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MGmmRA020081 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 11:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aji0e-0005Do-My for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 11:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28944 for ; Thu, 22 Jan 2004 11:48:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aji0d-0005Ke-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 11:48:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajhz5-000542-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 11:47:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajhx7-0004cL-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 11:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajhx0-0004hy-Gp; Thu, 22 Jan 2004 11:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajhw6-0004cN-Sx for pana@optimus.ietf.org; Thu, 22 Jan 2004 11:44:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27926 for ; Thu, 22 Jan 2004 11:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajhw5-0004Mu-00 for pana@ietf.org; Thu, 22 Jan 2004 11:44:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajhqr-0003dt-00 for pana@ietf.org; Thu, 22 Jan 2004 11:38:42 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ajhc7-0002qs-00 for pana@ietf.org; Thu, 22 Jan 2004 11:23:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MGN0N9013018; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MGN0JL008238; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA08237 ; Fri, 23 Jan 2004 01:23:00 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA01084; Fri, 23 Jan 2004 01:23:00 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25153; Fri, 23 Jan 2004 01:22:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MGMw0j011529; Fri, 23 Jan 2004 01:22:59 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW0094LG681M@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 01:22:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjhYm-0003jP-00; Thu, 22 Jan 2004 08:20:00 -0800 Date: Thu, 22 Jan 2004 08:19:59 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040122161959.GO26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Jan 22, 2004 at 05:33:40PM +0200, Dan.Forsberg@nokia.com wrote: > This becomes a MUST requirement for PaC and PAA to support both MAC algorithms.. Could you elaborate on this? Yoshihiro Ohba > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > Behalf Of ext Yoshihiro Ohba > > Sent: 21 January, 2004 19:48 > > To: pana@ietf.org > > Subject: [Pana] issue 38 > > > > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > > > It is true that in sectionm 9.4.1, multiple hash algorithms are > > supported for MAC AVP, while only HMAC-SHA1 is specified > > section 4.1.6. > > > > There is also an issue of whether PANA should allow negotiation of MAC > > algorithm. I think PANA should not allow algorithm negotiation, since > > there is a possible downgrading attack if negotiation is allowed. > > Instead, the PAA should specify which algorithm is used. As a result, > > the PaC either accepts the specified algorithm or fails to complete > > authentication successfully. > > > > Here is suggested text: > > > > In section 4.1.6, change: > > > > "When a MAC AVP is included in a PANA message, the value > > field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the > > following way: > > > > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0." > > > > > > to: > > > > "When a MAC AVP is included in a PANA message, the value > > field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the > > following way: > > > > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > represents the pseudo random function corresponding to the MAC > > algorithm specified in the MAC AVP. In this version of draft, > > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > > use the same algorithm to calculate a MAC AVP they originate and > > receive. The algorithm is determined by the PAA when > > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > > support the MAC algorithm specified in the PANA-Bind-Request > > message, it MUST silently discard the message. The PAA MUST NOT > > change the MAC algorithm throughout the continuation of the PANA > > session." > > > > > > Regards, > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 12:35:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00571 for ; Thu, 22 Jan 2004 12:35:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjijN-0000kR-Bc; Thu, 22 Jan 2004 12:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiin-0000jo-FD for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00519 for ; Thu, 22 Jan 2004 12:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajiig-0007Uh-00 for pana@ietf.org; Thu, 22 Jan 2004 12:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjieK-0007IW-00 for pana@ietf.org; Thu, 22 Jan 2004 12:29:49 -0500 Received: from smtp806.mail.sc5.yahoo.com ([66.163.168.185]) by ietf-mx with smtp (Exim 4.12) id 1AjiaY-00073W-00 for pana@ietf.org; Thu, 22 Jan 2004 12:25:54 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 17:24:52 -0000 Message-ID: <002b01c3e10c$a75860b0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> <00e101c3e062$0a051d30$681067c0@adithya> <20040122035457.GN26285@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 22 Jan 2004 09:24:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wed, Jan 21, 2004 at 01:03:37PM -0800, Mohan Parthasarathy wrote: > > > > > > Looks better. > > > > > > I think that relying solely on the SPD consulting might not prevent a > > > DoS attack where a malicous client performs IKE with spoofing an inner > > > address *before* the legitimate client does IKE with the inner > > > address. > > > > > Malicious client who successfully authenticated using PANA can launch > > this attack. But it is the same as the DoS attack that could happen with > > DAD. > > Yes. > > > > > > If this is true, we might want to mention it somewhere in the draft. > > > > > It is mentioned in the security considerations section. Please see whether it > > is enough. > > For more clarification, I'd suggest updating the following paragraph > of the security considerations section > > from: > > "If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. The use of IPsec does not prevent this attack. PAA > may use other mechanisms to prevent this attack." > > to: > > "If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. Although Section 3 describes an inner address > verification method based on SPD consulting, it is still possible > for an authenticated PaC to launch this attack. PAA may use other > mechanisms to prevent this attack." Ok. -mohan > > Regards, > > Yoshihiro Ohba > > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > > > New text: > > > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > > > before IKE exchange starts. As most of the IKE implementations assume > > > > that the SPD can be consulted during the SA negotiation, it may > > > > require a different behavior from IKE in the auto-configuration case. > > > > In the case of auto-configuration, IKE should be able to setup the SAs > > > > for the traffic selectors (which contain the PaC auto-configured address) > > > > specified by the PaC without requiring a corresponding entry in the SPD. > > > > If there is already an SA for the same address with a different identity > > > > (specified in the ID_KEY_ID payload), then the SA MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > corresponding to the traffic selectors specified by PaC > > > > for protecting the subsequent data packets." > > > > > > > > Comments ? > > > > > > > > -mohan > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 12:43:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00895 for ; Thu, 22 Jan 2004 12:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajir2-0001b3-0U for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:42:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHgtra006131 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajir1-0001ao-Rv for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00873 for ; Thu, 22 Jan 2004 12:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajiqv-0000BF-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:42:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjinP-0007nF-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:39:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajijj-0007aK-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:35:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjijN-0000kR-Bc; Thu, 22 Jan 2004 12:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiin-0000jo-FD for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00519 for ; Thu, 22 Jan 2004 12:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajiig-0007Uh-00 for pana@ietf.org; Thu, 22 Jan 2004 12:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjieK-0007IW-00 for pana@ietf.org; Thu, 22 Jan 2004 12:29:49 -0500 Received: from smtp806.mail.sc5.yahoo.com ([66.163.168.185]) by ietf-mx with smtp (Exim 4.12) id 1AjiaY-00073W-00 for pana@ietf.org; Thu, 22 Jan 2004 12:25:54 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 17:24:52 -0000 Message-ID: <002b01c3e10c$a75860b0$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <017e01c3db0f$cd01b760$c91167c0@adithya> <20040115031503.GC4868@steelhead> <00b701c3dbc4$7284bac0$c91167c0@adithya> <20040116005413.GE9900@steelhead> <006201c3dc7a$61d1b500$c91167c0@adithya> <012301c3dfa0$f0236a00$c91167c0@adithya> <20040121192723.GX26285@steelhead> <00e101c3e062$0a051d30$681067c0@adithya> <20040122035457.GN26285@steelhead> Subject: Re: [Pana] PANA-IPsec-01 Date: Thu, 22 Jan 2004 09:24:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Wed, Jan 21, 2004 at 01:03:37PM -0800, Mohan Parthasarathy wrote: > > > > > > Looks better. > > > > > > I think that relying solely on the SPD consulting might not prevent a > > > DoS attack where a malicous client performs IKE with spoofing an inner > > > address *before* the legitimate client does IKE with the inner > > > address. > > > > > Malicious client who successfully authenticated using PANA can launch > > this attack. But it is the same as the DoS attack that could happen with > > DAD. > > Yes. > > > > > > If this is true, we might want to mention it somewhere in the draft. > > > > > It is mentioned in the security considerations section. Please see whether it > > is enough. > > For more clarification, I'd suggest updating the following paragraph > of the security considerations section > > from: > > "If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. The use of IPsec does not prevent this attack. PAA > may use other mechanisms to prevent this attack." > > to: > > "If the PAA does not verify whether PaC is authorized to use an IP > address, it is possible for the PaC to steal the traffic destined to > some other PaC. Although Section 3 describes an inner address > verification method based on SPD consulting, it is still possible > for an authenticated PaC to launch this attack. PAA may use other > mechanisms to prevent this attack." Ok. -mohan > > Regards, > > Yoshihiro Ohba > > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Jan 20, 2004 at 02:01:20PM -0800, Mohan Parthasarathy wrote: > > > > New text: > > > > Thus, it may not be able to setup the SPD entries for the PaC appropriately > > > > before IKE exchange starts. As most of the IKE implementations assume > > > > that the SPD can be consulted during the SA negotiation, it may > > > > require a different behavior from IKE in the auto-configuration case. > > > > In the case of auto-configuration, IKE should be able to setup the SAs > > > > for the traffic selectors (which contain the PaC auto-configured address) > > > > specified by the PaC without requiring a corresponding entry in the SPD. > > > > If there is already an SA for the same address with a different identity > > > > (specified in the ID_KEY_ID payload), then the SA MUST > > > > be rejected with INVALID-ID-INFORMATION [IKE]. If PaC > > > > authenticates itself successfully, EP should add the SPD entry > > > > corresponding to the traffic selectors specified by PaC > > > > for protecting the subsequent data packets." > > > > > > > > Comments ? > > > > > > > > -mohan > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 12:44:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01054 for ; Thu, 22 Jan 2004 12:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajis5-0001gJ-ED; Thu, 22 Jan 2004 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajis1-0001f3-OD for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00958 for ; Thu, 22 Jan 2004 12:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajirz-0000G3-00 for pana@ietf.org; Thu, 22 Jan 2004 12:43:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajiov-00005E-00 for pana@ietf.org; Thu, 22 Jan 2004 12:40:46 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjilZ-0007fm-00 for pana@ietf.org; Thu, 22 Jan 2004 12:37:17 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MHaoN9029372; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MHaoIl029809; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA29808 ; Fri, 23 Jan 2004 02:36:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA06898; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA08050; Fri, 23 Jan 2004 02:18:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MHI50j020177; Fri, 23 Jan 2004 02:18:05 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW009S2IQ31M@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 02:18:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjiSs-0003q4-00; Thu, 22 Jan 2004 09:17:58 -0800 Date: Thu, 22 Jan 2004 09:17:58 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] EAP-Payload in PBR (new issue) In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040122171758.GP26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I thought that PANA-Error message is used for errors occured within PANA. But in this case, the error is an EAP authentication failure and I think it should be carried by PANA authentication success/failure message (i.e., PBR). (There is another problem with using PANA-Error for this case: Which AVP is considered invalid and carried in Failed-AVP?) Yoshihiro Ohba On Thu, Jan 22, 2004 at 05:36:40PM +0200, Dan.Forsberg@nokia.com wrote: > I guess an error should be sent instead then, not the PBR msg. > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > Behalf Of ext Yoshihiro Ohba > > Sent: 17 January, 2004 02:44 > > To: pana@ietf.org > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > PANA-Bind-Request. However, it is possible that EAP conversation > > fails without generating a EAP-Success or EAP-Failure message, > > specifically when a AAA timeout occurs (please see EAP Full > > Authenticator State Machine diagram in the EAP state machines draft, > > pdf version). > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 12:46:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01214 for ; Thu, 22 Jan 2004 12:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiu0-0001z5-VH; Thu, 22 Jan 2004 12:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjitD-0001sL-30 for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01088 for ; Thu, 22 Jan 2004 12:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjitB-0000Qy-00 for pana@ietf.org; Thu, 22 Jan 2004 12:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajis9-0000J6-00 for pana@ietf.org; Thu, 22 Jan 2004 12:44:07 -0500 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1Ajiq3-00006L-00 for pana@ietf.org; Thu, 22 Jan 2004 12:41:55 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 17:40:42 -0000 Message-ID: <003101c3e10e$dd826d50$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: References: <20040121193915.GY26285@steelhead> <20040122023823.GK26285@steelhead> Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Thu, 22 Jan 2004 09:40:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > On Wed, Jan 21, 2004 at 05:31:11PM -0800, Alper Yegin wrote: > > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > > > mean IPv4 link-local address specified in > > > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > > > explcitly says: > > > > > > "This > > > document does not recommend that Link-Local IPv4 addresses and > > > routable addresses be configured simultaneously on the same > > > interface." > > > > I don't think it should be a problem to use the link-local address as the > > tunnel end point, and the global address inside the tunnel. I don't think > > this is what the zeroconf draft is prohibiting. > > OK, I see what you mean. > > > > > Nevertheless, we can consider using the same global IP address as the tunnel > > end point and as the inner IP address as soon as the PaC gets one. Any pros > > and cons here? > > At least Windows 2000 and XP implementations, link-local address is > available only after performing DHCP and the DHCP has been failed. It > takes long time (about 30 seconds in my measurement) until DHCP fails, > which is unacceptable. In the same implementations, if DHCP succeeds, > link-local address is not available as Mohan mentioned. An advantage > would be that only one stateful configuration protocol operation is > needed for obtaining the inner addres. > One of the reasons we started using link-local address in PANA is to stay compatible with what the majority of the clients do today as you described above. There may be an advantage, but the deployment may not allow it e.g. where address is assigned from your ISP only after authentication. > On the other hand, if we use global IP address as the outer address, > unauthenticated DHCP would be performed to obtain a pre-PANA address. > In an environment where the post-PANA address (i.e, the global > address) is assigned to authenticated clients only, the pre-PANA and > post-PANA addresses will be different. This means that two stateful > configuration protocol operations will be needed, one for pre-PANA > address and the other for the post-PANA address. But this is much > better than waiting for lengty DHCP timeout to configure an IPv4 > link-local address. > I agree with this. 30 second delay might be too much. And this does not need any change in the behavior of the existing clients. So, i assume that the pre-pana address can be a RFC1918 private address. What should be the lease time for the pre-pana address i.e what should be recommended ? If you want to tunnel all packets using the pre-pana address (for the outer), then it makes sense to keep the lifetime of both the addresses same. Addresses might time out independently but it should not cause any problems i guess. If we recommend a very small lease time for the pre-pana address, then we should use the post-pana address for both inner and outer address. I know of some implementations that has problem with this (tunnel module drops the packets destined to the outer address itself as it thinks there is a routing loop). But as we have only PANA protocol packets destined to EP/PAA itself, we can setup a bypass rule for this in the SPD. -mohan > Yoshihiro Ohba > > > > > > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 12:46:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01231 for ; Thu, 22 Jan 2004 12:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiu7-00021C-Ri for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:46:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHk752007752 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiu7-00020x-MM for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01170 for ; Thu, 22 Jan 2004 12:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajiu6-0000XC-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:46:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajit8-0000QZ-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:45:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajis8-0000Is-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajis5-0001gJ-ED; Thu, 22 Jan 2004 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajis1-0001f3-OD for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:43:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00958 for ; Thu, 22 Jan 2004 12:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajirz-0000G3-00 for pana@ietf.org; Thu, 22 Jan 2004 12:43:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajiov-00005E-00 for pana@ietf.org; Thu, 22 Jan 2004 12:40:46 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjilZ-0007fm-00 for pana@ietf.org; Thu, 22 Jan 2004 12:37:17 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MHaoN9029372; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MHaoIl029809; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA29808 ; Fri, 23 Jan 2004 02:36:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA06898; Fri, 23 Jan 2004 02:36:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA08050; Fri, 23 Jan 2004 02:18:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MHI50j020177; Fri, 23 Jan 2004 02:18:05 +0900 (JST) Received: from steelhead ([159.119.168.106]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW009S2IQ31M@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 02:18:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjiSs-0003q4-00; Thu, 22 Jan 2004 09:17:58 -0800 Date: Thu, 22 Jan 2004 09:17:58 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] EAP-Payload in PBR (new issue) In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040122171758.GP26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I thought that PANA-Error message is used for errors occured within PANA. But in this case, the error is an EAP authentication failure and I think it should be carried by PANA authentication success/failure message (i.e., PBR). (There is another problem with using PANA-Error for this case: Which AVP is considered invalid and carried in Failed-AVP?) Yoshihiro Ohba On Thu, Jan 22, 2004 at 05:36:40PM +0200, Dan.Forsberg@nokia.com wrote: > I guess an error should be sent instead then, not the PBR msg. > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > Behalf Of ext Yoshihiro Ohba > > Sent: 17 January, 2004 02:44 > > To: pana@ietf.org > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > PANA-Bind-Request. However, it is possible that EAP conversation > > fails without generating a EAP-Success or EAP-Failure message, > > specifically when a AAA timeout occurs (please see EAP Full > > Authenticator State Machine diagram in the EAP state machines draft, > > pdf version). > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 12:48:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01422 for ; Thu, 22 Jan 2004 12:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajivv-0002Dw-7b for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:47:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHlxOk008542 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 12:47:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajivv-0002Dh-2N for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:47:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01401 for ; Thu, 22 Jan 2004 12:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajivt-0000hg-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:47:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajiuz-0000dK-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:47:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajiu4-0000Wz-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 12:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajiu0-0001z5-VH; Thu, 22 Jan 2004 12:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjitD-0001sL-30 for pana@optimus.ietf.org; Thu, 22 Jan 2004 12:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01088 for ; Thu, 22 Jan 2004 12:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjitB-0000Qy-00 for pana@ietf.org; Thu, 22 Jan 2004 12:45:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajis9-0000J6-00 for pana@ietf.org; Thu, 22 Jan 2004 12:44:07 -0500 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1Ajiq3-00006L-00 for pana@ietf.org; Thu, 22 Jan 2004 12:41:55 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 22 Jan 2004 17:40:42 -0000 Message-ID: <003101c3e10e$dd826d50$681067c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: References: <20040121193915.GY26285@steelhead> <20040122023823.GK26285@steelhead> Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Thu, 22 Jan 2004 09:40:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Wed, Jan 21, 2004 at 05:31:11PM -0800, Alper Yegin wrote: > > > I am not sure what PAC-LINK-LOCAL means in the case of IPv4. Does it > > > mean IPv4 link-local address specified in > > > draft-ietf-zeroconf-ipv4-linklocal? If so, the IPv4 link-local draft > > > explcitly says: > > > > > > "This > > > document does not recommend that Link-Local IPv4 addresses and > > > routable addresses be configured simultaneously on the same > > > interface." > > > > I don't think it should be a problem to use the link-local address as the > > tunnel end point, and the global address inside the tunnel. I don't think > > this is what the zeroconf draft is prohibiting. > > OK, I see what you mean. > > > > > Nevertheless, we can consider using the same global IP address as the tunnel > > end point and as the inner IP address as soon as the PaC gets one. Any pros > > and cons here? > > At least Windows 2000 and XP implementations, link-local address is > available only after performing DHCP and the DHCP has been failed. It > takes long time (about 30 seconds in my measurement) until DHCP fails, > which is unacceptable. In the same implementations, if DHCP succeeds, > link-local address is not available as Mohan mentioned. An advantage > would be that only one stateful configuration protocol operation is > needed for obtaining the inner addres. > One of the reasons we started using link-local address in PANA is to stay compatible with what the majority of the clients do today as you described above. There may be an advantage, but the deployment may not allow it e.g. where address is assigned from your ISP only after authentication. > On the other hand, if we use global IP address as the outer address, > unauthenticated DHCP would be performed to obtain a pre-PANA address. > In an environment where the post-PANA address (i.e, the global > address) is assigned to authenticated clients only, the pre-PANA and > post-PANA addresses will be different. This means that two stateful > configuration protocol operations will be needed, one for pre-PANA > address and the other for the post-PANA address. But this is much > better than waiting for lengty DHCP timeout to configure an IPv4 > link-local address. > I agree with this. 30 second delay might be too much. And this does not need any change in the behavior of the existing clients. So, i assume that the pre-pana address can be a RFC1918 private address. What should be the lease time for the pre-pana address i.e what should be recommended ? If you want to tunnel all packets using the pre-pana address (for the outer), then it makes sense to keep the lifetime of both the addresses same. Addresses might time out independently but it should not cause any problems i guess. If we recommend a very small lease time for the pre-pana address, then we should use the post-pana address for both inner and outer address. I know of some implementations that has problem with this (tunnel module drops the packets destined to the outer address itself as it thinks there is a routing loop). But as we have only PANA protocol packets destined to EP/PAA itself, we can setup a bypass rule for this in the SPD. -mohan > Yoshihiro Ohba > > > > > > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 15:33:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09002 for ; Thu, 22 Jan 2004 15:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlVd-0007JO-Lm; Thu, 22 Jan 2004 15:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlUi-00074d-W8 for pana@optimus.ietf.org; Thu, 22 Jan 2004 15:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08682 for ; Thu, 22 Jan 2004 15:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlUh-0006Ip-00 for pana@ietf.org; Thu, 22 Jan 2004 15:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlPU-0005tL-00 for pana@ietf.org; Thu, 22 Jan 2004 15:26:43 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjlIz-0005Pp-00 for pana@ietf.org; Thu, 22 Jan 2004 15:19:57 -0500 Date: Thu, 22 Jan 2004 12:19:29 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: Message-ID: In-Reply-To: <003101c3e10e$dd826d50$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> Nevertheless, we can consider using the same global IP address as the tunnel >>> end point and as the inner IP address as soon as the PaC gets one. Any pros >>> and cons here? >> >> At least Windows 2000 and XP implementations, link-local address is >> available only after performing DHCP and the DHCP has been failed. It >> takes long time (about 30 seconds in my measurement) until DHCP fails, >> which is unacceptable. In the same implementations, if DHCP succeeds, >> link-local address is not available as Mohan mentioned. An advantage >> would be that only one stateful configuration protocol operation is >> needed for obtaining the inner addres. >> > One of the reasons we started using link-local address in PANA is to stay > compatible with what the majority of the clients do today as you described > above. There may be an advantage, but the deployment may not allow > it e.g. where address is assigned from your ISP only after authentication. As normal, the IPv4 host would attempt DHCP. If it fails, it will fall back to link-local addresses. So, before the PANA run, the host will have one of these: 1- a link-local IPv4 address (using zeroconf) 2- a DHCP address that it will also use for data communication later 3- a DHCP address that is only used during PANA 4- a DHCP address that is used during PANA, and also as the tunnel end point later After PANA, the client will attempt getting another IPv4 address depending on the information in the PANA bind message. Only case 2 above does not require another IP address acqusition. The same PANA bind message will also imply whether the current IP address should be unconfigured prior to configuring the new one. If IPsec tunneling is used, the pre-PANA address will be maintained as the tunnel end point. Otherwise, the pre-PANA address will be released, and post-PANA address will be configured. So now, if case (1) is followed by getting a global IPv4 address via DHCP after PANA exchange, and IPsec is used, what should be used in the tunnel outer header? Unless we rebind the DI to the new IP address, the link-local address would be the answer. > >> On the other hand, if we use global IP address as the outer address, >> unauthenticated DHCP would be performed to obtain a pre-PANA address. >> In an environment where the post-PANA address (i.e, the global >> address) is assigned to authenticated clients only, the pre-PANA and >> post-PANA addresses will be different. This means that two stateful >> configuration protocol operations will be needed, one for pre-PANA >> address and the other for the post-PANA address. But this is much >> better than waiting for lengty DHCP timeout to configure an IPv4 >> link-local address. >> > I agree with this. 30 second delay might be too much. And this does not need > any change in the behavior of the existing clients. So, i assume that > the pre-pana address can be a RFC1918 private address. Yes, even if it is configured via DHCP, it can be a RFC1918 address. > What should > be the lease time for the pre-pana address i.e what should be recommended ? > If you want to tunnel all packets using the pre-pana address (for the outer), > then it makes sense to keep the lifetime of both the addresses same. > Addresses might time out independently but it should not cause any problems > i guess. If we recommend a very small lease time for the pre-pana address, > then we should use the post-pana address for both inner and outer address. I think using a short lease does not require that we use post-PANA address for both inner and outer headers. A longer lease can be granted when the current one expires. > I know of some implementations that has problem with this (tunnel module > drops the packets destined to the outer address itself as it thinks there is > a routing loop). But as we have only PANA protocol packets destined to > EP/PAA itself, we can setup a bypass rule for this in the SPD. Alper > > -mohan > >> Yoshihiro Ohba >> >> >> >>> >>> Alper >>> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 15:35:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09310 for ; Thu, 22 Jan 2004 15:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlXk-0007yp-KJ for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 15:35:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MKZCiN030669 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 15:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlXk-0007ya-Dr for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 15:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09253 for ; Thu, 22 Jan 2004 15:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlXj-0006nQ-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 15:35:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlWg-0006fD-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 15:34:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjlVg-0006UZ-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 15:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlVd-0007JO-Lm; Thu, 22 Jan 2004 15:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjlUi-00074d-W8 for pana@optimus.ietf.org; Thu, 22 Jan 2004 15:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08682 for ; Thu, 22 Jan 2004 15:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjlUh-0006Ip-00 for pana@ietf.org; Thu, 22 Jan 2004 15:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjlPU-0005tL-00 for pana@ietf.org; Thu, 22 Jan 2004 15:26:43 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjlIz-0005Pp-00 for pana@ietf.org; Thu, 22 Jan 2004 15:19:57 -0500 Date: Thu, 22 Jan 2004 12:19:29 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: Message-ID: In-Reply-To: <003101c3e10e$dd826d50$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>> Nevertheless, we can consider using the same global IP address as the tunnel >>> end point and as the inner IP address as soon as the PaC gets one. Any pros >>> and cons here? >> >> At least Windows 2000 and XP implementations, link-local address is >> available only after performing DHCP and the DHCP has been failed. It >> takes long time (about 30 seconds in my measurement) until DHCP fails, >> which is unacceptable. In the same implementations, if DHCP succeeds, >> link-local address is not available as Mohan mentioned. An advantage >> would be that only one stateful configuration protocol operation is >> needed for obtaining the inner addres. >> > One of the reasons we started using link-local address in PANA is to stay > compatible with what the majority of the clients do today as you described > above. There may be an advantage, but the deployment may not allow > it e.g. where address is assigned from your ISP only after authentication. As normal, the IPv4 host would attempt DHCP. If it fails, it will fall back to link-local addresses. So, before the PANA run, the host will have one of these: 1- a link-local IPv4 address (using zeroconf) 2- a DHCP address that it will also use for data communication later 3- a DHCP address that is only used during PANA 4- a DHCP address that is used during PANA, and also as the tunnel end point later After PANA, the client will attempt getting another IPv4 address depending on the information in the PANA bind message. Only case 2 above does not require another IP address acqusition. The same PANA bind message will also imply whether the current IP address should be unconfigured prior to configuring the new one. If IPsec tunneling is used, the pre-PANA address will be maintained as the tunnel end point. Otherwise, the pre-PANA address will be released, and post-PANA address will be configured. So now, if case (1) is followed by getting a global IPv4 address via DHCP after PANA exchange, and IPsec is used, what should be used in the tunnel outer header? Unless we rebind the DI to the new IP address, the link-local address would be the answer. > >> On the other hand, if we use global IP address as the outer address, >> unauthenticated DHCP would be performed to obtain a pre-PANA address. >> In an environment where the post-PANA address (i.e, the global >> address) is assigned to authenticated clients only, the pre-PANA and >> post-PANA addresses will be different. This means that two stateful >> configuration protocol operations will be needed, one for pre-PANA >> address and the other for the post-PANA address. But this is much >> better than waiting for lengty DHCP timeout to configure an IPv4 >> link-local address. >> > I agree with this. 30 second delay might be too much. And this does not need > any change in the behavior of the existing clients. So, i assume that > the pre-pana address can be a RFC1918 private address. Yes, even if it is configured via DHCP, it can be a RFC1918 address. > What should > be the lease time for the pre-pana address i.e what should be recommended ? > If you want to tunnel all packets using the pre-pana address (for the outer), > then it makes sense to keep the lifetime of both the addresses same. > Addresses might time out independently but it should not cause any problems > i guess. If we recommend a very small lease time for the pre-pana address, > then we should use the post-pana address for both inner and outer address. I think using a short lease does not require that we use post-PANA address for both inner and outer headers. A longer lease can be granted when the current one expires. > I know of some implementations that has problem with this (tunnel module > drops the packets destined to the outer address itself as it thinks there is > a routing loop). But as we have only PANA protocol packets destined to > EP/PAA itself, we can setup a bypass rule for this in the SPD. Alper > > -mohan > >> Yoshihiro Ohba >> >> >> >>> >>> Alper >>> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 17:41:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16466 for ; Thu, 22 Jan 2004 17:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnVV-0001Al-HI; Thu, 22 Jan 2004 17:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnUY-00013Y-7k for pana@optimus.ietf.org; Thu, 22 Jan 2004 17:40:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16253 for ; Thu, 22 Jan 2004 17:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnUV-0002T2-00 for pana@ietf.org; Thu, 22 Jan 2004 17:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnNR-0001UF-00 for pana@ietf.org; Thu, 22 Jan 2004 17:32:44 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjnEN-0000ga-00 for pana@ietf.org; Thu, 22 Jan 2004 17:23:19 -0500 Date: Thu, 22 Jan 2004 14:23:07 -0800 Subject: Re: [Pana] issue 38 From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040121174747.GU26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > http://www.danforsberg.info:8080/pana-issues/issue38 > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. > Instead, the PAA should specify which algorithm is used. As a result, > the PaC either accepts the specified algorithm or fails to complete > authentication successfully. Why do we have to deal with HMAC-MD5, can't we simply state that it is always HMAC-SHA1? Alper > > Here is suggested text: > > In section 4.1.6, change: > > "When a MAC AVP is included in a PANA message, the value field of the > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0." > > to: > > "When a MAC AVP is included in a PANA message, the value field of the > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > represents the pseudo random function corresponding to the MAC > algorithm specified in the MAC AVP. In this version of draft, > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > use the same algorithm to calculate a MAC AVP they originate and > receive. The algorithm is determined by the PAA when > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > support the MAC algorithm specified in the PANA-Bind-Request > message, it MUST silently discard the message. The PAA MUST NOT > change the MAC algorithm throughout the continuation of the PANA > session." > > > Regards, > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 17:43:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16644 for ; Thu, 22 Jan 2004 17:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnXS-0001Z6-6Y; Thu, 22 Jan 2004 17:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnX2-0001QW-5b for pana@optimus.ietf.org; Thu, 22 Jan 2004 17:42:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16555 for ; Thu, 22 Jan 2004 17:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnWz-00032g-00 for pana@ietf.org; Thu, 22 Jan 2004 17:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnT7-0002Ao-00 for pana@ietf.org; Thu, 22 Jan 2004 17:38:36 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjnJT-00014W-00 for pana@ietf.org; Thu, 22 Jan 2004 17:28:35 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MMS3N9005224; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MMS3pB021915; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA21914 ; Fri, 23 Jan 2004 07:28:03 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA05974; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA29317; Fri, 23 Jan 2004 07:28:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MMS10j026330; Fri, 23 Jan 2004 07:28:02 +0900 (JST) Received: from steelhead ([159.119.168.134]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW00FWRX2NQ6@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 07:28:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjnFV-0004Ua-00; Thu, 22 Jan 2004 14:24:29 -0800 Date: Thu, 22 Jan 2004 14:24:29 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040122222429.GA26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040121174747.GU26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 22, 2004 at 02:23:07PM -0800, Alper Yegin wrote: > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > > > It is true that in sectionm 9.4.1, multiple hash algorithms are > > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > > > There is also an issue of whether PANA should allow negotiation of MAC > > algorithm. I think PANA should not allow algorithm negotiation, since > > there is a possible downgrading attack if negotiation is allowed. > > Instead, the PAA should specify which algorithm is used. As a result, > > the PaC either accepts the specified algorithm or fails to complete > > authentication successfully. > > Why do we have to deal with HMAC-MD5, can't we simply state that it is > always HMAC-SHA1? Considering possible future evolution of cryptography, I think hard-coding algorithm type in the specification is not desirable. Yoshihiro Ohba > > Alper > > > > > > Here is suggested text: > > > > In section 4.1.6, change: > > > > "When a MAC AVP is included in a PANA message, the value field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0." > > > > to: > > > > "When a MAC AVP is included in a PANA message, the value field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > represents the pseudo random function corresponding to the MAC > > algorithm specified in the MAC AVP. In this version of draft, > > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > > use the same algorithm to calculate a MAC AVP they originate and > > receive. The algorithm is determined by the PAA when > > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > > support the MAC algorithm specified in the PANA-Bind-Request > > message, it MUST silently discard the message. The PAA MUST NOT > > change the MAC algorithm throughout the continuation of the PANA > > session." > > > > > > Regards, > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 17:49:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17554 for ; Thu, 22 Jan 2004 17:49:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajnct-0002Jz-Sa for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 17:48:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MMmdg1008919 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 17:48:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajnct-0002Jl-OH for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 17:48:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17384 for ; Thu, 22 Jan 2004 17:48:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajncq-0004O4-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnZN-0003aY-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjnVW-0002h6-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnVV-0001Al-HI; Thu, 22 Jan 2004 17:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnUY-00013Y-7k for pana@optimus.ietf.org; Thu, 22 Jan 2004 17:40:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16253 for ; Thu, 22 Jan 2004 17:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnUV-0002T2-00 for pana@ietf.org; Thu, 22 Jan 2004 17:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnNR-0001UF-00 for pana@ietf.org; Thu, 22 Jan 2004 17:32:44 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjnEN-0000ga-00 for pana@ietf.org; Thu, 22 Jan 2004 17:23:19 -0500 Date: Thu, 22 Jan 2004 14:23:07 -0800 Subject: Re: [Pana] issue 38 From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040121174747.GU26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > http://www.danforsberg.info:8080/pana-issues/issue38 > > It is true that in sectionm 9.4.1, multiple hash algorithms are > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > There is also an issue of whether PANA should allow negotiation of MAC > algorithm. I think PANA should not allow algorithm negotiation, since > there is a possible downgrading attack if negotiation is allowed. > Instead, the PAA should specify which algorithm is used. As a result, > the PaC either accepts the specified algorithm or fails to complete > authentication successfully. Why do we have to deal with HMAC-MD5, can't we simply state that it is always HMAC-SHA1? Alper > > Here is suggested text: > > In section 4.1.6, change: > > "When a MAC AVP is included in a PANA message, the value field of the > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0." > > to: > > "When a MAC AVP is included in a PANA message, the value field of the > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > where PANA_PDU is the PANA message including the PANA header, with > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > represents the pseudo random function corresponding to the MAC > algorithm specified in the MAC AVP. In this version of draft, > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > use the same algorithm to calculate a MAC AVP they originate and > receive. The algorithm is determined by the PAA when > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > support the MAC algorithm specified in the PANA-Bind-Request > message, it MUST silently discard the message. The PAA MUST NOT > change the MAC algorithm throughout the continuation of the PANA > session." > > > Regards, > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 17:50:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17821 for ; Thu, 22 Jan 2004 17:50:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajne1-0002Qe-7i for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 17:49:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MMnnWQ009330 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 17:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajne1-0002QN-3Q for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 17:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17693 for ; Thu, 22 Jan 2004 17:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajndx-0004eg-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnbO-00043X-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:47:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjnXd-00039g-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 17:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnXS-0001Z6-6Y; Thu, 22 Jan 2004 17:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnX2-0001QW-5b for pana@optimus.ietf.org; Thu, 22 Jan 2004 17:42:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16555 for ; Thu, 22 Jan 2004 17:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnWz-00032g-00 for pana@ietf.org; Thu, 22 Jan 2004 17:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnT7-0002Ao-00 for pana@ietf.org; Thu, 22 Jan 2004 17:38:36 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjnJT-00014W-00 for pana@ietf.org; Thu, 22 Jan 2004 17:28:35 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0MMS3N9005224; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0MMS3pB021915; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA21914 ; Fri, 23 Jan 2004 07:28:03 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA05974; Fri, 23 Jan 2004 07:28:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA29317; Fri, 23 Jan 2004 07:28:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0MMS10j026330; Fri, 23 Jan 2004 07:28:02 +0900 (JST) Received: from steelhead ([159.119.168.134]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRW00FWRX2NQ6@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 07:28:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjnFV-0004Ua-00; Thu, 22 Jan 2004 14:24:29 -0800 Date: Thu, 22 Jan 2004 14:24:29 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040122222429.GA26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040121174747.GU26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Jan 22, 2004 at 02:23:07PM -0800, Alper Yegin wrote: > > > http://www.danforsberg.info:8080/pana-issues/issue38 > > > > It is true that in sectionm 9.4.1, multiple hash algorithms are > > supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. > > > > There is also an issue of whether PANA should allow negotiation of MAC > > algorithm. I think PANA should not allow algorithm negotiation, since > > there is a possible downgrading attack if negotiation is allowed. > > Instead, the PAA should specify which algorithm is used. As a result, > > the PaC either accepts the specified algorithm or fails to complete > > authentication successfully. > > Why do we have to deal with HMAC-MD5, can't we simply state that it is > always HMAC-SHA1? Considering possible future evolution of cryptography, I think hard-coding algorithm type in the specification is not desirable. Yoshihiro Ohba > > Alper > > > > > > Here is suggested text: > > > > In section 4.1.6, change: > > > > "When a MAC AVP is included in a PANA message, the value field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > > > MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0." > > > > to: > > > > "When a MAC AVP is included in a PANA message, the value field of the > > MAC AVP is calculated by using the PANA_MAC_Key in the following way: > > > > MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > > > where PANA_PDU is the PANA message including the PANA header, with > > the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > represents the pseudo random function corresponding to the MAC > > algorithm specified in the MAC AVP. In this version of draft, > > PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > > use the same algorithm to calculate a MAC AVP they originate and > > receive. The algorithm is determined by the PAA when > > a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > > support the MAC algorithm specified in the PANA-Bind-Request > > message, it MUST silently discard the message. The PAA MUST NOT > > change the MAC algorithm throughout the continuation of the PANA > > session." > > > > > > Regards, > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 19:19:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21222 for ; Thu, 22 Jan 2004 19:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp2K-000635-Sc; Thu, 22 Jan 2004 19:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp1V-00062W-UY for pana@optimus.ietf.org; Thu, 22 Jan 2004 19:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21193 for ; Thu, 22 Jan 2004 19:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajp1P-000027-00 for pana@ietf.org; Thu, 22 Jan 2004 19:18:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajox3-0007kO-00 for pana@ietf.org; Thu, 22 Jan 2004 19:13:34 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjovC-0007dW-00 for pana@ietf.org; Thu, 22 Jan 2004 19:11:38 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 23 Jan 2004 00:09:57 -0000 Message-ID: <00e301c3e145$3c844400$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: References: Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Thu, 22 Jan 2004 16:09:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > >>> Nevertheless, we can consider using the same global IP address as the tunnel > >>> end point and as the inner IP address as soon as the PaC gets one. Any pros > >>> and cons here? > >> > >> At least Windows 2000 and XP implementations, link-local address is > >> available only after performing DHCP and the DHCP has been failed. It > >> takes long time (about 30 seconds in my measurement) until DHCP fails, > >> which is unacceptable. In the same implementations, if DHCP succeeds, > >> link-local address is not available as Mohan mentioned. An advantage > >> would be that only one stateful configuration protocol operation is > >> needed for obtaining the inner addres. > >> > > One of the reasons we started using link-local address in PANA is to stay > > compatible with what the majority of the clients do today as you described > > above. There may be an advantage, but the deployment may not allow > > it e.g. where address is assigned from your ISP only after authentication. > > As normal, the IPv4 host would attempt DHCP. If it fails, it will fall back > to link-local addresses. So, before the PANA run, the host will have one of > these: > 1- a link-local IPv4 address (using zeroconf) > 2- a DHCP address that it will also use for data communication later > 3- a DHCP address that is only used during PANA > 4- a DHCP address that is used during PANA, and also as the tunnel end point > later > > After PANA, the client will attempt getting another IPv4 address depending > on the information in the PANA bind message. Only case 2 above does not > require another IP address acqusition. > > The same PANA bind message will also imply whether the current IP address > should be unconfigured prior to configuring the new one. If IPsec tunneling > is used, the pre-PANA address will be maintained as the tunnel end point. > Otherwise, the pre-PANA address will be released, and post-PANA address will > be configured. > > So now, if case (1) is followed by getting a global IPv4 address via DHCP > after PANA exchange, and IPsec is used, what should be used in the tunnel > outer header? Unless we rebind the DI to the new IP address, the link-local > address would be the answer. > First, clarification regarding re-bind. When IPsec is used, the SA is bound to the post-pana address. Who is benefiting from rebinding the DI to the new IP address i.e why is it needed in the IPsec case ? Now, whether we want to use one address or two addresses on an interface ? We have to understand whether there are source address selection issues with any of the implementation or not. We have a default route to EP through an interface with 2 addresses on it. Both the address are /32. Normally the source address is picked from the outgoing interface if the application has not initialized it. If each of the address is configured as a separate logical interface, then it may not have problems. Otherwise, not sure what address will be picked for packets trying to reach off-link. You don't want the link-local address. > > > >> On the other hand, if we use global IP address as the outer address, > >> unauthenticated DHCP would be performed to obtain a pre-PANA address. > >> In an environment where the post-PANA address (i.e, the global > >> address) is assigned to authenticated clients only, the pre-PANA and > >> post-PANA addresses will be different. This means that two stateful > >> configuration protocol operations will be needed, one for pre-PANA > >> address and the other for the post-PANA address. But this is much > >> better than waiting for lengty DHCP timeout to configure an IPv4 > >> link-local address. > >> > > I agree with this. 30 second delay might be too much. And this does not need > > any change in the behavior of the existing clients. So, i assume that > > the pre-pana address can be a RFC1918 private address. > > Yes, even if it is configured via DHCP, it can be a RFC1918 address. > > > What should > > be the lease time for the pre-pana address i.e what should be recommended ? > > If you want to tunnel all packets using the pre-pana address (for the outer), > > then it makes sense to keep the lifetime of both the addresses same. > > Addresses might time out independently but it should not cause any problems > > i guess. If we recommend a very small lease time for the pre-pana address, > > then we should use the post-pana address for both inner and outer address. > > I think using a short lease does not require that we use post-PANA address > for both inner and outer headers. A longer lease can be granted when the > current one expires. Sure. Has anyone tried configuring e.g. linux, two addresses using DHCP on a interface ? I don't know how easy or cumbersome it is. -mohan > > > I know of some implementations that has problem with this (tunnel module > > drops the packets destined to the outer address itself as it thinks there is > > a routing loop). But as we have only PANA protocol packets destined to > > EP/PAA itself, we can setup a bypass rule for this in the SPD. > > Alper > > > > > > -mohan > > > >> Yoshihiro Ohba > >> > >> > >> > >>> > >>> Alper > >>> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 19:24:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21334 for ; Thu, 22 Jan 2004 19:24:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp79-0006Ix-O9 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 19:23:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N0NxBr024231 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 19:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp79-0006Ik-JU for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 19:23:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21331 for ; Thu, 22 Jan 2004 19:23:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajp72-0000EY-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 19:23:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajp5M-0000Af-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 19:22:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajp2b-000060-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 19:19:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp2K-000635-Sc; Thu, 22 Jan 2004 19:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajp1V-00062W-UY for pana@optimus.ietf.org; Thu, 22 Jan 2004 19:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21193 for ; Thu, 22 Jan 2004 19:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajp1P-000027-00 for pana@ietf.org; Thu, 22 Jan 2004 19:18:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajox3-0007kO-00 for pana@ietf.org; Thu, 22 Jan 2004 19:13:34 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AjovC-0007dW-00 for pana@ietf.org; Thu, 22 Jan 2004 19:11:38 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 23 Jan 2004 00:09:57 -0000 Message-ID: <00e301c3e145$3c844400$681067c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: References: Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 Date: Thu, 22 Jan 2004 16:09:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >>> Nevertheless, we can consider using the same global IP address as the tunnel > >>> end point and as the inner IP address as soon as the PaC gets one. Any pros > >>> and cons here? > >> > >> At least Windows 2000 and XP implementations, link-local address is > >> available only after performing DHCP and the DHCP has been failed. It > >> takes long time (about 30 seconds in my measurement) until DHCP fails, > >> which is unacceptable. In the same implementations, if DHCP succeeds, > >> link-local address is not available as Mohan mentioned. An advantage > >> would be that only one stateful configuration protocol operation is > >> needed for obtaining the inner addres. > >> > > One of the reasons we started using link-local address in PANA is to stay > > compatible with what the majority of the clients do today as you described > > above. There may be an advantage, but the deployment may not allow > > it e.g. where address is assigned from your ISP only after authentication. > > As normal, the IPv4 host would attempt DHCP. If it fails, it will fall back > to link-local addresses. So, before the PANA run, the host will have one of > these: > 1- a link-local IPv4 address (using zeroconf) > 2- a DHCP address that it will also use for data communication later > 3- a DHCP address that is only used during PANA > 4- a DHCP address that is used during PANA, and also as the tunnel end point > later > > After PANA, the client will attempt getting another IPv4 address depending > on the information in the PANA bind message. Only case 2 above does not > require another IP address acqusition. > > The same PANA bind message will also imply whether the current IP address > should be unconfigured prior to configuring the new one. If IPsec tunneling > is used, the pre-PANA address will be maintained as the tunnel end point. > Otherwise, the pre-PANA address will be released, and post-PANA address will > be configured. > > So now, if case (1) is followed by getting a global IPv4 address via DHCP > after PANA exchange, and IPsec is used, what should be used in the tunnel > outer header? Unless we rebind the DI to the new IP address, the link-local > address would be the answer. > First, clarification regarding re-bind. When IPsec is used, the SA is bound to the post-pana address. Who is benefiting from rebinding the DI to the new IP address i.e why is it needed in the IPsec case ? Now, whether we want to use one address or two addresses on an interface ? We have to understand whether there are source address selection issues with any of the implementation or not. We have a default route to EP through an interface with 2 addresses on it. Both the address are /32. Normally the source address is picked from the outgoing interface if the application has not initialized it. If each of the address is configured as a separate logical interface, then it may not have problems. Otherwise, not sure what address will be picked for packets trying to reach off-link. You don't want the link-local address. > > > >> On the other hand, if we use global IP address as the outer address, > >> unauthenticated DHCP would be performed to obtain a pre-PANA address. > >> In an environment where the post-PANA address (i.e, the global > >> address) is assigned to authenticated clients only, the pre-PANA and > >> post-PANA addresses will be different. This means that two stateful > >> configuration protocol operations will be needed, one for pre-PANA > >> address and the other for the post-PANA address. But this is much > >> better than waiting for lengty DHCP timeout to configure an IPv4 > >> link-local address. > >> > > I agree with this. 30 second delay might be too much. And this does not need > > any change in the behavior of the existing clients. So, i assume that > > the pre-pana address can be a RFC1918 private address. > > Yes, even if it is configured via DHCP, it can be a RFC1918 address. > > > What should > > be the lease time for the pre-pana address i.e what should be recommended ? > > If you want to tunnel all packets using the pre-pana address (for the outer), > > then it makes sense to keep the lifetime of both the addresses same. > > Addresses might time out independently but it should not cause any problems > > i guess. If we recommend a very small lease time for the pre-pana address, > > then we should use the post-pana address for both inner and outer address. > > I think using a short lease does not require that we use post-PANA address > for both inner and outer headers. A longer lease can be granted when the > current one expires. Sure. Has anyone tried configuring e.g. linux, two addresses using DHCP on a interface ? I don't know how easy or cumbersome it is. -mohan > > > I know of some implementations that has problem with this (tunnel module > > drops the packets destined to the outer address itself as it thinks there is > > a routing loop). But as we have only PANA protocol packets destined to > > EP/PAA itself, we can setup a bypass rule for this in the SPD. > > Alper > > > > > > -mohan > > > >> Yoshihiro Ohba > >> > >> > >> > >>> > >>> Alper > >>> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 21:12:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24746 for ; Thu, 22 Jan 2004 21:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqng-0005Xp-Hr; Thu, 22 Jan 2004 21:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqnL-0005Wu-CQ for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:11:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24729 for ; Thu, 22 Jan 2004 21:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqnD-0004k2-00 for pana@ietf.org; Thu, 22 Jan 2004 21:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajql1-0004h5-00 for pana@ietf.org; Thu, 22 Jan 2004 21:09:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjqjK-0004ek-00 for pana@ietf.org; Thu, 22 Jan 2004 21:07:31 -0500 Date: Thu, 22 Jan 2004 18:07:04 -0800 Subject: Re: [Pana] issue 38 From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040122222429.GA26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>> http://www.danforsberg.info:8080/pana-issues/issue38 >>> >>> It is true that in sectionm 9.4.1, multiple hash algorithms are >>> supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. >>> >>> There is also an issue of whether PANA should allow negotiation of MAC >>> algorithm. I think PANA should not allow algorithm negotiation, since >>> there is a possible downgrading attack if negotiation is allowed. >>> Instead, the PAA should specify which algorithm is used. As a result, >>> the PaC either accepts the specified algorithm or fails to complete >>> authentication successfully. >> >> Why do we have to deal with HMAC-MD5, can't we simply state that it is >> always HMAC-SHA1? > > Considering possible future evolution of cryptography, I think > hard-coding algorithm type in the specification is not desirable. OK, we can include an algorithm type, and allocate a number for HMAC-SHA1 today, with the provision that more can be added later. I think this can be the base line, without supporting HMAC-MD5. (we don't have to create an interop problem from day one by also supporting HMAC-MD5 which is not even recommended for use). Alper > > Yoshihiro Ohba > > >> >> Alper >> >> >>> >>> Here is suggested text: >>> >>> In section 4.1.6, change: >>> >>> "When a MAC AVP is included in a PANA message, the value field of the >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: >>> >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) >>> >>> where PANA_PDU is the PANA message including the PANA header, with >>> the MAC AVP value field first initialized to 0." >>> >>> to: >>> >>> "When a MAC AVP is included in a PANA message, the value field of the >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: >>> >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) >>> >>> where PANA_PDU is the PANA message including the PANA header, with >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF >>> represents the pseudo random function corresponding to the MAC >>> algorithm specified in the MAC AVP. In this version of draft, >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST >>> use the same algorithm to calculate a MAC AVP they originate and >>> receive. The algorithm is determined by the PAA when >>> a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not >>> support the MAC algorithm specified in the PANA-Bind-Request >>> message, it MUST silently discard the message. The PAA MUST NOT >>> change the MAC algorithm throughout the continuation of the PANA >>> session." >>> >>> >>> Regards, >>> >>> Yoshihiro Ohba >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 21:17:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24889 for ; Thu, 22 Jan 2004 21:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqsV-00064u-Oo for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:17:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2Gxfl023357 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqsV-00064e-Jj for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:16:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24859 for ; Thu, 22 Jan 2004 21:16:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqsO-0004sP-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:16:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajqp0-0004oY-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:13:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajqo1-0004kb-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:12:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajqng-0005Xp-Hr; Thu, 22 Jan 2004 21:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjqnL-0005Wu-CQ for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:11:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24729 for ; Thu, 22 Jan 2004 21:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqnD-0004k2-00 for pana@ietf.org; Thu, 22 Jan 2004 21:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajql1-0004h5-00 for pana@ietf.org; Thu, 22 Jan 2004 21:09:15 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AjqjK-0004ek-00 for pana@ietf.org; Thu, 22 Jan 2004 21:07:31 -0500 Date: Thu, 22 Jan 2004 18:07:04 -0800 Subject: Re: [Pana] issue 38 From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040122222429.GA26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>> http://www.danforsberg.info:8080/pana-issues/issue38 >>> >>> It is true that in sectionm 9.4.1, multiple hash algorithms are >>> supported for MAC AVP, while only HMAC-SHA1 is specified section 4.1.6. >>> >>> There is also an issue of whether PANA should allow negotiation of MAC >>> algorithm. I think PANA should not allow algorithm negotiation, since >>> there is a possible downgrading attack if negotiation is allowed. >>> Instead, the PAA should specify which algorithm is used. As a result, >>> the PaC either accepts the specified algorithm or fails to complete >>> authentication successfully. >> >> Why do we have to deal with HMAC-MD5, can't we simply state that it is >> always HMAC-SHA1? > > Considering possible future evolution of cryptography, I think > hard-coding algorithm type in the specification is not desirable. OK, we can include an algorithm type, and allocate a number for HMAC-SHA1 today, with the provision that more can be added later. I think this can be the base line, without supporting HMAC-MD5. (we don't have to create an interop problem from day one by also supporting HMAC-MD5 which is not even recommended for use). Alper > > Yoshihiro Ohba > > >> >> Alper >> >> >>> >>> Here is suggested text: >>> >>> In section 4.1.6, change: >>> >>> "When a MAC AVP is included in a PANA message, the value field of the >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: >>> >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) >>> >>> where PANA_PDU is the PANA message including the PANA header, with >>> the MAC AVP value field first initialized to 0." >>> >>> to: >>> >>> "When a MAC AVP is included in a PANA message, the value field of the >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: >>> >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) >>> >>> where PANA_PDU is the PANA message including the PANA header, with >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF >>> represents the pseudo random function corresponding to the MAC >>> algorithm specified in the MAC AVP. In this version of draft, >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST >>> use the same algorithm to calculate a MAC AVP they originate and >>> receive. The algorithm is determined by the PAA when >>> a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not >>> support the MAC algorithm specified in the PANA-Bind-Request >>> message, it MUST silently discard the message. The PAA MUST NOT >>> change the MAC algorithm throughout the continuation of the PANA >>> session." >>> >>> >>> Regards, >>> >>> Yoshihiro Ohba >>> >>> _______________________________________________ >>> Pana mailing list >>> Pana@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pana >>> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 21:34:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25370 for ; Thu, 22 Jan 2004 21:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajr8y-0006dz-Pg; Thu, 22 Jan 2004 21:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajr8T-0006dG-Lo for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:33:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25291 for ; Thu, 22 Jan 2004 21:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajr8Q-0005au-00 for pana@ietf.org; Thu, 22 Jan 2004 21:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajr4j-0005P3-00 for pana@ietf.org; Thu, 22 Jan 2004 21:29:38 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ajr0w-0005DS-00 for pana@ietf.org; Thu, 22 Jan 2004 21:25:42 -0500 Date: Thu, 22 Jan 2004 18:25:31 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: Message-ID: In-Reply-To: <00e301c3e145$3c844400$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> So now, if case (1) is followed by getting a global IPv4 address via DHCP >> after PANA exchange, and IPsec is used, what should be used in the tunnel >> outer header? Unless we rebind the DI to the new IP address, the link-local >> address would be the answer. >> > First, clarification regarding re-bind. When IPsec is used, the SA is bound to > the > post-pana address. Who is benefiting from rebinding the DI to the new IP > address i.e > why is it needed in the IPsec case ? At least for network management and accounting reasons, we sould make sure the PANA state and the data traffic in the network is consistent. I think this is achieved only when the PaC DI appears on the data packets (whether its an IP address or MAC address). So, I think, if we are going to use post-PANA address on the tunnel header we should register it as PaC DI. Otherwise, I guess you are suggesting a discrepancy between the DI sent from PAA to EP and the tunnel headers doesn't break IKE and IPsec processing. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 21:35:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25493 for ; Thu, 22 Jan 2004 21:35:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrAP-0006lL-Hq for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:35:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2ZTNo025989 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrAP-0006l6-CG for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:35:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25487 for ; Thu, 22 Jan 2004 21:35:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrAM-0005q9-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:35:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajr9p-0005mm-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:34:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajr8y-0005g7-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajr8y-0006dz-Pg; Thu, 22 Jan 2004 21:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajr8T-0006dG-Lo for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:33:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25291 for ; Thu, 22 Jan 2004 21:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajr8Q-0005au-00 for pana@ietf.org; Thu, 22 Jan 2004 21:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajr4j-0005P3-00 for pana@ietf.org; Thu, 22 Jan 2004 21:29:38 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ajr0w-0005DS-00 for pana@ietf.org; Thu, 22 Jan 2004 21:25:42 -0500 Date: Thu, 22 Jan 2004 18:25:31 -0800 Subject: Re: [Pana] [pana-ipsec] PAC-LINK-LOCAL in IPv4 From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: Message-ID: In-Reply-To: <00e301c3e145$3c844400$681067c0@adithya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> So now, if case (1) is followed by getting a global IPv4 address via DHCP >> after PANA exchange, and IPsec is used, what should be used in the tunnel >> outer header? Unless we rebind the DI to the new IP address, the link-local >> address would be the answer. >> > First, clarification regarding re-bind. When IPsec is used, the SA is bound to > the > post-pana address. Who is benefiting from rebinding the DI to the new IP > address i.e > why is it needed in the IPsec case ? At least for network management and accounting reasons, we sould make sure the PANA state and the data traffic in the network is consistent. I think this is achieved only when the PaC DI appears on the data packets (whether its an IP address or MAC address). So, I think, if we are going to use post-PANA address on the tunnel header we should register it as PaC DI. Otherwise, I guess you are suggesting a discrepancy between the DI sent from PAA to EP and the tunnel headers doesn't break IKE and IPsec processing. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 22 21:49:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25872 for ; Thu, 22 Jan 2004 21:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrNU-000819-TU; Thu, 22 Jan 2004 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrMo-00080O-FP for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:48:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25799 for ; Thu, 22 Jan 2004 21:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrMk-00069d-00 for pana@ietf.org; Thu, 22 Jan 2004 21:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrLx-00068L-00 for pana@ietf.org; Thu, 22 Jan 2004 21:47:25 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjrKq-00066y-00 for pana@ietf.org; Thu, 22 Jan 2004 21:46:16 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0N2kCN9005753; Fri, 23 Jan 2004 11:46:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0N2kCap008023; Fri, 23 Jan 2004 11:46:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA08021 ; Fri, 23 Jan 2004 11:46:12 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA29797; Fri, 23 Jan 2004 11:46:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA15561; Fri, 23 Jan 2004 11:46:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0N2k80j022722; Fri, 23 Jan 2004 11:46:08 +0900 (JST) Received: from steelhead ([159.119.168.134]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRX00N8990U2Y@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 11:46:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjrIy-000532-00; Thu, 22 Jan 2004 18:44:20 -0800 Date: Thu, 22 Jan 2004 18:44:19 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040123024419.GM26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040122222429.GA26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 22, 2004 at 06:07:04PM -0800, Alper Yegin wrote: > > > > Considering possible future evolution of cryptography, I think > > hard-coding algorithm type in the specification is not desirable. > > OK, we can include an algorithm type, and allocate a number for HMAC-SHA1 > today, with the provision that more can be added later. I think this can be > the base line, without supporting HMAC-MD5. (we don't have to create an > interop problem from day one by also supporting HMAC-MD5 which is not even > recommended for use). I agree. Yoshihiro Ohba > > Alper > > > > > > Yoshihiro Ohba > > > > > >> > >> Alper > >> > >> > >>> > >>> Here is suggested text: > >>> > >>> In section 4.1.6, change: > >>> > >>> "When a MAC AVP is included in a PANA message, the value field of the > >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: > >>> > >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > >>> > >>> where PANA_PDU is the PANA message including the PANA header, with > >>> the MAC AVP value field first initialized to 0." > >>> > >>> to: > >>> > >>> "When a MAC AVP is included in a PANA message, the value field of the > >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: > >>> > >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > >>> > >>> where PANA_PDU is the PANA message including the PANA header, with > >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF > >>> represents the pseudo random function corresponding to the MAC > >>> algorithm specified in the MAC AVP. In this version of draft, > >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > >>> use the same algorithm to calculate a MAC AVP they originate and > >>> receive. The algorithm is determined by the PAA when > >>> a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > >>> support the MAC algorithm specified in the PANA-Bind-Request > >>> message, it MUST silently discard the message. The PAA MUST NOT > >>> change the MAC algorithm throughout the continuation of the PANA > >>> session." > >>> > >>> > >>> Regards, > >>> > >>> Yoshihiro Ohba > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >> > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 22 21:50:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25899 for ; Thu, 22 Jan 2004 21:50:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrOl-00085a-3c for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:50:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N2oJhO031088 for pana-archive@odin.ietf.org; Thu, 22 Jan 2004 21:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrOk-00085L-Vr for pana-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 21:50:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25896 for ; Thu, 22 Jan 2004 21:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrOh-0006Cm-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrNm-0006Bg-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:49:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjrNU-0006Ao-00 for pana-web-archive@ietf.org; Thu, 22 Jan 2004 21:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrNU-000819-TU; Thu, 22 Jan 2004 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjrMo-00080O-FP for pana@optimus.ietf.org; Thu, 22 Jan 2004 21:48:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25799 for ; Thu, 22 Jan 2004 21:48:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjrMk-00069d-00 for pana@ietf.org; Thu, 22 Jan 2004 21:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjrLx-00068L-00 for pana@ietf.org; Thu, 22 Jan 2004 21:47:25 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AjrKq-00066y-00 for pana@ietf.org; Thu, 22 Jan 2004 21:46:16 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0N2kCN9005753; Fri, 23 Jan 2004 11:46:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0N2kCap008023; Fri, 23 Jan 2004 11:46:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA08021 ; Fri, 23 Jan 2004 11:46:12 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA29797; Fri, 23 Jan 2004 11:46:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA15561; Fri, 23 Jan 2004 11:46:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0N2k80j022722; Fri, 23 Jan 2004 11:46:08 +0900 (JST) Received: from steelhead ([159.119.168.134]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRX00N8990U2Y@tsbpo1.po.toshiba.co.jp>; Fri, 23 Jan 2004 11:46:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AjrIy-000532-00; Thu, 22 Jan 2004 18:44:20 -0800 Date: Thu, 22 Jan 2004 18:44:19 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 38 In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040123024419.GM26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040122222429.GA26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Jan 22, 2004 at 06:07:04PM -0800, Alper Yegin wrote: > > > > Considering possible future evolution of cryptography, I think > > hard-coding algorithm type in the specification is not desirable. > > OK, we can include an algorithm type, and allocate a number for HMAC-SHA1 > today, with the provision that more can be added later. I think this can be > the base line, without supporting HMAC-MD5. (we don't have to create an > interop problem from day one by also supporting HMAC-MD5 which is not even > recommended for use). I agree. Yoshihiro Ohba > > Alper > > > > > > Yoshihiro Ohba > > > > > >> > >> Alper > >> > >> > >>> > >>> Here is suggested text: > >>> > >>> In section 4.1.6, change: > >>> > >>> "When a MAC AVP is included in a PANA message, the value field of the > >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: > >>> > >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > >>> > >>> where PANA_PDU is the PANA message including the PANA header, with > >>> the MAC AVP value field first initialized to 0." > >>> > >>> to: > >>> > >>> "When a MAC AVP is included in a PANA message, the value field of the > >>> MAC AVP is calculated by using the PANA_MAC_Key in the following way: > >>> > >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > >>> > >>> where PANA_PDU is the PANA message including the PANA header, with > >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF > >>> represents the pseudo random function corresponding to the MAC > >>> algorithm specified in the MAC AVP. In this version of draft, > >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC and PAA MUST > >>> use the same algorithm to calculate a MAC AVP they originate and > >>> receive. The algorithm is determined by the PAA when > >>> a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not > >>> support the MAC algorithm specified in the PANA-Bind-Request > >>> message, it MUST silently discard the message. The PAA MUST NOT > >>> change the MAC algorithm throughout the continuation of the PANA > >>> session." > >>> > >>> > >>> Regards, > >>> > >>> Yoshihiro Ohba > >>> > >>> _______________________________________________ > >>> Pana mailing list > >>> Pana@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pana > >>> > >> > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 23 10:29:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05480 for ; Fri, 23 Jan 2004 10:29:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ez-0000OK-Dj; Fri, 23 Jan 2004 10:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ep-0000MD-6i for pana@optimus.ietf.org; Fri, 23 Jan 2004 10:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05448 for ; Fri, 23 Jan 2004 10:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Em-00030s-00 for pana@ietf.org; Fri, 23 Jan 2004 10:28:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Dt-0002zF-00 for pana@ietf.org; Fri, 23 Jan 2004 10:27:54 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3DN-0002u3-00 for pana@ietf.org; Fri, 23 Jan 2004 10:27:21 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id CB75335BAB for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id B6C7B3F423 for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012316194630950 for ; Fri, 23 Jan 2004 16:19:46 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 7DD9C3F423 for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Ak346-000D5J-Ae for ; Fri, 23 Jan 2004 16:17:46 +0100 Date: Fri, 23 Jan 2004 16:17:46 +0100 From: Julien Bournelle To: pana@ietf.org Message-ID: <20040123151746.GF49972@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Pana] comments on pana-03a Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi, I have a few questions/comments regarding the draft pana-03a: -1- The PAA set the S-flag if we want to do ISP and NAP authentication and the PaC set the S-flag if it is ok. But what do we do if pac does not set the S-FLag ? -2- In the outline, 4.2 is "Discovery and Initial handshake" 4.3 is "Authentication phase when PANA-PAA-Discover is sent by EP" 4.4 is "Re-authentication" so we may have the impression that the case where the PANA-PAA-Discover is sent by the pac is not considered. Maybe we could just rename 4.3 with "Authentication Phase". -3- Correct me if I'm wrong but I guess the draft CMS Application Diameter is no longer supported by AAA wg and draft-aboba-pppext-key-problem-07 is now draft-ietf-eap-keying-01.txt -4- The PAA can indicate that IPsec is supported by the Protection Capability AVP sent in the PANA-Bind-Request. As the pac can not indicate if it support it, the PAA is going to configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). As such, EP will set up its SPD and will accept only ipsec traffic. SO finally, when PAA sets the protection capability with IPsec protection it implicitely requires that pac MUST support IPsec to access network. I wonder if it is what we want. what do you think ? (Am I missing ?) -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 23 10:31:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05666 for ; Fri, 23 Jan 2004 10:31:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Gi-0000ja-6O for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 10:30:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NFUmoV002821 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 10:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Gi-0000jQ-2i for pana-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 10:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05628 for ; Fri, 23 Jan 2004 10:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Gf-00034z-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 10:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Fk-000339-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 10:29:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3F3-00031J-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 10:29:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ez-0000OK-Dj; Fri, 23 Jan 2004 10:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ep-0000MD-6i for pana@optimus.ietf.org; Fri, 23 Jan 2004 10:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05448 for ; Fri, 23 Jan 2004 10:28:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Em-00030s-00 for pana@ietf.org; Fri, 23 Jan 2004 10:28:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Dt-0002zF-00 for pana@ietf.org; Fri, 23 Jan 2004 10:27:54 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3DN-0002u3-00 for pana@ietf.org; Fri, 23 Jan 2004 10:27:21 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id CB75335BAB for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id B6C7B3F423 for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012316194630950 for ; Fri, 23 Jan 2004 16:19:46 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id 7DD9C3F423 for ; Fri, 23 Jan 2004 16:19:47 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Ak346-000D5J-Ae for ; Fri, 23 Jan 2004 16:17:46 +0100 Date: Fri, 23 Jan 2004 16:17:46 +0100 From: Julien Bournelle To: pana@ietf.org Message-ID: <20040123151746.GF49972@ipv6-5.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Pana] comments on pana-03a Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi, I have a few questions/comments regarding the draft pana-03a: -1- The PAA set the S-flag if we want to do ISP and NAP authentication and the PaC set the S-flag if it is ok. But what do we do if pac does not set the S-FLag ? -2- In the outline, 4.2 is "Discovery and Initial handshake" 4.3 is "Authentication phase when PANA-PAA-Discover is sent by EP" 4.4 is "Re-authentication" so we may have the impression that the case where the PANA-PAA-Discover is sent by the pac is not considered. Maybe we could just rename 4.3 with "Authentication Phase". -3- Correct me if I'm wrong but I guess the draft CMS Application Diameter is no longer supported by AAA wg and draft-aboba-pppext-key-problem-07 is now draft-ietf-eap-keying-01.txt -4- The PAA can indicate that IPsec is supported by the Protection Capability AVP sent in the PANA-Bind-Request. As the pac can not indicate if it support it, the PAA is going to configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). As such, EP will set up its SPD and will accept only ipsec traffic. SO finally, when PAA sets the protection capability with IPsec protection it implicitely requires that pac MUST support IPsec to access network. I wonder if it is what we want. what do you think ? (Am I missing ?) -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 23 11:39:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10670 for ; Fri, 23 Jan 2004 11:39:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4Kj-0008Go-RT; Fri, 23 Jan 2004 11:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4KX-0008G4-UF for pana@optimus.ietf.org; Fri, 23 Jan 2004 11:38:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10652 for ; Fri, 23 Jan 2004 11:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4KW-00018r-00 for pana@ietf.org; Fri, 23 Jan 2004 11:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4Jb-00016d-00 for pana@ietf.org; Fri, 23 Jan 2004 11:37:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4JF-00014o-00 for pana@ietf.org; Fri, 23 Jan 2004 11:37:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NGbQN9013972; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NGbQbj020264; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA20263 ; Sat, 24 Jan 2004 01:37:26 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04539; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA27595; Sat, 24 Jan 2004 01:37:25 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NGbO0j025803; Sat, 24 Jan 2004 01:37:25 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00BARBIALG@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 01:37:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak4J0-0005kD-00; Fri, 23 Jan 2004 08:37:14 -0800 Date: Fri, 23 Jan 2004 08:37:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040123151746.GF49972@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040123163713.GQ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Julien, On Fri, Jan 23, 2004 at 04:17:46PM +0100, Julien Bournelle wrote: > hi, > > I have a few questions/comments regarding the draft pana-03a: > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > and the PaC set the S-flag if it is ok. But what do we do if pac does > not set the S-FLag ? When PaC does not set the S-fLag, only one EAP authentication occurs. I will add this explicit text. > > -2- In the outline, 4.2 is "Discovery and Initial handshake" 4.3 is > "Authentication phase when PANA-PAA-Discover is sent by EP" 4.4 is > "Re-authentication" so we may have the impression that the case where > the PANA-PAA-Discover is sent by the pac is not considered. > > Maybe we could just rename 4.3 with "Authentication Phase". That is a typo. I'll rename it as you suggest. > > -3- Correct me if I'm wrong but I guess the draft CMS Application > Diameter is no longer supported by AAA wg > and > draft-aboba-pppext-key-problem-07 is now > draft-ietf-eap-keying-01.txt That is true. To deal with the CMS issue, how about removing the following sentence in item c) of Section 11? "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key is securely carried (i.e. CMS protected) between AAA servers. " I will also update the reference to the eap-keying draft. > > > -4- The PAA can indicate that IPsec is supported by the Protection > Capability AVP sent in the PANA-Bind-Request. > As the pac can not indicate if it support it, the PAA is going to > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > As such, EP will set up its SPD and will > accept only ipsec traffic. > > SO finally, when PAA sets the protection capability with IPsec protection > it implicitely requires that pac MUST support IPsec to access network. > > I wonder if it is what we want. That is what we want. Protection capability is non-negotiable. In addition, the PaC that is incapable of IPsec should not return the PANA-Bind-Answer in this case. Instead, it should return an unprotected PANA-Error message with an appropriate Result-Code, and the PAA should treat the Error as an informational message and should neither enable IPsec nor immediately delete the session for the PaC. Instead, the PAA should wait for the authentication to timeout or for the number of retransmission to reach the maximum value. I think we might need to define a new Result-Code to explicit support the above case, such as: " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 Error code from PaC to PAA. This error is returned when the PaC receives a PANA-Bind-Request is received with an Protection-Capability AVP and a valid MAC AVP but does not support the protection capability specified in the Protection-Capability AVP." What do you think? Thanks, Yoshihiro Ohba > > what do you think ? (Am I missing ?) > > > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 23 11:41:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10824 for ; Fri, 23 Jan 2004 11:41:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4MT-0008Of-9Y for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 11:40:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NGenhI032276 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 11:40:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4MT-0008OV-46 for pana-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 11:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10806 for ; Fri, 23 Jan 2004 11:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4MS-0001Fe-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:40:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4Lc-0001Db-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:39:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4Kn-0001Ah-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4Kj-0008Go-RT; Fri, 23 Jan 2004 11:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4KX-0008G4-UF for pana@optimus.ietf.org; Fri, 23 Jan 2004 11:38:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10652 for ; Fri, 23 Jan 2004 11:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4KW-00018r-00 for pana@ietf.org; Fri, 23 Jan 2004 11:38:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4Jb-00016d-00 for pana@ietf.org; Fri, 23 Jan 2004 11:37:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4JF-00014o-00 for pana@ietf.org; Fri, 23 Jan 2004 11:37:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NGbQN9013972; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NGbQbj020264; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA20263 ; Sat, 24 Jan 2004 01:37:26 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04539; Sat, 24 Jan 2004 01:37:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA27595; Sat, 24 Jan 2004 01:37:25 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NGbO0j025803; Sat, 24 Jan 2004 01:37:25 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00BARBIALG@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 01:37:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak4J0-0005kD-00; Fri, 23 Jan 2004 08:37:14 -0800 Date: Fri, 23 Jan 2004 08:37:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040123151746.GF49972@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040123163713.GQ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi Julien, On Fri, Jan 23, 2004 at 04:17:46PM +0100, Julien Bournelle wrote: > hi, > > I have a few questions/comments regarding the draft pana-03a: > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > and the PaC set the S-flag if it is ok. But what do we do if pac does > not set the S-FLag ? When PaC does not set the S-fLag, only one EAP authentication occurs. I will add this explicit text. > > -2- In the outline, 4.2 is "Discovery and Initial handshake" 4.3 is > "Authentication phase when PANA-PAA-Discover is sent by EP" 4.4 is > "Re-authentication" so we may have the impression that the case where > the PANA-PAA-Discover is sent by the pac is not considered. > > Maybe we could just rename 4.3 with "Authentication Phase". That is a typo. I'll rename it as you suggest. > > -3- Correct me if I'm wrong but I guess the draft CMS Application > Diameter is no longer supported by AAA wg > and > draft-aboba-pppext-key-problem-07 is now > draft-ietf-eap-keying-01.txt That is true. To deal with the CMS issue, how about removing the following sentence in item c) of Section 11? "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key is securely carried (i.e. CMS protected) between AAA servers. " I will also update the reference to the eap-keying draft. > > > -4- The PAA can indicate that IPsec is supported by the Protection > Capability AVP sent in the PANA-Bind-Request. > As the pac can not indicate if it support it, the PAA is going to > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > As such, EP will set up its SPD and will > accept only ipsec traffic. > > SO finally, when PAA sets the protection capability with IPsec protection > it implicitely requires that pac MUST support IPsec to access network. > > I wonder if it is what we want. That is what we want. Protection capability is non-negotiable. In addition, the PaC that is incapable of IPsec should not return the PANA-Bind-Answer in this case. Instead, it should return an unprotected PANA-Error message with an appropriate Result-Code, and the PAA should treat the Error as an informational message and should neither enable IPsec nor immediately delete the session for the PaC. Instead, the PAA should wait for the authentication to timeout or for the number of retransmission to reach the maximum value. I think we might need to define a new Result-Code to explicit support the above case, such as: " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 Error code from PaC to PAA. This error is returned when the PaC receives a PANA-Bind-Request is received with an Protection-Capability AVP and a valid MAC AVP but does not support the protection capability specified in the Protection-Capability AVP." What do you think? Thanks, Yoshihiro Ohba > > what do you think ? (Am I missing ?) > > > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 23 11:51:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11069 for ; Fri, 23 Jan 2004 11:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4WL-0000iZ-LU; Fri, 23 Jan 2004 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4W3-0000iC-MM for pana@optimus.ietf.org; Fri, 23 Jan 2004 11:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11064 for ; Fri, 23 Jan 2004 11:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4W2-0001YQ-00 for pana@ietf.org; Fri, 23 Jan 2004 11:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4V7-0001Xk-00 for pana@ietf.org; Fri, 23 Jan 2004 11:49:45 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4Ul-0001Wx-00 for pana@ietf.org; Fri, 23 Jan 2004 11:49:24 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NGnMN9016167 for ; Sat, 24 Jan 2004 01:49:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NGnMZs023334 for ; Sat, 24 Jan 2004 01:49:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA23333 ; Sat, 24 Jan 2004 01:49:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA06673; Sat, 24 Jan 2004 01:49:21 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA03479; Sat, 24 Jan 2004 01:49:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NGnK0j027586 for ; Sat, 24 Jan 2004 01:49:20 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00BF3C26LG@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Sat, 24 Jan 2004 01:49:19 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak4Tk-0005lv-00 for ; Fri, 23 Jan 2004 08:48:20 -0800 Date: Fri, 23 Jan 2004 08:48:20 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040123164820.GR26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] SESS_RESUM in state machine Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , In the PAA state machine, there is a variable SESS_RESUM and there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action "Tx: PANA-Reauth-Request". However, I was not able to found the text in the base specification to allow this transition. When the PAA is in OFFLINE state, it means the session is deleted and there is no PANA SA. So it is not possible for the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. I think this transition should be removed and thus SESS_RESUM is not necessary. The same thing applies to the PaC state machine. There is a transition from WAIT_PAA to OPEN with an action "Tx: PANA-Reauth-Answer". I think this should not be allowed for the same reason. To summarize: PANA-Reauth-Request/Answer exchange should occur only in OPEN state for both PaC and PAA. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 23 11:53:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11125 for ; Fri, 23 Jan 2004 11:53:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4Y0-0000sN-Tr for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 11:52:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NGqiWf003361 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 11:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4Y0-0000s8-Ne for pana-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 11:52:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11119 for ; Fri, 23 Jan 2004 11:52:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4Xz-0001b0-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:52:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4X2-0001Zt-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:51:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak4WO-0001Yz-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 11:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4WL-0000iZ-LU; Fri, 23 Jan 2004 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak4W3-0000iC-MM for pana@optimus.ietf.org; Fri, 23 Jan 2004 11:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11064 for ; Fri, 23 Jan 2004 11:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4W2-0001YQ-00 for pana@ietf.org; Fri, 23 Jan 2004 11:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak4V7-0001Xk-00 for pana@ietf.org; Fri, 23 Jan 2004 11:49:45 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak4Ul-0001Wx-00 for pana@ietf.org; Fri, 23 Jan 2004 11:49:24 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NGnMN9016167 for ; Sat, 24 Jan 2004 01:49:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NGnMZs023334 for ; Sat, 24 Jan 2004 01:49:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA23333 ; Sat, 24 Jan 2004 01:49:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA06673; Sat, 24 Jan 2004 01:49:21 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA03479; Sat, 24 Jan 2004 01:49:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NGnK0j027586 for ; Sat, 24 Jan 2004 01:49:20 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00BF3C26LG@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Sat, 24 Jan 2004 01:49:19 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak4Tk-0005lv-00 for ; Fri, 23 Jan 2004 08:48:20 -0800 Date: Fri, 23 Jan 2004 08:48:20 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040123164820.GR26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] SESS_RESUM in state machine Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In the PAA state machine, there is a variable SESS_RESUM and there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action "Tx: PANA-Reauth-Request". However, I was not able to found the text in the base specification to allow this transition. When the PAA is in OFFLINE state, it means the session is deleted and there is no PANA SA. So it is not possible for the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. I think this transition should be removed and thus SESS_RESUM is not necessary. The same thing applies to the PaC state machine. There is a transition from WAIT_PAA to OPEN with an action "Tx: PANA-Reauth-Answer". I think this should not be allowed for the same reason. To summarize: PANA-Reauth-Request/Answer exchange should occur only in OPEN state for both PaC and PAA. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 23 14:21:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17298 for ; Fri, 23 Jan 2004 14:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6rX-0004QZ-Rs; Fri, 23 Jan 2004 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6qk-0004Js-92 for pana@optimus.ietf.org; Fri, 23 Jan 2004 14:20:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17156 for ; Fri, 23 Jan 2004 14:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6qh-0007kk-00 for pana@ietf.org; Fri, 23 Jan 2004 14:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6po-0007cp-00 for pana@ietf.org; Fri, 23 Jan 2004 14:19:16 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6ob-0007Y3-00 for pana@ietf.org; Fri, 23 Jan 2004 14:18:01 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NJHxN9016384; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NJHx7E028657; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA28656 ; Sat, 24 Jan 2004 04:17:59 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA26240; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA17730; Sat, 24 Jan 2004 04:17:58 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NJHv0j003813; Sat, 24 Jan 2004 04:17:58 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00DSSIXV8G@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 04:17:56 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak6oK-00064z-00; Fri, 23 Jan 2004 11:17:44 -0800 Date: Fri, 23 Jan 2004 11:17:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] SESS_RESUM in state machine In-reply-to: <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> To: Victor Fajardo Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040123191744.GW26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Victor Fajardo , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123164820.GR26285@steelhead> <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Jan 23, 2004 at 01:38:24PM -0500, Victor Fajardo wrote: > In addition, it seems SESS_RESUM is used to flag the inclusion/exclusion of > the session-id AVP in the start answer message of the Pac state machine. > But at this point, the PAA is offline (stateless with regards to keeping > knowledge about the Pac) and hence will not have established a session id. While PAA is offline with stateless, if it receives PANA-Start-Answer with Session-Id, it is still valid. Because the PAA can trigger context transfer to pull the PANA session context from other PAA and send ... PANA-Reauth-Request.... Ah, now I see why the PAA state machine has the transition from OFFLINE to WAIT_REAUTH_ANS. I found the corresponding description in section 4.9 and it should work. Please ignore my previous comment. Sorry for my confusion. Yoshihiro Ohba > > -- victor > > > In the PAA state machine, there is a variable SESS_RESUM and > > there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action > > "Tx: PANA-Reauth-Request". > > > > However, I was not able to found the text in the base specification to > > allow this transition. When the PAA is in OFFLINE state, it means the > > session is deleted and there is no PANA SA. So it is not possible for > > the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. > > > > I think this transition should be removed and thus SESS_RESUM is not > > necessary. > > > > The same thing applies to the PaC state machine. There is a > > transition from WAIT_PAA to OPEN with an action "Tx: > > PANA-Reauth-Answer". I think this should not be allowed for the same > > reason. > > > > To summarize: PANA-Reauth-Request/Answer exchange should occur only in > > OPEN state for both PaC and PAA. > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 23 14:40:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18134 for ; Fri, 23 Jan 2004 14:40:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7A0-0005kJ-Fc for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 14:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0NJe8or022068 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 14:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak79y-0005jh-BN for pana-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 14:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18072 for ; Fri, 23 Jan 2004 14:40:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak79v-0000sV-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 14:40:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak796-0000li-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 14:39:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak77F-0000cj-01 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 14:37:17 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak6rb-0003cK-Vj for pana-web-archive@ietf.org; Fri, 23 Jan 2004 14:21:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6rX-0004QZ-Rs; Fri, 23 Jan 2004 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6qk-0004Js-92 for pana@optimus.ietf.org; Fri, 23 Jan 2004 14:20:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17156 for ; Fri, 23 Jan 2004 14:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6qh-0007kk-00 for pana@ietf.org; Fri, 23 Jan 2004 14:20:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6po-0007cp-00 for pana@ietf.org; Fri, 23 Jan 2004 14:19:16 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6ob-0007Y3-00 for pana@ietf.org; Fri, 23 Jan 2004 14:18:01 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0NJHxN9016384; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0NJHx7E028657; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA28656 ; Sat, 24 Jan 2004 04:17:59 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA26240; Sat, 24 Jan 2004 04:17:59 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA17730; Sat, 24 Jan 2004 04:17:58 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0NJHv0j003813; Sat, 24 Jan 2004 04:17:58 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRY00DSSIXV8G@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 04:17:56 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ak6oK-00064z-00; Fri, 23 Jan 2004 11:17:44 -0800 Date: Fri, 23 Jan 2004 11:17:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] SESS_RESUM in state machine In-reply-to: <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> To: Victor Fajardo Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040123191744.GW26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Victor Fajardo , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123164820.GR26285@steelhead> <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Jan 23, 2004 at 01:38:24PM -0500, Victor Fajardo wrote: > In addition, it seems SESS_RESUM is used to flag the inclusion/exclusion of > the session-id AVP in the start answer message of the Pac state machine. > But at this point, the PAA is offline (stateless with regards to keeping > knowledge about the Pac) and hence will not have established a session id. While PAA is offline with stateless, if it receives PANA-Start-Answer with Session-Id, it is still valid. Because the PAA can trigger context transfer to pull the PANA session context from other PAA and send ... PANA-Reauth-Request.... Ah, now I see why the PAA state machine has the transition from OFFLINE to WAIT_REAUTH_ANS. I found the corresponding description in section 4.9 and it should work. Please ignore my previous comment. Sorry for my confusion. Yoshihiro Ohba > > -- victor > > > In the PAA state machine, there is a variable SESS_RESUM and > > there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action > > "Tx: PANA-Reauth-Request". > > > > However, I was not able to found the text in the base specification to > > allow this transition. When the PAA is in OFFLINE state, it means the > > session is deleted and there is no PANA SA. So it is not possible for > > the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. > > > > I think this transition should be removed and thus SESS_RESUM is not > > necessary. > > > > The same thing applies to the PaC state machine. There is a > > transition from WAIT_PAA to OPEN with an action "Tx: > > PANA-Reauth-Answer". I think this should not be allowed for the same > > reason. > > > > To summarize: PANA-Reauth-Request/Answer exchange should occur only in > > OPEN state for both PaC and PAA. > > > > Regards, > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Jan 23 22:47:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09851 for ; Fri, 23 Jan 2004 22:47:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkElB-0002j0-2Y; Fri, 23 Jan 2004 22:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkEkI-0002iP-IL for pana@optimus.ietf.org; Fri, 23 Jan 2004 22:46:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09819 for ; Fri, 23 Jan 2004 22:46:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkEkF-0006Bl-00 for pana@ietf.org; Fri, 23 Jan 2004 22:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkEjN-0006AY-00 for pana@ietf.org; Fri, 23 Jan 2004 22:45:10 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AkEiV-00067Z-00 for pana@ietf.org; Fri, 23 Jan 2004 22:44:16 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0O3i4N9015657; Sat, 24 Jan 2004 12:44:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0O3i4Vv001002; Sat, 24 Jan 2004 12:44:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA01001 ; Sat, 24 Jan 2004 12:44:03 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA18940; Sat, 24 Jan 2004 12:44:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA23231; Sat, 24 Jan 2004 12:44:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0O3i20j009054; Sat, 24 Jan 2004 12:44:02 +0900 (JST) Received: from steelhead ([159.119.168.80]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRZ001V46DC23@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 12:44:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AkEhS-00076W-00; Fri, 23 Jan 2004 19:43:10 -0800 Date: Fri, 23 Jan 2004 19:43:10 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040124034310.GZ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 40 (proposed text) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Here is a proposed text for issue 40. (Sorry if I had already sent this.) - Add the following item in section 4.1.1: "o Key-Id AVP: contains an MSK identifier." - In section 4.1.5, Change: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a Master Session Key (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA authentication fails or no MSK is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two MSKs are derived. If this happens, the PANA SA MUST be bound to the MSK derived from the first EAP authentication. When a new MSK is derived as a result of EAP-based re-authentication, any key derived from the old MSK MUST be updated to a new one that is derived from the new MSK." to: A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a Master Session Key (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA authentication fails or no MSK is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two MSKs are derived. If this happens, the PANA SA MUST be bound to the MSK derived from the first EAP authentication. When a new MSK is derived as a result of EAP-based re-authentication, any key derived from the old MSK MUST be updated to a new one that is derived from the new MSK. In order to distinguish the new MSK from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the MSK within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new MSK." - In section 4.1.5, change: " * PANA SA attributes: + MSK + PANA_MAC_Key" to: " * PANA SA attributes: + MSK + MSK identifier + PANA_MAC_Key" - Add the following section: "9.4.16 Key-Id AVP The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an MSK identifier. The MSK identifier is assigned by PAA and MUST be unique within the PANA session." - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to contain optional Key-Id AVP. Comments? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Jan 23 22:49:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09937 for ; Fri, 23 Jan 2004 22:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkEnB-0002oA-22 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 22:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0O3n5p0010788 for pana-archive@odin.ietf.org; Fri, 23 Jan 2004 22:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkEnA-0002nv-UY for pana-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 22:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09899 for ; Fri, 23 Jan 2004 22:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkEn7-0006JY-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 22:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkEm9-0006GV-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 22:48:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkElC-0006Dz-00 for pana-web-archive@ietf.org; Fri, 23 Jan 2004 22:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkElB-0002j0-2Y; Fri, 23 Jan 2004 22:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkEkI-0002iP-IL for pana@optimus.ietf.org; Fri, 23 Jan 2004 22:46:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09819 for ; Fri, 23 Jan 2004 22:46:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkEkF-0006Bl-00 for pana@ietf.org; Fri, 23 Jan 2004 22:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkEjN-0006AY-00 for pana@ietf.org; Fri, 23 Jan 2004 22:45:10 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AkEiV-00067Z-00 for pana@ietf.org; Fri, 23 Jan 2004 22:44:16 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0O3i4N9015657; Sat, 24 Jan 2004 12:44:04 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0O3i4Vv001002; Sat, 24 Jan 2004 12:44:04 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA01001 ; Sat, 24 Jan 2004 12:44:03 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA18940; Sat, 24 Jan 2004 12:44:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA23231; Sat, 24 Jan 2004 12:44:03 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0O3i20j009054; Sat, 24 Jan 2004 12:44:02 +0900 (JST) Received: from steelhead ([159.119.168.80]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HRZ001V46DC23@tsbpo1.po.toshiba.co.jp>; Sat, 24 Jan 2004 12:44:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AkEhS-00076W-00; Fri, 23 Jan 2004 19:43:10 -0800 Date: Fri, 23 Jan 2004 19:43:10 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040124034310.GZ26285@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 40 (proposed text) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Here is a proposed text for issue 40. (Sorry if I had already sent this.) - Add the following item in section 4.1.1: "o Key-Id AVP: contains an MSK identifier." - In section 4.1.5, Change: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a Master Session Key (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA authentication fails or no MSK is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two MSKs are derived. If this happens, the PANA SA MUST be bound to the MSK derived from the first EAP authentication. When a new MSK is derived as a result of EAP-based re-authentication, any key derived from the old MSK MUST be updated to a new one that is derived from the new MSK." to: A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a Master Session Key (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA authentication fails or no MSK is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two MSKs are derived. If this happens, the PANA SA MUST be bound to the MSK derived from the first EAP authentication. When a new MSK is derived as a result of EAP-based re-authentication, any key derived from the old MSK MUST be updated to a new one that is derived from the new MSK. In order to distinguish the new MSK from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the MSK within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new MSK." - In section 4.1.5, change: " * PANA SA attributes: + MSK + PANA_MAC_Key" to: " * PANA SA attributes: + MSK + MSK identifier + PANA_MAC_Key" - Add the following section: "9.4.16 Key-Id AVP The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an MSK identifier. The MSK identifier is assigned by PAA and MUST be unique within the PANA session." - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to contain optional Key-Id AVP. Comments? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sat Jan 24 11:23:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13258 for ; Sat, 24 Jan 2004 11:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQYn-0006Dj-3O; Sat, 24 Jan 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQYS-0006DA-VB for pana@optimus.ietf.org; Sat, 24 Jan 2004 11:22:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13221 for ; Sat, 24 Jan 2004 11:22:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkQYS-0004sx-00 for pana@ietf.org; Sat, 24 Jan 2004 11:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkQXQ-0004qi-00 for pana@ietf.org; Sat, 24 Jan 2004 11:21:39 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AkQWY-0004oO-00 for pana@ietf.org; Sat, 24 Jan 2004 11:20:42 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i0OGKe000721; Sat, 24 Jan 2004 17:20:41 +0100 (MET) Received: from verena (rel036131xrelesn1.esn.sbs.de [149.246.36.131]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i0OGKcl14773; Sat, 24 Jan 2004 17:20:38 +0100 (MET) From: "Hannes Tschofenig" To: "'Alper Yegin'" Cc: Subject: RE: [Pana] EAP keying issues and PANA Date: Sat, 24 Jan 2004 17:20:29 +0100 Message-ID: <007801c3e295$fc5306d0$0105a8c0@verena> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable hi alper,=20 sorry for the delay. please see my comments inline: > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com]=20 > Sent: Dienstag, 13. J=E4nner 2004 00:28 > To: Tschofenig Hannes > Cc: pana@ietf.org > Subject: Re: [Pana] EAP keying issues and PANA >=20 >=20 > Hello Hannes, >=20 > Thank you for this analysis! This is a very useful material=20 > for having this discussion... >=20 > Please see my inlined comments below. >=20 >=20 > > hi all, > >=20 > > an interesting issue with a relationship to the EAP keying work was > raised. > > i have tried (in this first shot) to write a short text on the EAP > keying > > issues as they appear in PANA. > >=20 > > this text also includes some discussion parts where further=20 > input is=20 > > required (denoted as FOR DISCUSSION). > >=20 > > ciao > > hannes > >=20 > > ------------- > >=20 > > Protocol Communication Overview > > ------------------------------------------- > >=20 > > This section discusses EAP keying issues and is therefore strongly > aligned > > with Section 1.3 of [EAP-Keying]. There the entire EAP communication > is > > separated into three steps. Note that the first step is actually not > part of > > EAP itself. > >=20 > > - Discovery phase (phase 0) > > - EAP authentication, key derivation and transport (phase 1) > > - Unicast security association establishment (phase 2) > >=20 > > The discovery phase in PANA has the goal to find the PAA in the > visited > > network. This step is very hard to secure in a roaming=20 > environment. In > many > > cases an additional security protection at this step would=20 > add denial > of > > service vulnerabilities. However, to prevent very basic denial of > service > > attacks, whereby an adversary floods the PAA with bogus requests, a > cookie > > exchange is used. In PANA no capability discovery takes=20 > place at phase > 0. > >=20 > > Phase 1 is subdivided into two phases: Phase 1a and phase=20 > 1b. In phase > 1a > > the PAA starts sending the initial EAP packet and thereby initiates > the > > authentication procedure. The PAA might implement some EAP=20 > methods or > in > > many cases not even a single one - it acts as a passthrough device > which > > interacts with a backend authentication server. > >=20 > > EAP methods might provide key derivation and mutual authentication. > PANA > > leaves the choice to network architects which EAP methods=20 > to mandate. > This > > is necessary to fullfil the requirements of the larger number of > deployment > > scenarios. In case of wireless networks without physical or=20 > link layer=20 > > security the suggestions of [EAP-KEYING] with regard to EAP methods > should > > be followed. Methods which provide session key establishment and > mutual > > authentication are mandated. > >=20 > > Since the key derivation takes place between the EAP peer=20 > and the EAP > server > > it is (in many cases) necessary to transport the keying=20 > material from > the > > EAP server to the Authenticator (which corresponds to the PAA in > PANA). This > > step is referred as phase 1b. If the EAP server and the=20 > Authenticator > are > > co-located then this step is replaced by an API call. > >=20 > > Since PANA signaling messages need protection a PANA SA needs to be=20 > > established between the PaC and the PAA >=20 > The PANA SA is needed to provide the keys for the so-called=20 > phase 2. While we have this SA, we thought we can also use it=20 > for securing the subsequent PANA exchanges. Though, it is not=20 > a requirement that PANA, as a EAP lower layer, needs this=20 > kind of protection. that is true. for some scenarios this pana sa is not needed while for = others it is.=20 pana can operate in many different environments.=20 >=20 > > whereby new keying material needs to > > be derived from the key provided by the EAP method. This step is a > slight > > deviation from IEEE 802.1X since PANA does not automatically create > security > > associations for data traffic protection. >=20 > 802.1X does not either. It's the 4-way handshake of 802.11i=20 > that creates this SA. true. the ieee folks have separated these issues into two documents. = they, however, belong together.=20 >=20 > > With the help of EAP session keys are in place and PANA needs to > create, > > delete and update the parameters of the PANA SA. > >=20 > > PANA makes a more fine-grain separation in phase 2. Parts=20 > of phase 2a > are > > accomplished within PANA and some parts are delegated towards IKE if > IPsec > > SA establishment is desired (see [PANA-IPsec]). Phase 2b does not > exist in > > PANA. We will address the differences in more details in=20 > this section. > >=20 > > Figure 1 shows the communication overview. The figure is taken from=20 > > [EAP-Keying] and modified accordingly. The "Unicast Secure=20 > association=20 > > (phase 2a)" is replaced by the abstract term PANA Phase 2=20 > to avoid a=20 > > terminology confusion. > >=20 > >=20 > > EAP peer/PaC Authenticator/PAA Auth. Server > > ------------ ----------------- ------------ > > |<----------------------------->| =20 > | > > | Discovery (phase 0) | =20 > | > > =20 > |<----------------------------->|<----------------------------->| > > | EAP auth (phase 1a) | AAA pass-through=20 > (optional) | > > | | =20 > | > > | =20 > |<----------------------------->| > > | | AAA-Key=20 > transport | > > | | (optional; phase=20 > 1b) | > > |<----------------------------->| =20 > | > > | PANA Phase 2 | =20 > | > > | | =20 > | > > |<----------------------------->| =20 > | > > | IKE/IPsec SA establishment | =20 > | > > | (optional) | =20 > | > > | | =20 > | >=20 > I didn't understand why we have "PANA phase 2". Normally PANA=20 > should not "leak into" phase 2. Phase 2 is for IKE (or, in=20 > the case of 802.1X-based systems, 4-way handshake) well, the usage of the EAP derived keys for the pana sa provides key confirmation once you use the keys for protection of the signaling = messages. hence it is better to use the pana derived keys for the ipsec sa = compared to the pure eap method derived key.=20 >=20 > >=20 > > Figure 1: Communication Overview > >=20 > > Figure 1 ignores the fact that the Authenticator/PAA can=20 > physically be=20 > > separated from the Enforcement Point (EP). In this case IKE=20 > would not > run > > between the PaC and the PAA. > >=20 > > Phase 2 is executed after a successful EAP exchange in phase 1 > (including > > the transport of keying material to the Authenticator). > >=20 > > This phase accomplishes the following tasks (compared with the list=20 > > described in Section 1.3 of [EAP-KEYING]): > >=20 > > - Since PANA does not negotiate parameters during the=20 > discovery phase > it is > > not possible to confirm them. No cipher suite negotiation=20 > takes place > in > > PANA. > >=20 > > - PANA securely provides an exchange of parameters and=20 > usage modes as > part > > of the PANA-Bind-Request message (such as Device-Id, Lifetime,=20 > > Protection-Cap AVPs). > >=20 > > - PANA does not derive further session keys for protection of data > traffic. > > If an IPsec has to be established then IKE or IKEv2 is used. > >=20 > > - Mutual key confirmation (PAA to PaC with the help of the > PANA-Bind-Request > > and PaC to PAA with the help of the PANA-Bind-Answer message) is > provided. > > This ensure that both, the PaC and the PAA, successfully=20 > executed EAP > and, > > in the case of the PAA, were able to create the necessary keys and > parameter > > for the PANA SA. > >=20 > > - The PANA SA is active immediately after the PANA SA is established > (i.e., > > after the EAP method was successfully executed and session keys are=20 > > available). > >=20 > > - PANA also offers a mechanism for terminating access and to delete > the > > established state with the help of the PANA-Termination-Request and=20 > > PANA-Termination-Answer message. Without sending such a message the > PAA and > > the PaC delete their established state after lifetime expiration. > >=20 > > Security Associations > > -------------------------- > >=20 > > Several different security associations are created as part of the > PANA > > exchange. We will describe of them in some level of detail whereby > some PANA > > specific aspects might lead to discussions. > >=20 > > - EAP SA > >=20 > > First, there is the EAP SA which is described in Section 3.1 of=20 > > [EAP-KEYING]. Due to the nature of EAP there are some=20 > restrictions on > the > > EAP SA such as the missing lifetime negotiation, no SA delete > operation etc. > > Some EAP methods provide enhanced functionality by establishing > additional > > state which is subject to special optimizations such as=20 > "fast resume". > A > > detailed discussion of these issues is beyond the scope of PANA. > >=20 > > - AAA-Key SA / PANA SA > >=20 > > The AAA-Key SA described in Section 3.2 of [EAP-KEYING] seems to be > the > > counterpart of the PANA SA. This security association exists between > the PaC > > and the PAA. The following parameters constitute this AAA-Key SA: > >=20 > > - the EAP peer name > > - the NAS/authenticator name > > - the AAA-Key > > - the AAA-Key maximum lifetime (if known) > > - the AAA attributes sent in the Access-Accept > >=20 > > The subsequent paragraph is an attempt to map the text in=20 > [EAP-KEYING] > to > > PANA. > >=20 > > For the PANA-SA at the PAA would have the following parameters: > > - AAA attributes (obtained via the Access-Accept) > > - Lifetime (optional?) > > - Key of the PANA SA (derived from the AAA-Key) > > - Socket-Pair information (Src/Dst IP address, Src/Port, UDP > protocol) >=20 > We don't really deal with "sockets" context in the PANA=20 > design. Instead, I think we can refer to the "device IDs" in here. >=20 the term device id is an abstract term. you certainly have to consider a source and a destination "device id" (ip address, mac address) > > - Session ID > > The PANA-SA at the PaC contains similar attributes except=20 > for the AAA=20 > > attributes since they are invisible to the PaC. > >=20 > > The lifetime of the PANA SA is determined by a number of parameters. > The > > Lifetime AVP transmitted to the PaC is an indication for=20 > the PaC about > the > > time duration granted for network access (and therefore=20 > also for the=20 > > lifetime of the security association). > >=20 > > The identities used for the PaC and the PAA are less=20 > clearly described > in > > PANA (and also in the EAP context). Some of these issues will be > discussed > > again in the context of "key naming". > >=20 > > The identity of the NAS (in the IEEE context) or PAA (in=20 > PANA) has to > be > > mapped to attributes in the AAA infrastructure. Hence, within RADIUS > the NAS > > is identified by the NAS-Identifier, NAS-IP-Address and > NAS-IPv6-Address > > attributes. Although these attributes are kept very=20 > flexible it needs > to be > > ensured that they match to the PANA context. > >=20 > > --- > >=20 > > FOR DISCUSSION: Should the PANA SA be bound to a specific=20 > PaC <-> PAA? > This > > is particularly of interest for mobility. It needs to be evaluated > whether > > the discussion in the EAP keying design team (or within the EAP > working > > group in general) is an issue here or even in general=20 > (e.g., a virtual > NAS). >=20 > PANA SA is bound to a PANA session. we need to be more specific. see the key naming issues.=20 >=20 > >=20 > > FOR DISCUSSION: Should a new key be derived after the=20 > lifetime of the > PANA > > SA expires (as part of a re-authentication procedure)? This should > then > > require that the Lifetime AVP is mandatory in order for the PaC to > perform > > the same computation/protocol action. What protocol interaction is > required > > for rekeying? It should be noted that the expiration of the PANA SA > lifetime > > is not necessarily the same as a regular SA expiration. The lifetime > refers > > more likely to the authorization decision or some other security > policy > > based aspects of reauthentication interval. A clarification=20 > would be=20 > > necessary and helpful. >=20 > When the PANA session expires, if the peers are interested in=20 > continuing the "access", another run of EAP is executed=20 > inside PANA. This should create a new EAP SA, hence a new PANA SA. does this lead to a new session identifier? >=20 > >=20 > > --- > >=20 > > - Unicast Secure Association SA / IPsec SA > >=20 > > In [EAP-KEYING] a "unicast secure association SA" seems to be a link > layer > > specific security association which is used to protect the data > traffic > > itself. In the PANA context the equivalent would be an IPsec SA. >=20 > In theory, one might choose to enable L2 ciphering after a=20 > successful PANA authentication. For example, using the newly=20 > generated keys with WPA-PSK. I'm not aware of anyone looking=20 > at the details yet though. So, this is another possibility in=20 > addition to enabling IPsec-based access control. true.=20 >=20 > > Since PANA > > IPsec uses IKE or IKEv2, it would be necessary to consider also the > state > > established with these protocols. > >=20 > > The content of the "unicast secure association SA" is described as > >=20 > > - the peer port identifier (Calling-Station-Id) > > - the NAS port identifier (Called-Station-Id) > > - the unicast Transient Session Keys (TSKs) > > - the unicast secure association peer nonce > > - the unicast secure association authenticator nonce > > - the negotiated unicast capabilities and unicast ciphersuite. > >=20 > > For PANA IPsec usage three SAs are of relevance: > > - PANA-IKE-SA > > - IKE-SA/ISAKMP SA > > - IPsec SA > >=20 > > Each of these SAs have different attributes and a different=20 > lifetime. > >=20 > > The content of the IPsec SA and the IKE-SA/ISAKMP SA is described in > the > > relevant IPsec working group documents and will not be=20 > repeated here. > >=20 > > The PANA-IKE-SA, which is the state information used as input to the > IKE / > > IKEv2 exchange, is of interest here. The following information is > necessary: >=20 > So, is this what you are saying: >=20 > EAP SA -> PANA SA -> PANA-IKE-SA -> IPsec-SA >=20 > Do we need PANA-IKE-SA, or can we skip it? particuly of interest is the relationship between these sas. is it = always one-to-one or one-to-many? and this again depends how we "name" the = security associations and when we change these identifiers.=20 >=20 > >=20 > > - the PANA-SA derived key (which is indirectly used as a=20 > pre-shared=20 > > secret for IKE/IKEv2) > > - the identities of the PaC (IP address) and EP (also IP address) > (both > > IP addresses are > > made available to both entities during the PANA protocol > execution). > > - the Session ID > >=20 > > --- > >=20 > > FOR DISCUSSION: A key derived from the PANA SA key should be used as > input > > to the key derivation function for the IKE preshared secret key and > not the > > MSK. Mutual key confirmation is provided for the PANA SA key. > >=20 > > --- > >=20 > >> From authorization point of view it is necessary to ensure that the > IPsec > > SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain=20 > active after > the > > PANA context is removed since otherwise network resources could be > consumed > > without authorization. Since the PaC is able to send a terminate > message at > > any time there is a need for a good API between the PAA/EP and the > IKE/IPsec > > daemon. > >=20 > > --- > >=20 > > FOR DISCUSSION: > > Should a newly derived key for the PANA SA lead to a new=20 > key for the=20 > > PANA-IKE SA? My preference is NO. The PaC should, however,=20 > be able to=20 > > create a new IPsec SA at any time during the lifetime of a PANA SA.=20 > > Should the PAA be able to force the PaC to create a new IPsec SA? >=20 > > Should it be possible to create more than one IPsec SA=20 > between the PaC > and > > the EP at the same time (for example to support different quality of > service > > classes)? >=20 > I think this is beyond the scope of PANA design. If PANA=20 > provides a shared secret to PaC and EP for generation of an=20 > IPsec SA for access control, then its job is done. If someone=20 > proposes a design for generating multiple IPsec SAs from a=20 > single shared secret for QoS/etc reasons, then they can do so=20 > independent of where the shared secret came from. ok.=20 >=20 > >=20 > > --- > >=20 > >=20 > >=20 > > "Key Naming" > > ------------------ > >=20 > > This section discusses aspects of selecting a security associations > before > > applying protection to signaling messages or to data=20 > traffic itself. A > new > > term ("key naming") was invented to describe this selection of a > security > > association as part of the work done in the EAP working group. > >=20 > > To avoid confusion with new terms, a possible definition is included > here: > >=20 > > Key Naming: "Parameters used to index (=3D to select, or to=20 > point to) a=20 > > security association in order to protection the corresponding > cryptographic > > computation. The computation might be applied for inbound and for > outbound > > traffic." > >=20 > > As a well-known example, IPsec is used to describe the=20 > meaning of key=20 > > naming. Not that inbound and outbound processing is different. For > inbound > > processing an IPsec SA is selected using the destination IP address, > SPI and > > protocol type (ESP, AH). > > For outbound processing the IPsec SA is selected based on the > installed > > policies which highly differ from environment to environment. A > typical > > policy might protect all traffic between a source IP address and a > given > > destination IP address. The applicable policy then points=20 > to the IPsec > SA > > that has to be applied. In some cases even more than one IPsec SA > might be > > applied. > >=20 > >> From this example it can easily be seen that key naming has to > consider > > inbound and outbound processing separately for most protocols. > >=20 > > Section 3.5 of [EAP-KEYING] describes the following key names: > >=20 > > "EAP SA name: > > The EAP security association is uniquely named with EAP > > server name, EAP Method Type, EAP peer nonce, EAP server nonce>." > >=20 > > Please note that the EAP SA is created as a result of a full EAP > protocol > > run between the EAP peer and EAP server. It is for further study why > an EAP > > SA needs to be named. > >=20 > > "AAA-Key Name: > > The AAA-Key is named by the concatenation of the EAP SA name, > "AAA-Key" and > > the authenticator name." > >=20 > > For PANA the key naming of the EAP SA is not of interest here. The=20 > > definition of the AAA-Key name sounds like an input for a key > derivation > > function rather than information to select a security=20 > association. The > PANA > > SA name which should be equivalent to the AAA-Key name is=20 > selected as > > follows: > >=20 > > Inbound processing: > > The PAA is able to select the PANA security association of=20 > an incoming=20 > > signaling message based on the session identifier. The PaC=20 > is able to=20 > > select the PANA SA of an incoming signaling message > also > > based on the session identifier included in the header of the PANA > signaling > > message. > >=20 > > Note that in both cases it would be possible to use the socket pair > for the > > same purpose. > >=20 > > Outbound processing: > > For outbound processing at the PAA the socket is used to determine > where to > > send the message. The socket is selected either based on a=20 > reply which > is > > pending or based on information from the AAA infrastructure. State > must be > > stored to bind a message arriving from the PaC (e.g., an EAP payload > in the > > PANA-Auth-Answer message) and the EAP message send to the EAP server > via the > > AAA infrastructure. > >=20 > > TBD: What information elements are used here exactly to=20 > provide these=20 > > multiplexing capabilities? > >=20 > > For outbound processing at the PaC we have to consider a case where > the PaC > > is equipped with multiple interfaces and hence has to select the > correct > > one. At the end a socket is used to select which interface=20 > to send the=20 > > messages but to deal with IP address changes at the interfaces the > Session > > Identifier is used to as an intermediate pointer. Furthermore, > policies > > determine at which interface a message needs to be send in general > (e.g., > > reauthentication or an incoming request from the PAA which=20 > requires a=20 > > response). >=20 > I'm not sure if there is anything specific to PANA in here.=20 > These sound like general "how to send a UDP packet to peer" issues. i think there is. you might want to take a look at my previous comments. = >=20 > >=20 > > ----- > >=20 > > FOR DISCUSSION: If the PaC has to run a new re-authentication step > then a > > new EAP SA is created. As a consequence a new key for the=20 > PANA SA is=20 > > created. This is at least true for a full EAP protocol run (but it > might not > > be true for a "fast resume" since the desired properties=20 > have not been=20 > > described yet). >=20 > I presume you are referring to the fast resume features in=20 > "EAP methods"? From PANA perspective, whether it is fast=20 > resume or not, it will just look like "running EAP". in some sense you are right. i am, however, not sure whether an eap = method fast resume aims to provide new session keys.=20 >=20 > >=20 > > If two PANA SAs (with overlapping lifetime) exist in=20 > parallel then you > need > > a way to identify which SA to select. Two mechanisms are possible: > > - A key version number as in Kerberos which is increased=20 > and allows to=20 > > select the refer to the latest version of the key. For the=20 > purpose of > key > > naming both values, the session identifier and the key=20 > version number, > would > > be required. > > - A new identifier (e.g., SPI) such as in IPsec which itself has no > ordering > > property. Additionally the lifetime of the security association is > required > > to determine the most recent one. > >=20 > > Based on this, the following procedure is necessary to see whether > > - Is this a problem in PANA itself? > > - Is this a problem for PANA-IPsec handling? > > - If so, then which approach should be chosen in PANA: > > a) key version number > > b) modification of the identifier (the session identifier in our > case); > > This could mean that a new session identifier is created once a new > key is > > available. > >=20 > > ----- > >=20 > > For other protocols (such as IKE) rekeying turned out to be complex > with a > > number of failure cases. For IPsec SAs rekeying considerations are=20 > > dealt-with in IKE/IKEv2 itself. PANA, however, needs to=20 > make sure that > both > > views of the world are consistent based on the unreliable channel > provided > > with UDP >=20 > UDP itself is unreliable, but we have the ack mechanism for=20 > the Bind messages. >=20 > > (and the various error cases of the different protocols). It should=20 > > not be possible to create a protocol sequence whereby the=20 > PaC and the > PAA > > established different state. > >=20 > > Please note that the usage of the session identifier in the PANA > protocol is > > different from the one in PANA-IPsec handling. >=20 > Can you please elaborate, what kind of differences are you=20 > referring to. before we had this discussion mohans ipsec document used the session identifier in a different fashion. he said that he will change it.=20 >=20 > > The session identifier > > shipped to the EP mainly helps to associate the established PANA > session > > (and therefore the EAP authentication and authorization) to the > accounting > > mechanisms at the EP. > >=20 > > TBD: What mechanisms are available in IKE to indicate=20 > different keys? > Take a > > look at the PANA IPsec draft. IKE itself does not address different > versions > > of the pre-shared secret. The API used by IKE/IKEv2 must be able to > provide > > this functionality. > >=20 > > EAP Keying requirements > > ------------------------------- > >=20 > > Section 4.2.3 of [EAP-KEYING] lists a few requirements which have to > be met > > by the protocols using EAP. We will briefly list the=20 > requirements and=20 > > mention whether we believe that the individual requirement is met. > Beyond > > the requirements listed below a number of other requirements are > discussed > > in [EAP-KEYING] which are also relevant for PANA, such as=20 > AAA and EAP > method > > requirements. > >=20 > > - Mutual proof of possession > >=20 > > PANA provides mutual proof of possession (i.e., mutual key > confirmation) of > > a key derived from the AAA-Key (or more precisely from the MSK which > is > > transported to the PAA via the AAA infrastructure). > >=20 > > - Key Naming > >=20 > > Every protocol provides mechanisms to select the security > associations. PANA > > should be/is no different here. A previous section discusses some of > the > > issues which need to be addressed with regard to key naming and > different > > versions of the key. > >=20 > > - Creation and Deletion > >=20 > > This requirement mainly addresses the creation and deletion=20 > of phase 2=20 > > security associations. [EAP-KEYING] tightly binds the successful > execution > > of phase 2 with security associations for securing the data traffic. > This > > is, however, not the case in PANA since these are separate=20 > protocols. >=20 > I didn't understand this one. What exactly are you referring=20 > to as "separate protocols?" in pana (if you use ipsec sas) then you can delete an ipsec sa without = any impact for pana.=20 >=20 > > Some > > questions have been raised in this context in previous sections. > Deletion of > > the IPsec SAs MUST be accomplished indirectly with a PANA=20 > termination=20 > > message. > >=20 > > - Integrity and Replay Protection > >=20 > > Once the EAP exchange is successfully finished PANA=20 > signaling messages > can > > be integrity and replay protected. > >=20 > > - Direct operation > >=20 > > This requirement is highly tight to the IEEE environment=20 > where a link > layer > > security associations are established. Hence the requirement is made > that > > the protocol must only run between these two entities and=20 > not between > other > > parties. > >=20 > > For PANA this is, however, not the case since the EP might be > physically > > separated and hence it is required to transfer derived keys=20 > to the EP. > The > > transfer is controlled by the PAA and hence it is not=20 > possible by an=20 > > unauthorized entity to query the PAA for keys. Furthermore,=20 > the IPsec=20 > > SA and the IKE-SA/ISAKMP SA is not available to > the > > PAA itself. > >=20 > > - Derivation of transient session keys > >=20 > > In case of PANA the PANA protocol itself does not establish=20 > the IPsec > SAs > > directly. > >=20 > > - TSK freshness > >=20 > > As mentioned in the previous section PANA itself does not derive > unicast > > (and multicast) transient session keys. IPsec is=20 > responsible for this=20 > > purpose and provides these capabilities. IPsec SAs can be > reestablished > > independently of a PANA protocol. > >=20 > > - Bi-directional operation > >=20 > > This requirement addresses the establishment of uni-directional > security > > associations for protection of data traffic. Again, this requirement > is not > > directly applicable to PANA. IKE/IKEv2, however, establishes two > separate > > uni-lateral security associations. > >=20 > > - Secure capabilities negotiation > >=20 > > PANA does not negotiate capabilities during phase 0. However, some > form of > > limited capability negotiation takes place secured with the PANA > exchange. > > Cipher suites are not negotiated in PANA. > >=20 > > References > > ------------- > >=20 > > [EAP-KEYING] B. Aboba, D. Simon, J. Arkko and H.=20 > Levkowetz: "EAP > Key > > Management Framework", , (work in > progress), > > October, 2003. > >=20 > > [PANA-IPsec] M. Parthasarathy: "PANA enabling IPsec based Access > Control ", > > , (work in progress), October 2003. >=20 > Thanks. >=20 > Alper ciao hannes > =20 >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sat Jan 24 11:25:04 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13301 for ; Sat, 24 Jan 2004 11:25:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQaK-0006IL-1X for pana-archive@odin.ietf.org; Sat, 24 Jan 2004 11:24:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0OGOawh024193 for pana-archive@odin.ietf.org; Sat, 24 Jan 2004 11:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQaJ-0006I8-QG for pana-web-archive@optimus.ietf.org; Sat, 24 Jan 2004 11:24:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13296 for ; Sat, 24 Jan 2004 11:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkQaI-0004yl-00 for pana-web-archive@ietf.org; Sat, 24 Jan 2004 11:24:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkQZO-0004wg-00 for pana-web-archive@ietf.org; Sat, 24 Jan 2004 11:23:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkQYq-0004uU-00 for pana-web-archive@ietf.org; Sat, 24 Jan 2004 11:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQYn-0006Dj-3O; Sat, 24 Jan 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkQYS-0006DA-VB for pana@optimus.ietf.org; Sat, 24 Jan 2004 11:22:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13221 for ; Sat, 24 Jan 2004 11:22:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkQYS-0004sx-00 for pana@ietf.org; Sat, 24 Jan 2004 11:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkQXQ-0004qi-00 for pana@ietf.org; Sat, 24 Jan 2004 11:21:39 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AkQWY-0004oO-00 for pana@ietf.org; Sat, 24 Jan 2004 11:20:42 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i0OGKe000721; Sat, 24 Jan 2004 17:20:41 +0100 (MET) Received: from verena (rel036131xrelesn1.esn.sbs.de [149.246.36.131]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id i0OGKcl14773; Sat, 24 Jan 2004 17:20:38 +0100 (MET) From: "Hannes Tschofenig" To: "'Alper Yegin'" Cc: Subject: RE: [Pana] EAP keying issues and PANA Date: Sat, 24 Jan 2004 17:20:29 +0100 Message-ID: <007801c3e295$fc5306d0$0105a8c0@verena> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi alper,=20 sorry for the delay. please see my comments inline: > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com]=20 > Sent: Dienstag, 13. J=E4nner 2004 00:28 > To: Tschofenig Hannes > Cc: pana@ietf.org > Subject: Re: [Pana] EAP keying issues and PANA >=20 >=20 > Hello Hannes, >=20 > Thank you for this analysis! This is a very useful material=20 > for having this discussion... >=20 > Please see my inlined comments below. >=20 >=20 > > hi all, > >=20 > > an interesting issue with a relationship to the EAP keying work was > raised. > > i have tried (in this first shot) to write a short text on the EAP > keying > > issues as they appear in PANA. > >=20 > > this text also includes some discussion parts where further=20 > input is=20 > > required (denoted as FOR DISCUSSION). > >=20 > > ciao > > hannes > >=20 > > ------------- > >=20 > > Protocol Communication Overview > > ------------------------------------------- > >=20 > > This section discusses EAP keying issues and is therefore strongly > aligned > > with Section 1.3 of [EAP-Keying]. There the entire EAP communication > is > > separated into three steps. Note that the first step is actually not > part of > > EAP itself. > >=20 > > - Discovery phase (phase 0) > > - EAP authentication, key derivation and transport (phase 1) > > - Unicast security association establishment (phase 2) > >=20 > > The discovery phase in PANA has the goal to find the PAA in the > visited > > network. This step is very hard to secure in a roaming=20 > environment. In > many > > cases an additional security protection at this step would=20 > add denial > of > > service vulnerabilities. However, to prevent very basic denial of > service > > attacks, whereby an adversary floods the PAA with bogus requests, a > cookie > > exchange is used. In PANA no capability discovery takes=20 > place at phase > 0. > >=20 > > Phase 1 is subdivided into two phases: Phase 1a and phase=20 > 1b. In phase > 1a > > the PAA starts sending the initial EAP packet and thereby initiates > the > > authentication procedure. The PAA might implement some EAP=20 > methods or > in > > many cases not even a single one - it acts as a passthrough device > which > > interacts with a backend authentication server. > >=20 > > EAP methods might provide key derivation and mutual authentication. > PANA > > leaves the choice to network architects which EAP methods=20 > to mandate. > This > > is necessary to fullfil the requirements of the larger number of > deployment > > scenarios. In case of wireless networks without physical or=20 > link layer=20 > > security the suggestions of [EAP-KEYING] with regard to EAP methods > should > > be followed. Methods which provide session key establishment and > mutual > > authentication are mandated. > >=20 > > Since the key derivation takes place between the EAP peer=20 > and the EAP > server > > it is (in many cases) necessary to transport the keying=20 > material from > the > > EAP server to the Authenticator (which corresponds to the PAA in > PANA). This > > step is referred as phase 1b. If the EAP server and the=20 > Authenticator > are > > co-located then this step is replaced by an API call. > >=20 > > Since PANA signaling messages need protection a PANA SA needs to be=20 > > established between the PaC and the PAA >=20 > The PANA SA is needed to provide the keys for the so-called=20 > phase 2. While we have this SA, we thought we can also use it=20 > for securing the subsequent PANA exchanges. Though, it is not=20 > a requirement that PANA, as a EAP lower layer, needs this=20 > kind of protection. that is true. for some scenarios this pana sa is not needed while for = others it is.=20 pana can operate in many different environments.=20 >=20 > > whereby new keying material needs to > > be derived from the key provided by the EAP method. This step is a > slight > > deviation from IEEE 802.1X since PANA does not automatically create > security > > associations for data traffic protection. >=20 > 802.1X does not either. It's the 4-way handshake of 802.11i=20 > that creates this SA. true. the ieee folks have separated these issues into two documents. = they, however, belong together.=20 >=20 > > With the help of EAP session keys are in place and PANA needs to > create, > > delete and update the parameters of the PANA SA. > >=20 > > PANA makes a more fine-grain separation in phase 2. Parts=20 > of phase 2a > are > > accomplished within PANA and some parts are delegated towards IKE if > IPsec > > SA establishment is desired (see [PANA-IPsec]). Phase 2b does not > exist in > > PANA. We will address the differences in more details in=20 > this section. > >=20 > > Figure 1 shows the communication overview. The figure is taken from=20 > > [EAP-Keying] and modified accordingly. The "Unicast Secure=20 > association=20 > > (phase 2a)" is replaced by the abstract term PANA Phase 2=20 > to avoid a=20 > > terminology confusion. > >=20 > >=20 > > EAP peer/PaC Authenticator/PAA Auth. Server > > ------------ ----------------- ------------ > > |<----------------------------->| =20 > | > > | Discovery (phase 0) | =20 > | > > =20 > |<----------------------------->|<----------------------------->| > > | EAP auth (phase 1a) | AAA pass-through=20 > (optional) | > > | | =20 > | > > | =20 > |<----------------------------->| > > | | AAA-Key=20 > transport | > > | | (optional; phase=20 > 1b) | > > |<----------------------------->| =20 > | > > | PANA Phase 2 | =20 > | > > | | =20 > | > > |<----------------------------->| =20 > | > > | IKE/IPsec SA establishment | =20 > | > > | (optional) | =20 > | > > | | =20 > | >=20 > I didn't understand why we have "PANA phase 2". Normally PANA=20 > should not "leak into" phase 2. Phase 2 is for IKE (or, in=20 > the case of 802.1X-based systems, 4-way handshake) well, the usage of the EAP derived keys for the pana sa provides key confirmation once you use the keys for protection of the signaling = messages. hence it is better to use the pana derived keys for the ipsec sa = compared to the pure eap method derived key.=20 >=20 > >=20 > > Figure 1: Communication Overview > >=20 > > Figure 1 ignores the fact that the Authenticator/PAA can=20 > physically be=20 > > separated from the Enforcement Point (EP). In this case IKE=20 > would not > run > > between the PaC and the PAA. > >=20 > > Phase 2 is executed after a successful EAP exchange in phase 1 > (including > > the transport of keying material to the Authenticator). > >=20 > > This phase accomplishes the following tasks (compared with the list=20 > > described in Section 1.3 of [EAP-KEYING]): > >=20 > > - Since PANA does not negotiate parameters during the=20 > discovery phase > it is > > not possible to confirm them. No cipher suite negotiation=20 > takes place > in > > PANA. > >=20 > > - PANA securely provides an exchange of parameters and=20 > usage modes as > part > > of the PANA-Bind-Request message (such as Device-Id, Lifetime,=20 > > Protection-Cap AVPs). > >=20 > > - PANA does not derive further session keys for protection of data > traffic. > > If an IPsec has to be established then IKE or IKEv2 is used. > >=20 > > - Mutual key confirmation (PAA to PaC with the help of the > PANA-Bind-Request > > and PaC to PAA with the help of the PANA-Bind-Answer message) is > provided. > > This ensure that both, the PaC and the PAA, successfully=20 > executed EAP > and, > > in the case of the PAA, were able to create the necessary keys and > parameter > > for the PANA SA. > >=20 > > - The PANA SA is active immediately after the PANA SA is established > (i.e., > > after the EAP method was successfully executed and session keys are=20 > > available). > >=20 > > - PANA also offers a mechanism for terminating access and to delete > the > > established state with the help of the PANA-Termination-Request and=20 > > PANA-Termination-Answer message. Without sending such a message the > PAA and > > the PaC delete their established state after lifetime expiration. > >=20 > > Security Associations > > -------------------------- > >=20 > > Several different security associations are created as part of the > PANA > > exchange. We will describe of them in some level of detail whereby > some PANA > > specific aspects might lead to discussions. > >=20 > > - EAP SA > >=20 > > First, there is the EAP SA which is described in Section 3.1 of=20 > > [EAP-KEYING]. Due to the nature of EAP there are some=20 > restrictions on > the > > EAP SA such as the missing lifetime negotiation, no SA delete > operation etc. > > Some EAP methods provide enhanced functionality by establishing > additional > > state which is subject to special optimizations such as=20 > "fast resume". > A > > detailed discussion of these issues is beyond the scope of PANA. > >=20 > > - AAA-Key SA / PANA SA > >=20 > > The AAA-Key SA described in Section 3.2 of [EAP-KEYING] seems to be > the > > counterpart of the PANA SA. This security association exists between > the PaC > > and the PAA. The following parameters constitute this AAA-Key SA: > >=20 > > - the EAP peer name > > - the NAS/authenticator name > > - the AAA-Key > > - the AAA-Key maximum lifetime (if known) > > - the AAA attributes sent in the Access-Accept > >=20 > > The subsequent paragraph is an attempt to map the text in=20 > [EAP-KEYING] > to > > PANA. > >=20 > > For the PANA-SA at the PAA would have the following parameters: > > - AAA attributes (obtained via the Access-Accept) > > - Lifetime (optional?) > > - Key of the PANA SA (derived from the AAA-Key) > > - Socket-Pair information (Src/Dst IP address, Src/Port, UDP > protocol) >=20 > We don't really deal with "sockets" context in the PANA=20 > design. Instead, I think we can refer to the "device IDs" in here. >=20 the term device id is an abstract term. you certainly have to consider a source and a destination "device id" (ip address, mac address) > > - Session ID > > The PANA-SA at the PaC contains similar attributes except=20 > for the AAA=20 > > attributes since they are invisible to the PaC. > >=20 > > The lifetime of the PANA SA is determined by a number of parameters. > The > > Lifetime AVP transmitted to the PaC is an indication for=20 > the PaC about > the > > time duration granted for network access (and therefore=20 > also for the=20 > > lifetime of the security association). > >=20 > > The identities used for the PaC and the PAA are less=20 > clearly described > in > > PANA (and also in the EAP context). Some of these issues will be > discussed > > again in the context of "key naming". > >=20 > > The identity of the NAS (in the IEEE context) or PAA (in=20 > PANA) has to > be > > mapped to attributes in the AAA infrastructure. Hence, within RADIUS > the NAS > > is identified by the NAS-Identifier, NAS-IP-Address and > NAS-IPv6-Address > > attributes. Although these attributes are kept very=20 > flexible it needs > to be > > ensured that they match to the PANA context. > >=20 > > --- > >=20 > > FOR DISCUSSION: Should the PANA SA be bound to a specific=20 > PaC <-> PAA? > This > > is particularly of interest for mobility. It needs to be evaluated > whether > > the discussion in the EAP keying design team (or within the EAP > working > > group in general) is an issue here or even in general=20 > (e.g., a virtual > NAS). >=20 > PANA SA is bound to a PANA session. we need to be more specific. see the key naming issues.=20 >=20 > >=20 > > FOR DISCUSSION: Should a new key be derived after the=20 > lifetime of the > PANA > > SA expires (as part of a re-authentication procedure)? This should > then > > require that the Lifetime AVP is mandatory in order for the PaC to > perform > > the same computation/protocol action. What protocol interaction is > required > > for rekeying? It should be noted that the expiration of the PANA SA > lifetime > > is not necessarily the same as a regular SA expiration. The lifetime > refers > > more likely to the authorization decision or some other security > policy > > based aspects of reauthentication interval. A clarification=20 > would be=20 > > necessary and helpful. >=20 > When the PANA session expires, if the peers are interested in=20 > continuing the "access", another run of EAP is executed=20 > inside PANA. This should create a new EAP SA, hence a new PANA SA. does this lead to a new session identifier? >=20 > >=20 > > --- > >=20 > > - Unicast Secure Association SA / IPsec SA > >=20 > > In [EAP-KEYING] a "unicast secure association SA" seems to be a link > layer > > specific security association which is used to protect the data > traffic > > itself. In the PANA context the equivalent would be an IPsec SA. >=20 > In theory, one might choose to enable L2 ciphering after a=20 > successful PANA authentication. For example, using the newly=20 > generated keys with WPA-PSK. I'm not aware of anyone looking=20 > at the details yet though. So, this is another possibility in=20 > addition to enabling IPsec-based access control. true.=20 >=20 > > Since PANA > > IPsec uses IKE or IKEv2, it would be necessary to consider also the > state > > established with these protocols. > >=20 > > The content of the "unicast secure association SA" is described as > >=20 > > - the peer port identifier (Calling-Station-Id) > > - the NAS port identifier (Called-Station-Id) > > - the unicast Transient Session Keys (TSKs) > > - the unicast secure association peer nonce > > - the unicast secure association authenticator nonce > > - the negotiated unicast capabilities and unicast ciphersuite. > >=20 > > For PANA IPsec usage three SAs are of relevance: > > - PANA-IKE-SA > > - IKE-SA/ISAKMP SA > > - IPsec SA > >=20 > > Each of these SAs have different attributes and a different=20 > lifetime. > >=20 > > The content of the IPsec SA and the IKE-SA/ISAKMP SA is described in > the > > relevant IPsec working group documents and will not be=20 > repeated here. > >=20 > > The PANA-IKE-SA, which is the state information used as input to the > IKE / > > IKEv2 exchange, is of interest here. The following information is > necessary: >=20 > So, is this what you are saying: >=20 > EAP SA -> PANA SA -> PANA-IKE-SA -> IPsec-SA >=20 > Do we need PANA-IKE-SA, or can we skip it? particuly of interest is the relationship between these sas. is it = always one-to-one or one-to-many? and this again depends how we "name" the = security associations and when we change these identifiers.=20 >=20 > >=20 > > - the PANA-SA derived key (which is indirectly used as a=20 > pre-shared=20 > > secret for IKE/IKEv2) > > - the identities of the PaC (IP address) and EP (also IP address) > (both > > IP addresses are > > made available to both entities during the PANA protocol > execution). > > - the Session ID > >=20 > > --- > >=20 > > FOR DISCUSSION: A key derived from the PANA SA key should be used as > input > > to the key derivation function for the IKE preshared secret key and > not the > > MSK. Mutual key confirmation is provided for the PANA SA key. > >=20 > > --- > >=20 > >> From authorization point of view it is necessary to ensure that the > IPsec > > SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain=20 > active after > the > > PANA context is removed since otherwise network resources could be > consumed > > without authorization. Since the PaC is able to send a terminate > message at > > any time there is a need for a good API between the PAA/EP and the > IKE/IPsec > > daemon. > >=20 > > --- > >=20 > > FOR DISCUSSION: > > Should a newly derived key for the PANA SA lead to a new=20 > key for the=20 > > PANA-IKE SA? My preference is NO. The PaC should, however,=20 > be able to=20 > > create a new IPsec SA at any time during the lifetime of a PANA SA.=20 > > Should the PAA be able to force the PaC to create a new IPsec SA? >=20 > > Should it be possible to create more than one IPsec SA=20 > between the PaC > and > > the EP at the same time (for example to support different quality of > service > > classes)? >=20 > I think this is beyond the scope of PANA design. If PANA=20 > provides a shared secret to PaC and EP for generation of an=20 > IPsec SA for access control, then its job is done. If someone=20 > proposes a design for generating multiple IPsec SAs from a=20 > single shared secret for QoS/etc reasons, then they can do so=20 > independent of where the shared secret came from. ok.=20 >=20 > >=20 > > --- > >=20 > >=20 > >=20 > > "Key Naming" > > ------------------ > >=20 > > This section discusses aspects of selecting a security associations > before > > applying protection to signaling messages or to data=20 > traffic itself. A > new > > term ("key naming") was invented to describe this selection of a > security > > association as part of the work done in the EAP working group. > >=20 > > To avoid confusion with new terms, a possible definition is included > here: > >=20 > > Key Naming: "Parameters used to index (=3D to select, or to=20 > point to) a=20 > > security association in order to protection the corresponding > cryptographic > > computation. The computation might be applied for inbound and for > outbound > > traffic." > >=20 > > As a well-known example, IPsec is used to describe the=20 > meaning of key=20 > > naming. Not that inbound and outbound processing is different. For > inbound > > processing an IPsec SA is selected using the destination IP address, > SPI and > > protocol type (ESP, AH). > > For outbound processing the IPsec SA is selected based on the > installed > > policies which highly differ from environment to environment. A > typical > > policy might protect all traffic between a source IP address and a > given > > destination IP address. The applicable policy then points=20 > to the IPsec > SA > > that has to be applied. In some cases even more than one IPsec SA > might be > > applied. > >=20 > >> From this example it can easily be seen that key naming has to > consider > > inbound and outbound processing separately for most protocols. > >=20 > > Section 3.5 of [EAP-KEYING] describes the following key names: > >=20 > > "EAP SA name: > > The EAP security association is uniquely named with EAP > > server name, EAP Method Type, EAP peer nonce, EAP server nonce>." > >=20 > > Please note that the EAP SA is created as a result of a full EAP > protocol > > run between the EAP peer and EAP server. It is for further study why > an EAP > > SA needs to be named. > >=20 > > "AAA-Key Name: > > The AAA-Key is named by the concatenation of the EAP SA name, > "AAA-Key" and > > the authenticator name." > >=20 > > For PANA the key naming of the EAP SA is not of interest here. The=20 > > definition of the AAA-Key name sounds like an input for a key > derivation > > function rather than information to select a security=20 > association. The > PANA > > SA name which should be equivalent to the AAA-Key name is=20 > selected as > > follows: > >=20 > > Inbound processing: > > The PAA is able to select the PANA security association of=20 > an incoming=20 > > signaling message based on the session identifier. The PaC=20 > is able to=20 > > select the PANA SA of an incoming signaling message > also > > based on the session identifier included in the header of the PANA > signaling > > message. > >=20 > > Note that in both cases it would be possible to use the socket pair > for the > > same purpose. > >=20 > > Outbound processing: > > For outbound processing at the PAA the socket is used to determine > where to > > send the message. The socket is selected either based on a=20 > reply which > is > > pending or based on information from the AAA infrastructure. State > must be > > stored to bind a message arriving from the PaC (e.g., an EAP payload > in the > > PANA-Auth-Answer message) and the EAP message send to the EAP server > via the > > AAA infrastructure. > >=20 > > TBD: What information elements are used here exactly to=20 > provide these=20 > > multiplexing capabilities? > >=20 > > For outbound processing at the PaC we have to consider a case where > the PaC > > is equipped with multiple interfaces and hence has to select the > correct > > one. At the end a socket is used to select which interface=20 > to send the=20 > > messages but to deal with IP address changes at the interfaces the > Session > > Identifier is used to as an intermediate pointer. Furthermore, > policies > > determine at which interface a message needs to be send in general > (e.g., > > reauthentication or an incoming request from the PAA which=20 > requires a=20 > > response). >=20 > I'm not sure if there is anything specific to PANA in here.=20 > These sound like general "how to send a UDP packet to peer" issues. i think there is. you might want to take a look at my previous comments. = >=20 > >=20 > > ----- > >=20 > > FOR DISCUSSION: If the PaC has to run a new re-authentication step > then a > > new EAP SA is created. As a consequence a new key for the=20 > PANA SA is=20 > > created. This is at least true for a full EAP protocol run (but it > might not > > be true for a "fast resume" since the desired properties=20 > have not been=20 > > described yet). >=20 > I presume you are referring to the fast resume features in=20 > "EAP methods"? From PANA perspective, whether it is fast=20 > resume or not, it will just look like "running EAP". in some sense you are right. i am, however, not sure whether an eap = method fast resume aims to provide new session keys.=20 >=20 > >=20 > > If two PANA SAs (with overlapping lifetime) exist in=20 > parallel then you > need > > a way to identify which SA to select. Two mechanisms are possible: > > - A key version number as in Kerberos which is increased=20 > and allows to=20 > > select the refer to the latest version of the key. For the=20 > purpose of > key > > naming both values, the session identifier and the key=20 > version number, > would > > be required. > > - A new identifier (e.g., SPI) such as in IPsec which itself has no > ordering > > property. Additionally the lifetime of the security association is > required > > to determine the most recent one. > >=20 > > Based on this, the following procedure is necessary to see whether > > - Is this a problem in PANA itself? > > - Is this a problem for PANA-IPsec handling? > > - If so, then which approach should be chosen in PANA: > > a) key version number > > b) modification of the identifier (the session identifier in our > case); > > This could mean that a new session identifier is created once a new > key is > > available. > >=20 > > ----- > >=20 > > For other protocols (such as IKE) rekeying turned out to be complex > with a > > number of failure cases. For IPsec SAs rekeying considerations are=20 > > dealt-with in IKE/IKEv2 itself. PANA, however, needs to=20 > make sure that > both > > views of the world are consistent based on the unreliable channel > provided > > with UDP >=20 > UDP itself is unreliable, but we have the ack mechanism for=20 > the Bind messages. >=20 > > (and the various error cases of the different protocols). It should=20 > > not be possible to create a protocol sequence whereby the=20 > PaC and the > PAA > > established different state. > >=20 > > Please note that the usage of the session identifier in the PANA > protocol is > > different from the one in PANA-IPsec handling. >=20 > Can you please elaborate, what kind of differences are you=20 > referring to. before we had this discussion mohans ipsec document used the session identifier in a different fashion. he said that he will change it.=20 >=20 > > The session identifier > > shipped to the EP mainly helps to associate the established PANA > session > > (and therefore the EAP authentication and authorization) to the > accounting > > mechanisms at the EP. > >=20 > > TBD: What mechanisms are available in IKE to indicate=20 > different keys? > Take a > > look at the PANA IPsec draft. IKE itself does not address different > versions > > of the pre-shared secret. The API used by IKE/IKEv2 must be able to > provide > > this functionality. > >=20 > > EAP Keying requirements > > ------------------------------- > >=20 > > Section 4.2.3 of [EAP-KEYING] lists a few requirements which have to > be met > > by the protocols using EAP. We will briefly list the=20 > requirements and=20 > > mention whether we believe that the individual requirement is met. > Beyond > > the requirements listed below a number of other requirements are > discussed > > in [EAP-KEYING] which are also relevant for PANA, such as=20 > AAA and EAP > method > > requirements. > >=20 > > - Mutual proof of possession > >=20 > > PANA provides mutual proof of possession (i.e., mutual key > confirmation) of > > a key derived from the AAA-Key (or more precisely from the MSK which > is > > transported to the PAA via the AAA infrastructure). > >=20 > > - Key Naming > >=20 > > Every protocol provides mechanisms to select the security > associations. PANA > > should be/is no different here. A previous section discusses some of > the > > issues which need to be addressed with regard to key naming and > different > > versions of the key. > >=20 > > - Creation and Deletion > >=20 > > This requirement mainly addresses the creation and deletion=20 > of phase 2=20 > > security associations. [EAP-KEYING] tightly binds the successful > execution > > of phase 2 with security associations for securing the data traffic. > This > > is, however, not the case in PANA since these are separate=20 > protocols. >=20 > I didn't understand this one. What exactly are you referring=20 > to as "separate protocols?" in pana (if you use ipsec sas) then you can delete an ipsec sa without = any impact for pana.=20 >=20 > > Some > > questions have been raised in this context in previous sections. > Deletion of > > the IPsec SAs MUST be accomplished indirectly with a PANA=20 > termination=20 > > message. > >=20 > > - Integrity and Replay Protection > >=20 > > Once the EAP exchange is successfully finished PANA=20 > signaling messages > can > > be integrity and replay protected. > >=20 > > - Direct operation > >=20 > > This requirement is highly tight to the IEEE environment=20 > where a link > layer > > security associations are established. Hence the requirement is made > that > > the protocol must only run between these two entities and=20 > not between > other > > parties. > >=20 > > For PANA this is, however, not the case since the EP might be > physically > > separated and hence it is required to transfer derived keys=20 > to the EP. > The > > transfer is controlled by the PAA and hence it is not=20 > possible by an=20 > > unauthorized entity to query the PAA for keys. Furthermore,=20 > the IPsec=20 > > SA and the IKE-SA/ISAKMP SA is not available to > the > > PAA itself. > >=20 > > - Derivation of transient session keys > >=20 > > In case of PANA the PANA protocol itself does not establish=20 > the IPsec > SAs > > directly. > >=20 > > - TSK freshness > >=20 > > As mentioned in the previous section PANA itself does not derive > unicast > > (and multicast) transient session keys. IPsec is=20 > responsible for this=20 > > purpose and provides these capabilities. IPsec SAs can be > reestablished > > independently of a PANA protocol. > >=20 > > - Bi-directional operation > >=20 > > This requirement addresses the establishment of uni-directional > security > > associations for protection of data traffic. Again, this requirement > is not > > directly applicable to PANA. IKE/IKEv2, however, establishes two > separate > > uni-lateral security associations. > >=20 > > - Secure capabilities negotiation > >=20 > > PANA does not negotiate capabilities during phase 0. However, some > form of > > limited capability negotiation takes place secured with the PANA > exchange. > > Cipher suites are not negotiated in PANA. > >=20 > > References > > ------------- > >=20 > > [EAP-KEYING] B. Aboba, D. Simon, J. Arkko and H.=20 > Levkowetz: "EAP > Key > > Management Framework", , (work in > progress), > > October, 2003. > >=20 > > [PANA-IPsec] M. Parthasarathy: "PANA enabling IPsec based Access > Control ", > > , (work in progress), October 2003. >=20 > Thanks. >=20 > Alper ciao hannes > =20 >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 03:21:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24366 for ; Mon, 26 Jan 2004 03:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al1zU-0000I9-2E; Mon, 26 Jan 2004 03:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Ec-0001G3-6Q for pana@optimus.ietf.org; Fri, 23 Jan 2004 13:40:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15586 for ; Fri, 23 Jan 2004 13:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6EY-0006BA-00 for pana@ietf.org; Fri, 23 Jan 2004 13:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Db-00069o-00 for pana@ietf.org; Fri, 23 Jan 2004 13:39:47 -0500 Received: from v180.mailsnare.net ([206.246.200.180] helo=mail.mailsnare.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Ck-00067Q-00 for pana@ietf.org; Fri, 23 Jan 2004 13:38:54 -0500 Received: from TOSHI2004 (tari-dhcp158.research.telcordia.com [207.3.232.158]) by mail.mailsnare.net (Postfix) with SMTP id 1DF0310EB75; Fri, 23 Jan 2004 18:38:13 +0000 (UTC) Message-ID: <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> From: "Victor Fajardo" To: "Yoshihiro Ohba" , References: <20040123164820.GR26285@steelhead> Subject: Re: [Pana] SESS_RESUM in state machine Date: Fri, 23 Jan 2004 13:38:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by Clam AntiVirus X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In addition, it seems SESS_RESUM is used to flag the inclusion/exclusion of the session-id AVP in the start answer message of the Pac state machine. But at this point, the PAA is offline (stateless with regards to keeping knowledge about the Pac) and hence will not have established a session id. -- victor > In the PAA state machine, there is a variable SESS_RESUM and > there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action > "Tx: PANA-Reauth-Request". > > However, I was not able to found the text in the base specification to > allow this transition. When the PAA is in OFFLINE state, it means the > session is deleted and there is no PANA SA. So it is not possible for > the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. > > I think this transition should be removed and thus SESS_RESUM is not > necessary. > > The same thing applies to the PaC state machine. There is a > transition from WAIT_PAA to OPEN with an action "Tx: > PANA-Reauth-Answer". I think this should not be allowed for the same > reason. > > To summarize: PANA-Reauth-Request/Answer exchange should occur only in > OPEN state for both PaC and PAA. > > Regards, > Yoshihiro Ohba > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 03:23:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24426 for ; Mon, 26 Jan 2004 03:23:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al217-0000Q6-CR for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 03:22:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q8Mjoa001610 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 03:22:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al217-0000Pt-1R for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 03:22:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24407 for ; Mon, 26 Jan 2004 03:22:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al214-0004od-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 03:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al209-0004ma-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 03:21:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Al1zZ-0004l4-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 03:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al1zU-0000I9-2E; Mon, 26 Jan 2004 03:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak6Ec-0001G3-6Q for pana@optimus.ietf.org; Fri, 23 Jan 2004 13:40:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15586 for ; Fri, 23 Jan 2004 13:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak6EY-0006BA-00 for pana@ietf.org; Fri, 23 Jan 2004 13:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak6Db-00069o-00 for pana@ietf.org; Fri, 23 Jan 2004 13:39:47 -0500 Received: from v180.mailsnare.net ([206.246.200.180] helo=mail.mailsnare.net) by ietf-mx with esmtp (Exim 4.12) id 1Ak6Ck-00067Q-00 for pana@ietf.org; Fri, 23 Jan 2004 13:38:54 -0500 Received: from TOSHI2004 (tari-dhcp158.research.telcordia.com [207.3.232.158]) by mail.mailsnare.net (Postfix) with SMTP id 1DF0310EB75; Fri, 23 Jan 2004 18:38:13 +0000 (UTC) Message-ID: <009301c3e1e0$15bb34a0$b19dfea9@TOSHI2004> From: "Victor Fajardo" To: "Yoshihiro Ohba" , References: <20040123164820.GR26285@steelhead> Subject: Re: [Pana] SESS_RESUM in state machine Date: Fri, 23 Jan 2004 13:38:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by Clam AntiVirus Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In addition, it seems SESS_RESUM is used to flag the inclusion/exclusion of the session-id AVP in the start answer message of the Pac state machine. But at this point, the PAA is offline (stateless with regards to keeping knowledge about the Pac) and hence will not have established a session id. -- victor > In the PAA state machine, there is a variable SESS_RESUM and > there is a transition from OFFLINE to WAIT_REAUTH_ANS with an action > "Tx: PANA-Reauth-Request". > > However, I was not able to found the text in the base specification to > allow this transition. When the PAA is in OFFLINE state, it means the > session is deleted and there is no PANA SA. So it is not possible for > the PAA in OFFLINE state to send a PANA-Reauth-Request with a MAC AVP. > > I think this transition should be removed and thus SESS_RESUM is not > necessary. > > The same thing applies to the PaC state machine. There is a > transition from WAIT_PAA to OPEN with an action "Tx: > PANA-Reauth-Answer". I think this should not be allowed for the same > reason. > > To summarize: PANA-Reauth-Request/Answer exchange should occur only in > OPEN state for both PaC and PAA. > > Regards, > Yoshihiro Ohba > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 04:02:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25265 for ; Mon, 26 Jan 2004 04:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2d7-0002gA-P0; Mon, 26 Jan 2004 04:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2cs-0002fY-4A for pana@optimus.ietf.org; Mon, 26 Jan 2004 04:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25261 for ; Mon, 26 Jan 2004 04:01:44 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al2cp-00068k-00 for pana@ietf.org; Mon, 26 Jan 2004 04:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al2br-00067e-00 for pana@ietf.org; Mon, 26 Jan 2004 04:00:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Al2bk-00066h-00 for pana@ietf.org; Mon, 26 Jan 2004 04:00:36 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0Q90bY12081 for ; Mon, 26 Jan 2004 11:00:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 11:00:37 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 11:00:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 38 Date: Mon, 26 Jan 2004 11:00:36 +0200 Message-ID: Thread-Topic: [Pana] issue 38 Thread-Index: AcPhW5DfB+zN6TPPR7Wd+krQNDcREACj0Mag To: X-OriginalArrivalTime: 26 Jan 2004 09:00:36.0518 (UTC) FILETIME=[DCF19C60:01C3E3EA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree too. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 23 January, 2004 04:44 > To: Alper Yegin > Cc: Yoshihiro Ohba; pana@ietf.org > Subject: Re: [Pana] issue 38 > > > On Thu, Jan 22, 2004 at 06:07:04PM -0800, Alper Yegin wrote: > > > > > > Considering possible future evolution of cryptography, I think > > > hard-coding algorithm type in the specification is not desirable. > > > > OK, we can include an algorithm type, and allocate a number > for HMAC-SHA1 > > today, with the provision that more can be added later. I > think this can be > > the base line, without supporting HMAC-MD5. (we don't have > to create an > > interop problem from day one by also supporting HMAC-MD5 > which is not even > > recommended for use). > > I agree. > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > > Yoshihiro Ohba > > > > > > > > >> > > >> Alper > > >> > > >> > > >>> > > >>> Here is suggested text: > > >>> > > >>> In section 4.1.6, change: > > >>> > > >>> "When a MAC AVP is included in a PANA message, the > value field of the > > >>> MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > >>> > > >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > >>> > > >>> where PANA_PDU is the PANA message including the PANA > header, with > > >>> the MAC AVP value field first initialized to 0." > > >>> > > >>> to: > > >>> > > >>> "When a MAC AVP is included in a PANA message, the > value field of the > > >>> MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > >>> > > >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > >>> > > >>> where PANA_PDU is the PANA message including the PANA > header, with > > >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > >>> represents the pseudo random function corresponding to the MAC > > >>> algorithm specified in the MAC AVP. In this version of draft, > > >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC > and PAA MUST > > >>> use the same algorithm to calculate a MAC AVP they > originate and > > >>> receive. The algorithm is determined by the PAA when > > >>> a PANA-Bind-Request with a MAC AVP is sent. When the > PaC does not > > >>> support the MAC algorithm specified in the PANA-Bind-Request > > >>> message, it MUST silently discard the message. The > PAA MUST NOT > > >>> change the MAC algorithm throughout the continuation > of the PANA > > >>> session." > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Yoshihiro Ohba > > >>> > > >>> _______________________________________________ > > >>> Pana mailing list > > >>> Pana@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/pana > > >>> > > >> > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 04:16:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25684 for ; Mon, 26 Jan 2004 04:16:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2r7-0003bu-B8 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 04:16:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0Q9GTq5013878 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 04:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2r6-0003bi-N9 for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 04:16:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25650 for ; Mon, 26 Jan 2004 04:16:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al2r4-0006mt-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 04:16:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al2qE-0006fG-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 04:15:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Al2pK-0006Va-04 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 04:14:38 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Al2dE-0001a7-81 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 04:02:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2d7-0002gA-P0; Mon, 26 Jan 2004 04:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al2cs-0002fY-4A for pana@optimus.ietf.org; Mon, 26 Jan 2004 04:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25261 for ; Mon, 26 Jan 2004 04:01:44 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al2cp-00068k-00 for pana@ietf.org; Mon, 26 Jan 2004 04:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al2br-00067e-00 for pana@ietf.org; Mon, 26 Jan 2004 04:00:44 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Al2bk-00066h-00 for pana@ietf.org; Mon, 26 Jan 2004 04:00:36 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0Q90bY12081 for ; Mon, 26 Jan 2004 11:00:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 26 Jan 2004 11:00:37 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 11:00:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] issue 38 Date: Mon, 26 Jan 2004 11:00:36 +0200 Message-ID: Thread-Topic: [Pana] issue 38 Thread-Index: AcPhW5DfB+zN6TPPR7Wd+krQNDcREACj0Mag To: X-OriginalArrivalTime: 26 Jan 2004 09:00:36.0518 (UTC) FILETIME=[DCF19C60:01C3E3EA] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree too. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > Behalf Of ext Yoshihiro Ohba > Sent: 23 January, 2004 04:44 > To: Alper Yegin > Cc: Yoshihiro Ohba; pana@ietf.org > Subject: Re: [Pana] issue 38 > > > On Thu, Jan 22, 2004 at 06:07:04PM -0800, Alper Yegin wrote: > > > > > > Considering possible future evolution of cryptography, I think > > > hard-coding algorithm type in the specification is not desirable. > > > > OK, we can include an algorithm type, and allocate a number > for HMAC-SHA1 > > today, with the provision that more can be added later. I > think this can be > > the base line, without supporting HMAC-MD5. (we don't have > to create an > > interop problem from day one by also supporting HMAC-MD5 > which is not even > > recommended for use). > > I agree. > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > > Yoshihiro Ohba > > > > > > > > >> > > >> Alper > > >> > > >> > > >>> > > >>> Here is suggested text: > > >>> > > >>> In section 4.1.6, change: > > >>> > > >>> "When a MAC AVP is included in a PANA message, the > value field of the > > >>> MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > >>> > > >>> MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) > > >>> > > >>> where PANA_PDU is the PANA message including the PANA > header, with > > >>> the MAC AVP value field first initialized to 0." > > >>> > > >>> to: > > >>> > > >>> "When a MAC AVP is included in a PANA message, the > value field of the > > >>> MAC AVP is calculated by using the PANA_MAC_Key in the > following way: > > >>> > > >>> MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) > > >>> > > >>> where PANA_PDU is the PANA message including the PANA > header, with > > >>> the MAC AVP value field first initialized to 0. PANA_MAC_PRF > > >>> represents the pseudo random function corresponding to the MAC > > >>> algorithm specified in the MAC AVP. In this version of draft, > > >>> PANA_MAC_PRF is either HMAC-MD5 or HMAC-SHA1. The PaC > and PAA MUST > > >>> use the same algorithm to calculate a MAC AVP they > originate and > > >>> receive. The algorithm is determined by the PAA when > > >>> a PANA-Bind-Request with a MAC AVP is sent. When the > PaC does not > > >>> support the MAC algorithm specified in the PANA-Bind-Request > > >>> message, it MUST silently discard the message. The > PAA MUST NOT > > >>> change the MAC algorithm throughout the continuation > of the PANA > > >>> session." > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Yoshihiro Ohba > > >>> > > >>> _______________________________________________ > > >>> Pana mailing list > > >>> Pana@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/pana > > >>> > > >> > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 20:01:51 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27063 for ; Mon, 26 Jan 2004 20:01:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHbS-0000SZ-DL; Mon, 26 Jan 2004 20:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al3wE-0000eH-Qv for pana@optimus.ietf.org; Mon, 26 Jan 2004 05:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29447 for ; Mon, 26 Jan 2004 05:25:47 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al3wB-0004TD-00 for pana@ietf.org; Mon, 26 Jan 2004 05:25:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al3vF-0004RC-00 for pana@ietf.org; Mon, 26 Jan 2004 05:24:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Al3uL-0004OS-00 for pana@ietf.org; Mon, 26 Jan 2004 05:23:53 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QANsY16384 for ; Mon, 26 Jan 2004 12:23:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 12:23:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 12:23:53 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 12:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Mon, 26 Jan 2004 12:23:51 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPhDmVDaX4j+76fR9SmC9uQXJk6HQC3i9Tg To: Cc: X-OriginalArrivalTime: 26 Jan 2004 10:23:52.0619 (UTC) FILETIME=[7EDA1FB0:01C3E3F6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok. In EAP state machine the AAA timeout results as a timeout_failure. If PBR is used, the result-code AVP should clarify this. I coulnd't find any directly suitable result-code from rfc3588, though. One that is near could be this one: DIAMETER_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. => PANA_UNABLE_TO_COMPLY 5012 This could then happen in any stage in which the EAP protocol is involved. - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 22 January, 2004 19:18 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > I thought that PANA-Error message is used for errors occured within > PANA. But in this case, the error is an EAP authentication failure > and I think it should be carried by PANA authentication > success/failure message (i.e., PBR). > > (There is another problem with using PANA-Error for this case: > Which AVP is considered invalid and carried in Failed-AVP?) > > Yoshihiro Ohba > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > Dan.Forsberg@nokia.com wrote: > > I guess an error should be sent instead then, not the PBR msg. > > - Dan > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > Behalf Of ext Yoshihiro Ohba > > > Sent: 17 January, 2004 02:44 > > > To: pana@ietf.org > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > > PANA-Bind-Request. However, it is possible that EAP conversation > > > fails without generating a EAP-Success or EAP-Failure message, > > > specifically when a AAA timeout occurs (please see EAP Full > > > Authenticator State Machine diagram in the EAP state > machines draft, > > > pdf version). > > > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > > > Yoshihiro Ohba > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 20:03:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27242 for ; Mon, 26 Jan 2004 20:03:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdF-0001fE-LU; Mon, 26 Jan 2004 20:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al72t-0003qg-EW for pana@optimus.ietf.org; Mon, 26 Jan 2004 08:44:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05887 for ; Mon, 26 Jan 2004 08:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al72s-0006gS-00 for pana@ietf.org; Mon, 26 Jan 2004 08:44:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al71x-0006fI-00 for pana@ietf.org; Mon, 26 Jan 2004 08:43:58 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1Al71M-0006cF-00 for pana@ietf.org; Mon, 26 Jan 2004 08:43:20 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 3B966359AA for ; Mon, 26 Jan 2004 14:21:14 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 273F43F405 for ; Mon, 26 Jan 2004 14:21:14 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012614211322767 for ; Mon, 26 Jan 2004 14:21:13 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id DD64E3F405 for ; Mon, 26 Jan 2004 14:21:13 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Al6dw-000FcX-W3 for ; Mon, 26 Jan 2004 14:19:08 +0100 Date: Mon, 26 Jan 2004 14:19:08 +0100 From: Julien Bournelle To: pana@ietf.org Subject: Re: [Pana] comments on pana-03a Message-ID: <20040126131908.GH59634@ipv6-5.int-evry.fr> References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040123163713.GQ26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi, On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > not set the S-FLag ? > > When PaC does not set the S-fLag, only one EAP authentication occurs. > I will add this explicit text. ok, but in this case, which EAP authentication occurs ? (ISP ?) > > -3- Correct me if I'm wrong but I guess the draft CMS Application > > Diameter is no longer supported by AAA wg > > and > > draft-aboba-pppext-key-problem-07 is now > > draft-ietf-eap-keying-01.txt > > That is true. To deal with the CMS issue, how about removing the > following sentence in item c) of Section 11? > > "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key > is securely carried (i.e. CMS protected) between AAA servers. " > > I will also update the reference to the eap-keying draft. ok > > -4- The PAA can indicate that IPsec is supported by the Protection > > Capability AVP sent in the PANA-Bind-Request. > > As the pac can not indicate if it support it, the PAA is going to > > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > > As such, EP will set up its SPD and will > > accept only ipsec traffic. > > > > SO finally, when PAA sets the protection capability with IPsec protection > > it implicitely requires that pac MUST support IPsec to access network. > > > > I wonder if it is what we want. > > That is what we want. Protection capability is non-negotiable. In > addition, the PaC that is incapable of IPsec should not return the > PANA-Bind-Answer in this case. Instead, it should return an > unprotected PANA-Error message with an appropriate Result-Code, and > the PAA should treat the Error as an informational message and should > neither enable IPsec nor immediately delete the session for the PaC. > Instead, the PAA should wait for the authentication to timeout or for > the number of retransmission to reach the maximum value. > > I think we might need to define a new Result-Code to explicit support > the above case, such as: > > " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 > > Error code from PaC to PAA. This error is returned when the PaC > receives a PANA-Bind-Request is received with an > Protection-Capability AVP and a valid MAC AVP but does not > support the protection capability specified in the > Protection-Capability AVP." > > What do you think? I think that we need this error message. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 20:23:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28556 for ; Mon, 26 Jan 2004 20:23:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHwu-0003UV-SY for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1NSJ7013415 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHwu-0003UI-Ow for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:23:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28355 for ; Mon, 26 Jan 2004 20:23:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHws-0002OR-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:23:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHrK-00012n-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:17:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlHq1-0000uf-01 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlHhB-0007gu-75 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:07:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHdF-0001fE-LU; Mon, 26 Jan 2004 20:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al72t-0003qg-EW for pana@optimus.ietf.org; Mon, 26 Jan 2004 08:44:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05887 for ; Mon, 26 Jan 2004 08:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al72s-0006gS-00 for pana@ietf.org; Mon, 26 Jan 2004 08:44:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al71x-0006fI-00 for pana@ietf.org; Mon, 26 Jan 2004 08:43:58 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1Al71M-0006cF-00 for pana@ietf.org; Mon, 26 Jan 2004 08:43:20 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 3B966359AA for ; Mon, 26 Jan 2004 14:21:14 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 273F43F405 for ; Mon, 26 Jan 2004 14:21:14 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2004012614211322767 for ; Mon, 26 Jan 2004 14:21:13 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id DD64E3F405 for ; Mon, 26 Jan 2004 14:21:13 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Al6dw-000FcX-W3 for ; Mon, 26 Jan 2004 14:19:08 +0100 Date: Mon, 26 Jan 2004 14:19:08 +0100 From: Julien Bournelle To: pana@ietf.org Subject: Re: [Pana] comments on pana-03a Message-ID: <20040126131908.GH59634@ipv6-5.int-evry.fr> References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040123163713.GQ26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > not set the S-FLag ? > > When PaC does not set the S-fLag, only one EAP authentication occurs. > I will add this explicit text. ok, but in this case, which EAP authentication occurs ? (ISP ?) > > -3- Correct me if I'm wrong but I guess the draft CMS Application > > Diameter is no longer supported by AAA wg > > and > > draft-aboba-pppext-key-problem-07 is now > > draft-ietf-eap-keying-01.txt > > That is true. To deal with the CMS issue, how about removing the > following sentence in item c) of Section 11? > > "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key > is securely carried (i.e. CMS protected) between AAA servers. " > > I will also update the reference to the eap-keying draft. ok > > -4- The PAA can indicate that IPsec is supported by the Protection > > Capability AVP sent in the PANA-Bind-Request. > > As the pac can not indicate if it support it, the PAA is going to > > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > > As such, EP will set up its SPD and will > > accept only ipsec traffic. > > > > SO finally, when PAA sets the protection capability with IPsec protection > > it implicitely requires that pac MUST support IPsec to access network. > > > > I wonder if it is what we want. > > That is what we want. Protection capability is non-negotiable. In > addition, the PaC that is incapable of IPsec should not return the > PANA-Bind-Answer in this case. Instead, it should return an > unprotected PANA-Error message with an appropriate Result-Code, and > the PAA should treat the Error as an informational message and should > neither enable IPsec nor immediately delete the session for the PaC. > Instead, the PAA should wait for the authentication to timeout or for > the number of retransmission to reach the maximum value. > > I think we might need to define a new Result-Code to explicit support > the above case, such as: > > " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 > > Error code from PaC to PAA. This error is returned when the PaC > receives a PANA-Bind-Request is received with an > Protection-Capability AVP and a valid MAC AVP but does not > support the protection capability specified in the > Protection-Capability AVP." > > What do you think? I think that we need this error message. -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 20:24:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28796 for ; Mon, 26 Jan 2004 20:24:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHxL-0003ZT-TV for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1NtRt013717 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:23:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHxL-0003Z9-L6 for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28527 for ; Mon, 26 Jan 2004 20:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHxJ-0002WH-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:23:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHs1-0001B1-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:18:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlHq6-0000uf-01 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:16:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlHew-0007VY-SF for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:04:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHbS-0000SZ-DL; Mon, 26 Jan 2004 20:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al3wE-0000eH-Qv for pana@optimus.ietf.org; Mon, 26 Jan 2004 05:25:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29447 for ; Mon, 26 Jan 2004 05:25:47 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al3wB-0004TD-00 for pana@ietf.org; Mon, 26 Jan 2004 05:25:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al3vF-0004RC-00 for pana@ietf.org; Mon, 26 Jan 2004 05:24:50 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Al3uL-0004OS-00 for pana@ietf.org; Mon, 26 Jan 2004 05:23:53 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QANsY16384 for ; Mon, 26 Jan 2004 12:23:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 12:23:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 12:23:53 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 12:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Mon, 26 Jan 2004 12:23:51 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPhDmVDaX4j+76fR9SmC9uQXJk6HQC3i9Tg To: Cc: X-OriginalArrivalTime: 26 Jan 2004 10:23:52.0619 (UTC) FILETIME=[7EDA1FB0:01C3E3F6] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ok. In EAP state machine the AAA timeout results as a timeout_failure. If PBR is used, the result-code AVP should clarify this. I coulnd't find any directly suitable result-code from rfc3588, though. One that is near could be this one: DIAMETER_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. => PANA_UNABLE_TO_COMPLY 5012 This could then happen in any stage in which the EAP protocol is involved. - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 22 January, 2004 19:18 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > I thought that PANA-Error message is used for errors occured within > PANA. But in this case, the error is an EAP authentication failure > and I think it should be carried by PANA authentication > success/failure message (i.e., PBR). > > (There is another problem with using PANA-Error for this case: > Which AVP is considered invalid and carried in Failed-AVP?) > > Yoshihiro Ohba > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > Dan.Forsberg@nokia.com wrote: > > I guess an error should be sent instead then, not the PBR msg. > > - Dan > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > Behalf Of ext Yoshihiro Ohba > > > Sent: 17 January, 2004 02:44 > > > To: pana@ietf.org > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > > PANA-Bind-Request. However, it is possible that EAP conversation > > > fails without generating a EAP-Success or EAP-Failure message, > > > specifically when a AAA timeout occurs (please see EAP Full > > > Authenticator State Machine diagram in the EAP state > machines draft, > > > pdf version). > > > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > > > Yoshihiro Ohba > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 20:28:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00009 for ; Mon, 26 Jan 2004 20:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI1L-0004Tc-CB; Mon, 26 Jan 2004 20:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI0n-0004QM-7k for pana@optimus.ietf.org; Mon, 26 Jan 2004 20:27:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29864 for ; Mon, 26 Jan 2004 20:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI0l-0003VI-00 for pana@ietf.org; Mon, 26 Jan 2004 20:27:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHyW-0002sU-00 for pana@ietf.org; Mon, 26 Jan 2004 20:25:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlHtm-0001a0-00 for pana@ietf.org; Mon, 26 Jan 2004 20:20:15 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0R1KCN9000232; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0R1KC5S006801; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA06798 ; Tue, 27 Jan 2004 10:20:12 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA00622; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA25213; Tue, 27 Jan 2004 10:20:11 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0R1KA0j029331; Tue, 27 Jan 2004 10:20:10 +0900 (JST) Received: from steelhead ([159.119.168.67]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS400MB3JPKMF@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 10:20:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlHsT-0000s8-00; Mon, 26 Jan 2004 17:18:53 -0800 Date: Mon, 26 Jan 2004 17:18:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040126131908.GH59634@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040127011853.GJ29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Jan 26, 2004 at 02:19:08PM +0100, Julien Bournelle wrote: > Hi, > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > not set the S-FLag ? > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > I will add this explicit text. > > ok, but in this case, which EAP authentication occurs ? (ISP ?) I think in this case there is no distinction between NAP and ISP authentication (but the PaC can still declare its desire to use specific ISP). Yoshihiro Ohba > > > > -3- Correct me if I'm wrong but I guess the draft CMS Application > > > Diameter is no longer supported by AAA wg > > > and > > > draft-aboba-pppext-key-problem-07 is now > > > draft-ietf-eap-keying-01.txt > > > > That is true. To deal with the CMS issue, how about removing the > > following sentence in item c) of Section 11? > > > > "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key > > is securely carried (i.e. CMS protected) between AAA servers. " > > > > I will also update the reference to the eap-keying draft. > > ok > > > > -4- The PAA can indicate that IPsec is supported by the Protection > > > Capability AVP sent in the PANA-Bind-Request. > > > As the pac can not indicate if it support it, the PAA is going to > > > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > > > As such, EP will set up its SPD and will > > > accept only ipsec traffic. > > > > > > SO finally, when PAA sets the protection capability with IPsec protection > > > it implicitely requires that pac MUST support IPsec to access network. > > > > > > I wonder if it is what we want. > > > > That is what we want. Protection capability is non-negotiable. In > > addition, the PaC that is incapable of IPsec should not return the > > PANA-Bind-Answer in this case. Instead, it should return an > > unprotected PANA-Error message with an appropriate Result-Code, and > > the PAA should treat the Error as an informational message and should > > neither enable IPsec nor immediately delete the session for the PaC. > > Instead, the PAA should wait for the authentication to timeout or for > > the number of retransmission to reach the maximum value. > > > > I think we might need to define a new Result-Code to explicit support > > the above case, such as: > > > > " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 > > > > Error code from PaC to PAA. This error is returned when the PaC > > receives a PANA-Bind-Request is received with an > > Protection-Capability AVP and a valid MAC AVP but does not > > support the protection capability specified in the > > Protection-Capability AVP." > > > > What do you think? > > I think that we need this error message. > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 20:29:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00135 for ; Mon, 26 Jan 2004 20:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI2G-0004YO-Fd; Mon, 26 Jan 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI20-0004Xr-Py for pana@optimus.ietf.org; Mon, 26 Jan 2004 20:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00043 for ; Mon, 26 Jan 2004 20:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI1y-0003hS-00 for pana@ietf.org; Mon, 26 Jan 2004 20:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlI19-0003ZA-00 for pana@ietf.org; Mon, 26 Jan 2004 20:27:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlHzd-0003Ak-00 for pana@ietf.org; Mon, 26 Jan 2004 20:26:17 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0R1QAN9005989; Tue, 27 Jan 2004 10:26:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0R1Q7PG016880; Tue, 27 Jan 2004 10:26:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA16872 ; Tue, 27 Jan 2004 10:26:07 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA07547; Tue, 27 Jan 2004 10:26:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA23013; Tue, 27 Jan 2004 10:26:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0R1Q10j003278; Tue, 27 Jan 2004 10:26:02 +0900 (JST) Received: from steelhead ([159.119.168.67]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS400MU7JZAMF@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 10:26:00 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlHxh-0000tV-00; Mon, 26 Jan 2004 17:24:17 -0800 Date: Mon, 26 Jan 2004 17:24:17 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 40 (proposed text) In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040127012417.GK29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040124034310.GZ26285@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , As long as PAA maintains uniqueness on the key-id within the PANA session, any assignment method should be ok, including monotically increasing numbers and random value. (but monotically increasing numbers is much easier to maintain.) Yoshihiro Ohba On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > Any considerations regarding whether the key ID should be monotonically > increasing or just a random value? > > Alper > > > > Here is a proposed text for issue 40. > > (Sorry if I had already sent this.) > > > > > > - Add the following item in section 4.1.1: > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > - In section 4.1.5, Change: > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a Master Session Key (MSK) > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > authentication fails or no MSK is produced by any EAP authentication > > method. In the case where two EAP authentications are performed in a > > sequence in a single PANA authentication, it is possible that two > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > MSK derived from the first EAP authentication. When a new MSK is > > derived as a result of EAP-based re-authentication, any key derived > > from the old MSK MUST be updated to a new one that is derived from > > the new MSK." > > > > to: > > > > A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a Master Session Key > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > PANA authentication fails or no MSK is produced by any EAP > > authentication method. In the case where two EAP authentications > > are performed in a sequence in a single PANA authentication, it is > > possible that two MSKs are derived. If this happens, the PANA SA > > MUST be bound to the MSK derived from the first EAP authentication. > > When a new MSK is derived as a result of EAP-based > > re-authentication, any key derived from the old MSK MUST be updated > > to a new one that is derived from the new MSK. In order to > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > end of the authentication phase which resulted in deriving a new > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > that uniquely identifies the MSK within the PANA session. The > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > identifier carried in the request. PANA-Bind-Request and > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > AVP whose value is computed by using the new MSK." > > > > > > - In section 4.1.5, change: > > > > > > " * PANA SA attributes: > > > > + MSK > > > > + PANA_MAC_Key" > > > > > > to: > > > > " * PANA SA attributes: > > > > + MSK > > > > + MSK identifier > > > > + PANA_MAC_Key" > > > > > > - Add the following section: > > > > "9.4.16 Key-Id AVP > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > be unique within the PANA session." > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > contain optional Key-Id AVP. > > > > > > > > Comments? > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 20:30:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00300 for ; Mon, 26 Jan 2004 20:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI3H-0004eB-8Y for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1U3EW017851 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI3F-0004dX-8D for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00244 for ; Mon, 26 Jan 2004 20:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI3D-0003tv-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlI2L-0003le-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:29:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlI1W-0003bS-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI1L-0004Tc-CB; Mon, 26 Jan 2004 20:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI0n-0004QM-7k for pana@optimus.ietf.org; Mon, 26 Jan 2004 20:27:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29864 for ; Mon, 26 Jan 2004 20:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI0l-0003VI-00 for pana@ietf.org; Mon, 26 Jan 2004 20:27:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHyW-0002sU-00 for pana@ietf.org; Mon, 26 Jan 2004 20:25:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlHtm-0001a0-00 for pana@ietf.org; Mon, 26 Jan 2004 20:20:15 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0R1KCN9000232; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0R1KC5S006801; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA06798 ; Tue, 27 Jan 2004 10:20:12 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA00622; Tue, 27 Jan 2004 10:20:12 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA25213; Tue, 27 Jan 2004 10:20:11 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0R1KA0j029331; Tue, 27 Jan 2004 10:20:10 +0900 (JST) Received: from steelhead ([159.119.168.67]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS400MB3JPKMF@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 10:20:09 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlHsT-0000s8-00; Mon, 26 Jan 2004 17:18:53 -0800 Date: Mon, 26 Jan 2004 17:18:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040126131908.GH59634@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: pana@ietf.org Message-id: <20040127011853.GJ29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Jan 26, 2004 at 02:19:08PM +0100, Julien Bournelle wrote: > Hi, > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > not set the S-FLag ? > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > I will add this explicit text. > > ok, but in this case, which EAP authentication occurs ? (ISP ?) I think in this case there is no distinction between NAP and ISP authentication (but the PaC can still declare its desire to use specific ISP). Yoshihiro Ohba > > > > -3- Correct me if I'm wrong but I guess the draft CMS Application > > > Diameter is no longer supported by AAA wg > > > and > > > draft-aboba-pppext-key-problem-07 is now > > > draft-ietf-eap-keying-01.txt > > > > That is true. To deal with the CMS issue, how about removing the > > following sentence in item c) of Section 11? > > > > "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key > > is securely carried (i.e. CMS protected) between AAA servers. " > > > > I will also update the reference to the eap-keying draft. > > ok > > > > -4- The PAA can indicate that IPsec is supported by the Protection > > > Capability AVP sent in the PANA-Bind-Request. > > > As the pac can not indicate if it support it, the PAA is going to > > > configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). > > > As such, EP will set up its SPD and will > > > accept only ipsec traffic. > > > > > > SO finally, when PAA sets the protection capability with IPsec protection > > > it implicitely requires that pac MUST support IPsec to access network. > > > > > > I wonder if it is what we want. > > > > That is what we want. Protection capability is non-negotiable. In > > addition, the PaC that is incapable of IPsec should not return the > > PANA-Bind-Answer in this case. Instead, it should return an > > unprotected PANA-Error message with an appropriate Result-Code, and > > the PAA should treat the Error as an informational message and should > > neither enable IPsec nor immediately delete the session for the PaC. > > Instead, the PAA should wait for the authentication to timeout or for > > the number of retransmission to reach the maximum value. > > > > I think we might need to define a new Result-Code to explicit support > > the above case, such as: > > > > " PANA_PROTECTION_CAPABILITY_UNSUPPORTED 5016 > > > > Error code from PaC to PAA. This error is returned when the PaC > > receives a PANA-Bind-Request is received with an > > Protection-Capability AVP and a valid MAC AVP but does not > > support the protection capability specified in the > > Protection-Capability AVP." > > > > What do you think? > > I think that we need this error message. > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 20:31:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00377 for ; Mon, 26 Jan 2004 20:31:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI3z-0004gL-4l for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:30:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R1Ulve017991 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 20:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI3z-0004g6-0k for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 20:30:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00352 for ; Mon, 26 Jan 2004 20:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI3w-0003ze-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:30:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlI34-0003sg-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:29:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlI2E-0003kU-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 20:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI2G-0004YO-Fd; Mon, 26 Jan 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlI20-0004Xr-Py for pana@optimus.ietf.org; Mon, 26 Jan 2004 20:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00043 for ; Mon, 26 Jan 2004 20:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlI1y-0003hS-00 for pana@ietf.org; Mon, 26 Jan 2004 20:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlI19-0003ZA-00 for pana@ietf.org; Mon, 26 Jan 2004 20:27:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlHzd-0003Ak-00 for pana@ietf.org; Mon, 26 Jan 2004 20:26:17 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0R1QAN9005989; Tue, 27 Jan 2004 10:26:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0R1Q7PG016880; Tue, 27 Jan 2004 10:26:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA16872 ; Tue, 27 Jan 2004 10:26:07 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA07547; Tue, 27 Jan 2004 10:26:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA23013; Tue, 27 Jan 2004 10:26:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0R1Q10j003278; Tue, 27 Jan 2004 10:26:02 +0900 (JST) Received: from steelhead ([159.119.168.67]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS400MU7JZAMF@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 10:26:00 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlHxh-0000tV-00; Mon, 26 Jan 2004 17:24:17 -0800 Date: Mon, 26 Jan 2004 17:24:17 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 40 (proposed text) In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040127012417.GK29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040124034310.GZ26285@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 As long as PAA maintains uniqueness on the key-id within the PANA session, any assignment method should be ok, including monotically increasing numbers and random value. (but monotically increasing numbers is much easier to maintain.) Yoshihiro Ohba On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > Any considerations regarding whether the key ID should be monotonically > increasing or just a random value? > > Alper > > > > Here is a proposed text for issue 40. > > (Sorry if I had already sent this.) > > > > > > - Add the following item in section 4.1.1: > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > - In section 4.1.5, Change: > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a Master Session Key (MSK) > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > authentication fails or no MSK is produced by any EAP authentication > > method. In the case where two EAP authentications are performed in a > > sequence in a single PANA authentication, it is possible that two > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > MSK derived from the first EAP authentication. When a new MSK is > > derived as a result of EAP-based re-authentication, any key derived > > from the old MSK MUST be updated to a new one that is derived from > > the new MSK." > > > > to: > > > > A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a Master Session Key > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > PANA authentication fails or no MSK is produced by any EAP > > authentication method. In the case where two EAP authentications > > are performed in a sequence in a single PANA authentication, it is > > possible that two MSKs are derived. If this happens, the PANA SA > > MUST be bound to the MSK derived from the first EAP authentication. > > When a new MSK is derived as a result of EAP-based > > re-authentication, any key derived from the old MSK MUST be updated > > to a new one that is derived from the new MSK. In order to > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > end of the authentication phase which resulted in deriving a new > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > that uniquely identifies the MSK within the PANA session. The > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > identifier carried in the request. PANA-Bind-Request and > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > AVP whose value is computed by using the new MSK." > > > > > > - In section 4.1.5, change: > > > > > > " * PANA SA attributes: > > > > + MSK > > > > + PANA_MAC_Key" > > > > > > to: > > > > " * PANA SA attributes: > > > > + MSK > > > > + MSK identifier > > > > + PANA_MAC_Key" > > > > > > - Add the following section: > > > > "9.4.16 Key-Id AVP > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > be unique within the PANA session." > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > contain optional Key-Id AVP. > > > > > > > > Comments? > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Jan 26 22:00:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03243 for ; Mon, 26 Jan 2004 22:00:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJSN-0000oP-HC; Mon, 26 Jan 2004 22:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJRj-0000kS-3x for pana@optimus.ietf.org; Mon, 26 Jan 2004 21:59:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03223 for ; Mon, 26 Jan 2004 21:59:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlJRg-0000gc-00 for pana@ietf.org; Mon, 26 Jan 2004 21:59:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlJQk-0000fQ-00 for pana@ietf.org; Mon, 26 Jan 2004 21:58:23 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AlJQR-0000dz-00 for pana@ietf.org; Mon, 26 Jan 2004 21:58:03 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 27 Jan 2004 02:58:01 -0000 Message-ID: <01dd01c3e481$5f4494b0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> Subject: Re: [Pana] issue 40 (proposed text) Date: Mon, 26 Jan 2004 18:57:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > As long as PAA maintains uniqueness on the key-id within the PANA > session, any assignment method should be ok, including monotically > increasing numbers and random value. (but monotically increasing > numbers is much easier to maintain.) > Monotonically increasing numbers sounds good to me. -mohan > Yoshihiro Ohba > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > Any considerations regarding whether the key ID should be monotonically > > increasing or just a random value? > > > > Alper > > > > > > > Here is a proposed text for issue 40. > > > (Sorry if I had already sent this.) > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > - In section 4.1.5, Change: > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > authentication fails or no MSK is produced by any EAP authentication > > > method. In the case where two EAP authentications are performed in a > > > sequence in a single PANA authentication, it is possible that two > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > MSK derived from the first EAP authentication. When a new MSK is > > > derived as a result of EAP-based re-authentication, any key derived > > > from the old MSK MUST be updated to a new one that is derived from > > > the new MSK." > > > > > > to: > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > authentication succeeds with a creation of a Master Session Key > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > PANA authentication fails or no MSK is produced by any EAP > > > authentication method. In the case where two EAP authentications > > > are performed in a sequence in a single PANA authentication, it is > > > possible that two MSKs are derived. If this happens, the PANA SA > > > MUST be bound to the MSK derived from the first EAP authentication. > > > When a new MSK is derived as a result of EAP-based > > > re-authentication, any key derived from the old MSK MUST be updated > > > to a new one that is derived from the new MSK. In order to > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > end of the authentication phase which resulted in deriving a new > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > that uniquely identifies the MSK within the PANA session. The > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > identifier carried in the request. PANA-Bind-Request and > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > AVP whose value is computed by using the new MSK." > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > " * PANA SA attributes: > > > > > > + MSK > > > > > > + PANA_MAC_Key" > > > > > > > > > to: > > > > > > " * PANA SA attributes: > > > > > > + MSK > > > > > > + MSK identifier > > > > > > + PANA_MAC_Key" > > > > > > > > > - Add the following section: > > > > > > "9.4.16 Key-Id AVP > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > be unique within the PANA session." > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > contain optional Key-Id AVP. > > > > > > > > > > > > Comments? > > > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Jan 26 22:03:54 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03386 for ; Mon, 26 Jan 2004 22:03:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJVe-0000vP-Q1 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 22:03:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R33QY3003549 for pana-archive@odin.ietf.org; Mon, 26 Jan 2004 22:03:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJVe-0000vA-Ld for pana-web-archive@optimus.ietf.org; Mon, 26 Jan 2004 22:03:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03287 for ; Mon, 26 Jan 2004 22:03:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlJVb-0000tX-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 22:03:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlJUh-0000nP-00 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 22:02:28 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AlJTi-0000k6-03 for pana-web-archive@ietf.org; Mon, 26 Jan 2004 22:01:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AlJSb-0006hz-0j for pana-web-archive@ietf.org; Mon, 26 Jan 2004 22:00:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJSN-0000oP-HC; Mon, 26 Jan 2004 22:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlJRj-0000kS-3x for pana@optimus.ietf.org; Mon, 26 Jan 2004 21:59:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03223 for ; Mon, 26 Jan 2004 21:59:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlJRg-0000gc-00 for pana@ietf.org; Mon, 26 Jan 2004 21:59:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlJQk-0000fQ-00 for pana@ietf.org; Mon, 26 Jan 2004 21:58:23 -0500 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1AlJQR-0000dz-00 for pana@ietf.org; Mon, 26 Jan 2004 21:58:03 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 27 Jan 2004 02:58:01 -0000 Message-ID: <01dd01c3e481$5f4494b0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> Subject: Re: [Pana] issue 40 (proposed text) Date: Mon, 26 Jan 2004 18:57:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > As long as PAA maintains uniqueness on the key-id within the PANA > session, any assignment method should be ok, including monotically > increasing numbers and random value. (but monotically increasing > numbers is much easier to maintain.) > Monotonically increasing numbers sounds good to me. -mohan > Yoshihiro Ohba > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > Any considerations regarding whether the key ID should be monotonically > > increasing or just a random value? > > > > Alper > > > > > > > Here is a proposed text for issue 40. > > > (Sorry if I had already sent this.) > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > - In section 4.1.5, Change: > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > authentication fails or no MSK is produced by any EAP authentication > > > method. In the case where two EAP authentications are performed in a > > > sequence in a single PANA authentication, it is possible that two > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > MSK derived from the first EAP authentication. When a new MSK is > > > derived as a result of EAP-based re-authentication, any key derived > > > from the old MSK MUST be updated to a new one that is derived from > > > the new MSK." > > > > > > to: > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > authentication succeeds with a creation of a Master Session Key > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > PANA authentication fails or no MSK is produced by any EAP > > > authentication method. In the case where two EAP authentications > > > are performed in a sequence in a single PANA authentication, it is > > > possible that two MSKs are derived. If this happens, the PANA SA > > > MUST be bound to the MSK derived from the first EAP authentication. > > > When a new MSK is derived as a result of EAP-based > > > re-authentication, any key derived from the old MSK MUST be updated > > > to a new one that is derived from the new MSK. In order to > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > end of the authentication phase which resulted in deriving a new > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > that uniquely identifies the MSK within the PANA session. The > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > identifier carried in the request. PANA-Bind-Request and > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > AVP whose value is computed by using the new MSK." > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > " * PANA SA attributes: > > > > > > + MSK > > > > > > + PANA_MAC_Key" > > > > > > > > > to: > > > > > > " * PANA SA attributes: > > > > > > + MSK > > > > > > + MSK identifier > > > > > > + PANA_MAC_Key" > > > > > > > > > - Add the following section: > > > > > > "9.4.16 Key-Id AVP > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > be unique within the PANA session." > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > contain optional Key-Id AVP. > > > > > > > > > > > > Comments? > > > > > > Yoshihiro Ohba > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 02:30:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22919 for ; Tue, 27 Jan 2004 02:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNfe-0004ag-VS; Tue, 27 Jan 2004 02:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNfC-0004Yt-GK for pana@optimus.ietf.org; Tue, 27 Jan 2004 02:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22880 for ; Tue, 27 Jan 2004 02:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlNf8-0004jF-00 for pana@ietf.org; Tue, 27 Jan 2004 02:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlNeB-0004hP-00 for pana@ietf.org; Tue, 27 Jan 2004 02:28:31 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AlNdy-0004fk-00 for pana@ietf.org; Tue, 27 Jan 2004 02:28:18 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i0R7SIA19914; Tue, 27 Jan 2004 08:28:18 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i0R7SIZ13611; Tue, 27 Jan 2004 08:28:18 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 08:27:46 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC05F5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Alper Yegin'" Cc: pana@ietf.org Subject: RE: [Pana] EAP keying issues and PANA Date: Tue, 27 Jan 2004 08:27:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , hi alper, > >> When the PANA session expires, if the peers are interested in > >> continuing the "access", another run of EAP is executed > >> inside PANA. This should create a new EAP SA, hence a new PANA SA. > > > > does this lead to a new session identifier? > > I think I should have said "before the PANA session expires", > and in that > case I'd answer your question as "the same session identifier > is preserved". > It's like extending the lifetime of the ongoing session. If > the session > expires on the PAA, I think we can consider it's gone and a > new session > identifier will be allocated. in this case you might want to have two sas concurrently to safely switch from one sa to the other. to avoid some error cases where the pac or the paa end up having no valid security association you need to distinguish these two somehow. what do you think? > > Alper > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 02:32:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22970 for ; Tue, 27 Jan 2004 02:32:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNhC-0004j5-84 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 02:31:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R7VcMd018166 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 02:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNhB-0004ie-Rb for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 02:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22964 for ; Tue, 27 Jan 2004 02:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlNh8-0004wO-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 02:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlNgA-0004uB-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 02:30:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlNfg-0004py-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 02:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNfe-0004ag-VS; Tue, 27 Jan 2004 02:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlNfC-0004Yt-GK for pana@optimus.ietf.org; Tue, 27 Jan 2004 02:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22880 for ; Tue, 27 Jan 2004 02:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlNf8-0004jF-00 for pana@ietf.org; Tue, 27 Jan 2004 02:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlNeB-0004hP-00 for pana@ietf.org; Tue, 27 Jan 2004 02:28:31 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AlNdy-0004fk-00 for pana@ietf.org; Tue, 27 Jan 2004 02:28:18 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i0R7SIA19914; Tue, 27 Jan 2004 08:28:18 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i0R7SIZ13611; Tue, 27 Jan 2004 08:28:18 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 08:27:46 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC05F5@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Alper Yegin'" Cc: pana@ietf.org Subject: RE: [Pana] EAP keying issues and PANA Date: Tue, 27 Jan 2004 08:27:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi alper, > >> When the PANA session expires, if the peers are interested in > >> continuing the "access", another run of EAP is executed > >> inside PANA. This should create a new EAP SA, hence a new PANA SA. > > > > does this lead to a new session identifier? > > I think I should have said "before the PANA session expires", > and in that > case I'd answer your question as "the same session identifier > is preserved". > It's like extending the lifetime of the ongoing session. If > the session > expires on the PAA, I think we can consider it's gone and a > new session > identifier will be allocated. in this case you might want to have two sas concurrently to safely switch from one sa to the other. to avoid some error cases where the pac or the paa end up having no valid security association you need to distinguish these two somehow. what do you think? > > Alper > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 11:57:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13198 for ; Tue, 27 Jan 2004 11:57:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWL-0001iq-EL; Tue, 27 Jan 2004 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWD-0001i9-D6 for pana@optimus.ietf.org; Tue, 27 Jan 2004 11:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13183 for ; Tue, 27 Jan 2004 11:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWWB-0006Nx-00 for pana@ietf.org; Tue, 27 Jan 2004 11:56:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWVH-0006LF-00 for pana@ietf.org; Tue, 27 Jan 2004 11:55:56 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlWUb-0006IJ-00 for pana@ietf.org; Tue, 27 Jan 2004 11:55:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RGt6N9011400; Wed, 28 Jan 2004 01:55:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RGt6er027551; Wed, 28 Jan 2004 01:55:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27550 ; Wed, 28 Jan 2004 01:55:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA11585; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA08573; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RGt40j019041; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5001QFQZQ1N@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 01:55:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlWTY-0001mp-00; Tue, 27 Jan 2004 08:54:08 -0800 Date: Tue, 27 Jan 2004 08:54:07 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 40 (proposed text) In-reply-to: <01dd01c3e481$5f4494b0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040127165407.GJ3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> <01dd01c3e481$5f4494b0$c91167c0@adithya> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Then how about adding the following sentence? "Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." We do not have to mandate monotonically increasing numbers, like we do not mandate a particular cookie calculation mothod. Yoshihiro Ohba On Mon, Jan 26, 2004 at 06:57:59PM -0800, Mohan Parthasarathy wrote: > > > > As long as PAA maintains uniqueness on the key-id within the PANA > > session, any assignment method should be ok, including monotically > > increasing numbers and random value. (but monotically increasing > > numbers is much easier to maintain.) > > > Monotonically increasing numbers sounds good to me. > > -mohan > > > Yoshihiro Ohba > > > > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > > > Any considerations regarding whether the key ID should be monotonically > > > increasing or just a random value? > > > > > > Alper > > > > > > > > > > Here is a proposed text for issue 40. > > > > (Sorry if I had already sent this.) > > > > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > > > > - In section 4.1.5, Change: > > > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > > authentication fails or no MSK is produced by any EAP authentication > > > > method. In the case where two EAP authentications are performed in a > > > > sequence in a single PANA authentication, it is possible that two > > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > > MSK derived from the first EAP authentication. When a new MSK is > > > > derived as a result of EAP-based re-authentication, any key derived > > > > from the old MSK MUST be updated to a new one that is derived from > > > > the new MSK." > > > > > > > > to: > > > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > > authentication succeeds with a creation of a Master Session Key > > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > > PANA authentication fails or no MSK is produced by any EAP > > > > authentication method. In the case where two EAP authentications > > > > are performed in a sequence in a single PANA authentication, it is > > > > possible that two MSKs are derived. If this happens, the PANA SA > > > > MUST be bound to the MSK derived from the first EAP authentication. > > > > When a new MSK is derived as a result of EAP-based > > > > re-authentication, any key derived from the old MSK MUST be updated > > > > to a new one that is derived from the new MSK. In order to > > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > > end of the authentication phase which resulted in deriving a new > > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > > that uniquely identifies the MSK within the PANA session. The > > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > > identifier carried in the request. PANA-Bind-Request and > > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > > AVP whose value is computed by using the new MSK." > > > > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > > > > " * PANA SA attributes: > > > > > > > > + MSK > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > to: > > > > > > > > " * PANA SA attributes: > > > > > > > > + MSK > > > > > > > > + MSK identifier > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > - Add the following section: > > > > > > > > "9.4.16 Key-Id AVP > > > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > > be unique within the PANA session." > > > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > > contain optional Key-Id AVP. > > > > > > > > > > > > > > > > Comments? > > > > > > > > Yoshihiro Ohba > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 11:59:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13257 for ; Tue, 27 Jan 2004 11:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWY6-0001qE-Nd for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 11:58:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RGwohM007078 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 11:58:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWY6-0001q5-JK for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 11:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13230 for ; Tue, 27 Jan 2004 11:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWY5-0006UK-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 11:58:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWXA-0006Re-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 11:57:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlWWT-0006Os-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 11:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWL-0001iq-EL; Tue, 27 Jan 2004 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWWD-0001i9-D6 for pana@optimus.ietf.org; Tue, 27 Jan 2004 11:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13183 for ; Tue, 27 Jan 2004 11:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWWB-0006Nx-00 for pana@ietf.org; Tue, 27 Jan 2004 11:56:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWVH-0006LF-00 for pana@ietf.org; Tue, 27 Jan 2004 11:55:56 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlWUb-0006IJ-00 for pana@ietf.org; Tue, 27 Jan 2004 11:55:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RGt6N9011400; Wed, 28 Jan 2004 01:55:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RGt6er027551; Wed, 28 Jan 2004 01:55:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27550 ; Wed, 28 Jan 2004 01:55:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA11585; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA08573; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RGt40j019041; Wed, 28 Jan 2004 01:55:05 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5001QFQZQ1N@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 01:55:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlWTY-0001mp-00; Tue, 27 Jan 2004 08:54:08 -0800 Date: Tue, 27 Jan 2004 08:54:07 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 40 (proposed text) In-reply-to: <01dd01c3e481$5f4494b0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040127165407.GJ3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> <01dd01c3e481$5f4494b0$c91167c0@adithya> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Then how about adding the following sentence? "Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." We do not have to mandate monotonically increasing numbers, like we do not mandate a particular cookie calculation mothod. Yoshihiro Ohba On Mon, Jan 26, 2004 at 06:57:59PM -0800, Mohan Parthasarathy wrote: > > > > As long as PAA maintains uniqueness on the key-id within the PANA > > session, any assignment method should be ok, including monotically > > increasing numbers and random value. (but monotically increasing > > numbers is much easier to maintain.) > > > Monotonically increasing numbers sounds good to me. > > -mohan > > > Yoshihiro Ohba > > > > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > > > Any considerations regarding whether the key ID should be monotonically > > > increasing or just a random value? > > > > > > Alper > > > > > > > > > > Here is a proposed text for issue 40. > > > > (Sorry if I had already sent this.) > > > > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > > > > - In section 4.1.5, Change: > > > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > > authentication fails or no MSK is produced by any EAP authentication > > > > method. In the case where two EAP authentications are performed in a > > > > sequence in a single PANA authentication, it is possible that two > > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > > MSK derived from the first EAP authentication. When a new MSK is > > > > derived as a result of EAP-based re-authentication, any key derived > > > > from the old MSK MUST be updated to a new one that is derived from > > > > the new MSK." > > > > > > > > to: > > > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > > authentication succeeds with a creation of a Master Session Key > > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > > PANA authentication fails or no MSK is produced by any EAP > > > > authentication method. In the case where two EAP authentications > > > > are performed in a sequence in a single PANA authentication, it is > > > > possible that two MSKs are derived. If this happens, the PANA SA > > > > MUST be bound to the MSK derived from the first EAP authentication. > > > > When a new MSK is derived as a result of EAP-based > > > > re-authentication, any key derived from the old MSK MUST be updated > > > > to a new one that is derived from the new MSK. In order to > > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > > end of the authentication phase which resulted in deriving a new > > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > > that uniquely identifies the MSK within the PANA session. The > > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > > identifier carried in the request. PANA-Bind-Request and > > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > > AVP whose value is computed by using the new MSK." > > > > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > > > > " * PANA SA attributes: > > > > > > > > + MSK > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > to: > > > > > > > > " * PANA SA attributes: > > > > > > > > + MSK > > > > > > > > + MSK identifier > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > - Add the following section: > > > > > > > > "9.4.16 Key-Id AVP > > > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > > be unique within the PANA session." > > > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > > contain optional Key-Id AVP. > > > > > > > > > > > > > > > > Comments? > > > > > > > > Yoshihiro Ohba > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 12:21:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14320 for ; Tue, 27 Jan 2004 12:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWtY-0003Ir-65; Tue, 27 Jan 2004 12:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWsb-0003Gb-Fa for pana@optimus.ietf.org; Tue, 27 Jan 2004 12:20:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14298 for ; Tue, 27 Jan 2004 12:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWsZ-0000FQ-00 for pana@ietf.org; Tue, 27 Jan 2004 12:19:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWrx-0000Bn-00 for pana@ietf.org; Tue, 27 Jan 2004 12:19:22 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1AlWrB-00005y-00 for pana@ietf.org; Tue, 27 Jan 2004 12:18:33 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 27 Jan 2004 17:18:32 -0000 Message-ID: <002601c3e4f9$990bc1a0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> <01dd01c3e481$5f4494b0$c91167c0@adithya> <20040127165407.GJ3563@steelhead> Subject: Re: [Pana] issue 40 (proposed text) Date: Tue, 27 Jan 2004 09:18:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sounds good. -mohan ----- Original Message ----- From: "Yoshihiro Ohba" To: "Mohan Parthasarathy" Cc: "Yoshihiro Ohba" ; "Alper Yegin" ; Sent: Tuesday, January 27, 2004 8:54 AM Subject: Re: [Pana] issue 40 (proposed text) > Then how about adding the following sentence? > > "Although the specification does not mandate a particular method for > calculation of Key-Id AVP value, a simple method is to use > monotonically increasing numbers." > > We do not have to mandate monotonically increasing numbers, like > we do not mandate a particular cookie calculation mothod. > > Yoshihiro Ohba > > > On Mon, Jan 26, 2004 at 06:57:59PM -0800, Mohan Parthasarathy wrote: > > > > > > > As long as PAA maintains uniqueness on the key-id within the PANA > > > session, any assignment method should be ok, including monotically > > > increasing numbers and random value. (but monotically increasing > > > numbers is much easier to maintain.) > > > > > Monotonically increasing numbers sounds good to me. > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > > > > > Any considerations regarding whether the key ID should be monotonically > > > > increasing or just a random value? > > > > > > > > Alper > > > > > > > > > > > > > Here is a proposed text for issue 40. > > > > > (Sorry if I had already sent this.) > > > > > > > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > > > > > > > - In section 4.1.5, Change: > > > > > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > > > authentication fails or no MSK is produced by any EAP authentication > > > > > method. In the case where two EAP authentications are performed in a > > > > > sequence in a single PANA authentication, it is possible that two > > > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > > > MSK derived from the first EAP authentication. When a new MSK is > > > > > derived as a result of EAP-based re-authentication, any key derived > > > > > from the old MSK MUST be updated to a new one that is derived from > > > > > the new MSK." > > > > > > > > > > to: > > > > > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > > > authentication succeeds with a creation of a Master Session Key > > > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > > > PANA authentication fails or no MSK is produced by any EAP > > > > > authentication method. In the case where two EAP authentications > > > > > are performed in a sequence in a single PANA authentication, it is > > > > > possible that two MSKs are derived. If this happens, the PANA SA > > > > > MUST be bound to the MSK derived from the first EAP authentication. > > > > > When a new MSK is derived as a result of EAP-based > > > > > re-authentication, any key derived from the old MSK MUST be updated > > > > > to a new one that is derived from the new MSK. In order to > > > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > > > end of the authentication phase which resulted in deriving a new > > > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > > > that uniquely identifies the MSK within the PANA session. The > > > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > > > identifier carried in the request. PANA-Bind-Request and > > > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > > > AVP whose value is computed by using the new MSK." > > > > > > > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > > > > > > > " * PANA SA attributes: > > > > > > > > > > + MSK > > > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > > > > to: > > > > > > > > > > " * PANA SA attributes: > > > > > > > > > > + MSK > > > > > > > > > > + MSK identifier > > > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > > > > - Add the following section: > > > > > > > > > > "9.4.16 Key-Id AVP > > > > > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > > > be unique within the PANA session." > > > > > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > > > contain optional Key-Id AVP. > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 12:23:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14398 for ; Tue, 27 Jan 2004 12:23:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWvL-0003OT-Co for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 12:22:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RHMpBJ013044 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 12:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWvL-0003OJ-5i for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 12:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14379 for ; Tue, 27 Jan 2004 12:22:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWvJ-0000Pl-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:22:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWuQ-0000MD-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:21:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlWta-0000JM-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWtY-0003Ir-65; Tue, 27 Jan 2004 12:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlWsb-0003Gb-Fa for pana@optimus.ietf.org; Tue, 27 Jan 2004 12:20:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14298 for ; Tue, 27 Jan 2004 12:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlWsZ-0000FQ-00 for pana@ietf.org; Tue, 27 Jan 2004 12:19:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlWrx-0000Bn-00 for pana@ietf.org; Tue, 27 Jan 2004 12:19:22 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1AlWrB-00005y-00 for pana@ietf.org; Tue, 27 Jan 2004 12:18:33 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 27 Jan 2004 17:18:32 -0000 Message-ID: <002601c3e4f9$990bc1a0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Alper Yegin" , References: <20040124034310.GZ26285@steelhead> <20040127012417.GK29975@steelhead> <01dd01c3e481$5f4494b0$c91167c0@adithya> <20040127165407.GJ3563@steelhead> Subject: Re: [Pana] issue 40 (proposed text) Date: Tue, 27 Jan 2004 09:18:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sounds good. -mohan ----- Original Message ----- From: "Yoshihiro Ohba" To: "Mohan Parthasarathy" Cc: "Yoshihiro Ohba" ; "Alper Yegin" ; Sent: Tuesday, January 27, 2004 8:54 AM Subject: Re: [Pana] issue 40 (proposed text) > Then how about adding the following sentence? > > "Although the specification does not mandate a particular method for > calculation of Key-Id AVP value, a simple method is to use > monotonically increasing numbers." > > We do not have to mandate monotonically increasing numbers, like > we do not mandate a particular cookie calculation mothod. > > Yoshihiro Ohba > > > On Mon, Jan 26, 2004 at 06:57:59PM -0800, Mohan Parthasarathy wrote: > > > > > > > As long as PAA maintains uniqueness on the key-id within the PANA > > > session, any assignment method should be ok, including monotically > > > increasing numbers and random value. (but monotically increasing > > > numbers is much easier to maintain.) > > > > > Monotonically increasing numbers sounds good to me. > > > > -mohan > > > > > Yoshihiro Ohba > > > > > > > > > On Mon, Jan 26, 2004 at 01:21:55PM -0800, Alper Yegin wrote: > > > > > > > > Any considerations regarding whether the key ID should be monotonically > > > > increasing or just a random value? > > > > > > > > Alper > > > > > > > > > > > > > Here is a proposed text for issue 40. > > > > > (Sorry if I had already sent this.) > > > > > > > > > > > > > > > - Add the following item in section 4.1.1: > > > > > > > > > > "o Key-Id AVP: contains an MSK identifier." > > > > > > > > > > > > > > > - In section 4.1.5, Change: > > > > > > > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > > > > authentication succeeds with a creation of a Master Session Key (MSK) > > > > > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > > > > > authentication fails or no MSK is produced by any EAP authentication > > > > > method. In the case where two EAP authentications are performed in a > > > > > sequence in a single PANA authentication, it is possible that two > > > > > MSKs are derived. If this happens, the PANA SA MUST be bound to the > > > > > MSK derived from the first EAP authentication. When a new MSK is > > > > > derived as a result of EAP-based re-authentication, any key derived > > > > > from the old MSK MUST be updated to a new one that is derived from > > > > > the new MSK." > > > > > > > > > > to: > > > > > > > > > > A PANA SA is created as an attribute of a PANA session when EAP > > > > > authentication succeeds with a creation of a Master Session Key > > > > > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > > > > > PANA authentication fails or no MSK is produced by any EAP > > > > > authentication method. In the case where two EAP authentications > > > > > are performed in a sequence in a single PANA authentication, it is > > > > > possible that two MSKs are derived. If this happens, the PANA SA > > > > > MUST be bound to the MSK derived from the first EAP authentication. > > > > > When a new MSK is derived as a result of EAP-based > > > > > re-authentication, any key derived from the old MSK MUST be updated > > > > > to a new one that is derived from the new MSK. In order to > > > > > distinguish the new MSK from old ones, one Key-Id AVP MUST be > > > > > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > > > > > end of the authentication phase which resulted in deriving a new > > > > > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > > > > > that uniquely identifies the MSK within the PANA session. The > > > > > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > > > > > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > > > > > identifier carried in the request. PANA-Bind-Request and > > > > > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > > > > > AVP whose value is computed by using the new MSK." > > > > > > > > > > > > > > > - In section 4.1.5, change: > > > > > > > > > > > > > > > " * PANA SA attributes: > > > > > > > > > > + MSK > > > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > > > > to: > > > > > > > > > > " * PANA SA attributes: > > > > > > > > > > + MSK > > > > > > > > > > + MSK identifier > > > > > > > > > > + PANA_MAC_Key" > > > > > > > > > > > > > > > - Add the following section: > > > > > > > > > > "9.4.16 Key-Id AVP > > > > > > > > > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > > > > > an MSK identifier. The MSK identifier is assigned by PAA and MUST > > > > > be unique within the PANA session." > > > > > > > > > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > > > > > contain optional Key-Id AVP. > > > > > > > > > > > > > > > > > > > > Comments? > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 12:47:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16138 for ; Tue, 27 Jan 2004 12:47:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXIk-0005W1-5v; Tue, 27 Jan 2004 12:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXIZ-0005VW-Uw for pana@optimus.ietf.org; Tue, 27 Jan 2004 12:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16122 for ; Tue, 27 Jan 2004 12:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlXIY-0002wy-00 for pana@ietf.org; Tue, 27 Jan 2004 12:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlXHb-0002ue-00 for pana@ietf.org; Tue, 27 Jan 2004 12:45:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlXH9-0002sK-00 for pana@ietf.org; Tue, 27 Jan 2004 12:45:23 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RHjMN9024934 for ; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RHjMKl014698 for ; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA14697 ; Wed, 28 Jan 2004 02:45:22 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA27429; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA02447; Wed, 28 Jan 2004 02:45:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RHjK0j020516 for ; Wed, 28 Jan 2004 02:45:21 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5002EXTBJL9@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 28 Jan 2004 02:45:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlXFi-0001vn-00 for ; Tue, 27 Jan 2004 09:43:54 -0800 Date: Tue, 27 Jan 2004 09:43:54 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127174354.GP3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] [: issue 28 (state machine, table available)] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Let me retransmit this message since I have not seen my previous post... Yoshihiro Ohba ----- Forwarded message from ----- To: pana@ietf.org Subject: issue 28 (state machine, table available) Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i PANA state machines in ascii table format is available at: http://www.danforsberg.info:8080/pana-issues/file20/state-machine-01242004.txt (Thanks Dan for putting the file to the URL.) These are changes from the previous version of state machines in graphic images: ------------- o Retransmission behavior is added. o Decisions on whether to include optional AVP is added, based on the static configurations or dynamic conditions. o Detailed conditions are described for NAP/ISP separate authentication. o Variable name SESSION_RESUM is renamed to MOBILITY. o 2ND_EAP variable in PaC state machine is removed. Instead, Result-Code AVP value in PBR is checked. o In PAA state machine, OFFLINE state is devided into OFFLINE and STATEFUL_DISC states in order to distingish stateful discovery and stateless discovery. o "Session Timeout" signal in PAA state machine is replaced with EAP_REAUTH event. o "Timeout" signal in PaC and PAA state machines are replaced with SESS_TIMEOUT event. How it looks like? Comments are appreciated. Yoshihiro Ohba ----- End forwarded message ----- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 12:49:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16236 for ; Tue, 27 Jan 2004 12:49:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXKV-0005aM-A0 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 12:48:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RHmppo021464 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 12:48:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXKV-0005a7-1j for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 12:48:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16206 for ; Tue, 27 Jan 2004 12:48:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlXKT-00033M-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:48:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlXJW-00030L-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:47:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlXIl-0002xe-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 12:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXIk-0005W1-5v; Tue, 27 Jan 2004 12:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlXIZ-0005VW-Uw for pana@optimus.ietf.org; Tue, 27 Jan 2004 12:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16122 for ; Tue, 27 Jan 2004 12:46:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlXIY-0002wy-00 for pana@ietf.org; Tue, 27 Jan 2004 12:46:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlXHb-0002ue-00 for pana@ietf.org; Tue, 27 Jan 2004 12:45:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlXH9-0002sK-00 for pana@ietf.org; Tue, 27 Jan 2004 12:45:23 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RHjMN9024934 for ; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RHjMKl014698 for ; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA14697 ; Wed, 28 Jan 2004 02:45:22 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA27429; Wed, 28 Jan 2004 02:45:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA02447; Wed, 28 Jan 2004 02:45:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RHjK0j020516 for ; Wed, 28 Jan 2004 02:45:21 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5002EXTBJL9@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 28 Jan 2004 02:45:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlXFi-0001vn-00 for ; Tue, 27 Jan 2004 09:43:54 -0800 Date: Tue, 27 Jan 2004 09:43:54 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127174354.GP3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] [: issue 28 (state machine, table available)] Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Let me retransmit this message since I have not seen my previous post... Yoshihiro Ohba ----- Forwarded message from ----- To: pana@ietf.org Subject: issue 28 (state machine, table available) Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i PANA state machines in ascii table format is available at: http://www.danforsberg.info:8080/pana-issues/file20/state-machine-01242004.txt (Thanks Dan for putting the file to the URL.) These are changes from the previous version of state machines in graphic images: ------------- o Retransmission behavior is added. o Decisions on whether to include optional AVP is added, based on the static configurations or dynamic conditions. o Detailed conditions are described for NAP/ISP separate authentication. o Variable name SESSION_RESUM is renamed to MOBILITY. o 2ND_EAP variable in PaC state machine is removed. Instead, Result-Code AVP value in PBR is checked. o In PAA state machine, OFFLINE state is devided into OFFLINE and STATEFUL_DISC states in order to distingish stateful discovery and stateless discovery. o "Session Timeout" signal in PAA state machine is replaced with EAP_REAUTH event. o "Timeout" signal in PaC and PAA state machines are replaced with SESS_TIMEOUT event. How it looks like? Comments are appreciated. Yoshihiro Ohba ----- End forwarded message ----- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 14:04:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18499 for ; Tue, 27 Jan 2004 14:04:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYVE-0003oI-Q0; Tue, 27 Jan 2004 14:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYVD-0003ny-Lm for pana@optimus.ietf.org; Tue, 27 Jan 2004 14:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18481 for ; Tue, 27 Jan 2004 14:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYVB-0007Sm-00 for pana@ietf.org; Tue, 27 Jan 2004 14:03:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYUF-0007Pu-00 for pana@ietf.org; Tue, 27 Jan 2004 14:02:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlYU2-0007Mf-00 for pana@ietf.org; Tue, 27 Jan 2004 14:02:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RJ2iN9015128; Wed, 28 Jan 2004 04:02:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RJ2i0i010058; Wed, 28 Jan 2004 04:02:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA10057 ; Wed, 28 Jan 2004 04:02:44 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA15644; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA21451; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RJ2g0j011179; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS500459WWEXV@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 04:02:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlYTi-00027y-00; Tue, 27 Jan 2004 11:02:26 -0800 Date: Tue, 27 Jan 2004 11:02:26 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127190226.GS3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 38 (resolution) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , In section 4.1.6, change: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0." to: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0. PANA_MAC_PRF represents the pseudo random function corresponding to the MAC algorithm specified in the MAC AVP. In this version of draft, PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same algorithm to calculate a MAC AVP they originate and receive. The algorithm is determined by the PAA when a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not support the MAC algorithm specified in the PANA-Bind-Request message, it MUST silently discard the message. The PAA MUST NOT change the MAC algorithm throughout the continuation of the PANA session." In section 9.4.1, change: " Algorithm 1 HMAC-MD5 (16 bytes) 2 HMAC-SHA1 (20 bytes)" to: " Algorithm 1 HMAC-SHA1 (20 bytes)" Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 14:06:23 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18580 for ; Tue, 27 Jan 2004 14:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYX5-0003wK-Ho for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 14:05:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RJ5t1q015141 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 14:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYX5-0003w8-CS for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 14:05:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18543 for ; Tue, 27 Jan 2004 14:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYX3-0007ZR-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 14:05:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYW5-0007Vi-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 14:04:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlYVG-0007Ss-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 14:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYVE-0003oI-Q0; Tue, 27 Jan 2004 14:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYVD-0003ny-Lm for pana@optimus.ietf.org; Tue, 27 Jan 2004 14:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18481 for ; Tue, 27 Jan 2004 14:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYVB-0007Sm-00 for pana@ietf.org; Tue, 27 Jan 2004 14:03:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYUF-0007Pu-00 for pana@ietf.org; Tue, 27 Jan 2004 14:02:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlYU2-0007Mf-00 for pana@ietf.org; Tue, 27 Jan 2004 14:02:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RJ2iN9015128; Wed, 28 Jan 2004 04:02:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RJ2i0i010058; Wed, 28 Jan 2004 04:02:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA10057 ; Wed, 28 Jan 2004 04:02:44 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA15644; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA21451; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RJ2g0j011179; Wed, 28 Jan 2004 04:02:43 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS500459WWEXV@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 04:02:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlYTi-00027y-00; Tue, 27 Jan 2004 11:02:26 -0800 Date: Tue, 27 Jan 2004 11:02:26 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127190226.GS3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 38 (resolution) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In section 4.1.6, change: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = HMAC_SHA1(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0." to: "When a MAC AVP is included in a PANA message, the value field of the MAC AVP is calculated by using the PANA_MAC_Key in the following way: MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) where PANA_PDU is the PANA message including the PANA header, with the MAC AVP value field first initialized to 0. PANA_MAC_PRF represents the pseudo random function corresponding to the MAC algorithm specified in the MAC AVP. In this version of draft, PANA_MAC_PRF is HMAC-SHA1. The PaC and PAA MUST use the same algorithm to calculate a MAC AVP they originate and receive. The algorithm is determined by the PAA when a PANA-Bind-Request with a MAC AVP is sent. When the PaC does not support the MAC algorithm specified in the PANA-Bind-Request message, it MUST silently discard the message. The PAA MUST NOT change the MAC algorithm throughout the continuation of the PANA session." In section 9.4.1, change: " Algorithm 1 HMAC-MD5 (16 bytes) 2 HMAC-SHA1 (20 bytes)" to: " Algorithm 1 HMAC-SHA1 (20 bytes)" Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 15:09:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21324 for ; Tue, 27 Jan 2004 15:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZW8-0005jL-RO; Tue, 27 Jan 2004 15:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZW7-0005ir-TC for pana@optimus.ietf.org; Tue, 27 Jan 2004 15:08:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21272 for ; Tue, 27 Jan 2004 15:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlZW4-0003z8-00 for pana@ietf.org; Tue, 27 Jan 2004 15:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlZV8-0003vr-00 for pana@ietf.org; Tue, 27 Jan 2004 15:07:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlZUJ-0003sc-00 for pana@ietf.org; Tue, 27 Jan 2004 15:07:07 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RK76N9003732 for ; Wed, 28 Jan 2004 05:07:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RK76Aw005094 for ; Wed, 28 Jan 2004 05:07:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA05093 ; Wed, 28 Jan 2004 05:07:06 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA02817; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19406; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RK740j023930 for ; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5006Q3ZVR8D@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 28 Jan 2004 05:07:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlZSD-0002G9-00 for ; Tue, 27 Jan 2004 12:04:57 -0800 Date: Tue, 27 Jan 2004 12:04:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127200457.GW3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 41 (reject?) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Issue 41 (multiple PAA) will be rejected unless there is strong support. http://www.danforsberg.info:8080/pana-issues/issue41 Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 15:11:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21522 for ; Tue, 27 Jan 2004 15:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZY5-00071o-EJ for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 15:11:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RKB1Yj027002 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZY4-000719-J3 for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 15:11:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21461 for ; Tue, 27 Jan 2004 15:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlZY1-00047e-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:10:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlZX5-00043a-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:10:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlZW9-0003zp-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZW8-0005jL-RO; Tue, 27 Jan 2004 15:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlZW7-0005ir-TC for pana@optimus.ietf.org; Tue, 27 Jan 2004 15:08:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21272 for ; Tue, 27 Jan 2004 15:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlZW4-0003z8-00 for pana@ietf.org; Tue, 27 Jan 2004 15:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlZV8-0003vr-00 for pana@ietf.org; Tue, 27 Jan 2004 15:07:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AlZUJ-0003sc-00 for pana@ietf.org; Tue, 27 Jan 2004 15:07:07 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RK76N9003732 for ; Wed, 28 Jan 2004 05:07:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RK76Aw005094 for ; Wed, 28 Jan 2004 05:07:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA05093 ; Wed, 28 Jan 2004 05:07:06 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA02817; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19406; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RK740j023930 for ; Wed, 28 Jan 2004 05:07:05 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS5006Q3ZVR8D@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Wed, 28 Jan 2004 05:07:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AlZSD-0002G9-00 for ; Tue, 27 Jan 2004 12:04:57 -0800 Date: Tue, 27 Jan 2004 12:04:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127200457.GW3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 41 (reject?) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Issue 41 (multiple PAA) will be rejected unless there is strong support. http://www.danforsberg.info:8080/pana-issues/issue41 Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 15:49:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22941 for ; Tue, 27 Jan 2004 15:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ala8r-0002UQ-4N; Tue, 27 Jan 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ala7t-0002Sx-EN for pana@optimus.ietf.org; Tue, 27 Jan 2004 15:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22895 for ; Tue, 27 Jan 2004 15:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ala7s-00066c-00 for pana@ietf.org; Tue, 27 Jan 2004 15:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ala6x-000633-00 for pana@ietf.org; Tue, 27 Jan 2004 15:47:04 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ala6b-0005zm-00 for pana@ietf.org; Tue, 27 Jan 2004 15:46:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RKkeN9014215; Wed, 28 Jan 2004 05:46:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RKkeD0017954; Wed, 28 Jan 2004 05:46:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA17953 ; Wed, 28 Jan 2004 05:46:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA12152; Wed, 28 Jan 2004 05:46:39 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA09317; Wed, 28 Jan 2004 05:46:39 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RKkc0j000052; Wed, 28 Jan 2004 05:46:38 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS60078H1PO4W@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 05:46:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ala4V-0002Mr-00; Tue, 27 Jan 2004 12:44:31 -0800 Date: Tue, 27 Jan 2004 12:44:31 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127204431.GX3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] unspecified address clean-up (new issue) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , I think it's time to remove unspecified IP address support from PANA specification. Are we ready for the following changes? In section 4.1.2, change: "PaC MAY use unspecified IP address for communicating with PAA." to: "PaC MUST NOT use an unspecified IP address for communicating with PAA." Change the first two paragraphs in section 4.2 from: "4.2 Discovery and Initial Handshake Phase When a PaC attaches to a network, and knows that it has to discover PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- known link local multicast address (TBD) and UDP port (TBD). The source address is set to the unspecified IP address if the PaC has not configured an address yet. PANA PAA discovery assumes that PaC and PAA are one hop away from each other. If PaC knows the IP address of the PAA (some pre-configuration), it MAY unicast the PANA discovery message to that address. PAA SHOULD answer to the PANA-PAA-Discover message with a PANA-Start-Request message. When the PAA receives such a request, or upon receiving some lower layer indications of a new PaC, PAA SHOULD unicast a PANA-Start-Request message. The destination address may be unspecified IP address, but the L2 destination would be a unicast address (something for the implementations to deal with)." to: "4.2 Discovery and Initial Handshake Phase When a PaC attaches to a network, and knows that it has to discover PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- known link local multicast address (TBD) and UDP port (TBD). PANA PAA discovery assumes that PaC and PAA are one hop away from each other. If PaC knows the IP address of the PAA (some pre-configuration), it MAY unicast the PANA discovery message to that address. PAA SHOULD answer to the PANA-PAA-Discover message with a PANA-Start-Request message. When the PAA receives such a request, or upon receiving some lower layer indications of a new PaC, PAA SHOULD unicast a PANA-Start-Request message." Delete the following paragraph entirely from section 4.7: "When IPsec-based access control is used but the PaC is using an unspecified IP address in the authentication phase, the device ID reported by the PaC MUST be either 0.0.0.0 or 0::0. This device ID MUST be recorded as a temporary one by the PAA until the PaC obtains a valid one and informs the PAA. Eventually PaC MUST obtain an IP address, possibly by relying on the newly-created PANA session [I-D.tschofenig-pana-bootstrap-rfc3118], in order to gain full access to the network. PaC MUST update the device identifier registered on the PAA from unspecified to the valid IP address by initiating a PANA-Reauth-Request/PANA-Reauth-Answer exchange in which the IP address of the PaC is contained in the Device-Id AVP." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 15:51:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23033 for ; Tue, 27 Jan 2004 15:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaAo-0002zb-0r for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 15:51:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RKp1BA011491 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 15:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlaAn-0002z2-FX for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 15:51:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22987 for ; Tue, 27 Jan 2004 15:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlaAm-0006KC-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:51:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ala9l-0006Ew-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:49:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ala8s-0006AZ-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 15:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ala8r-0002UQ-4N; Tue, 27 Jan 2004 15:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ala7t-0002Sx-EN for pana@optimus.ietf.org; Tue, 27 Jan 2004 15:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22895 for ; Tue, 27 Jan 2004 15:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ala7s-00066c-00 for pana@ietf.org; Tue, 27 Jan 2004 15:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ala6x-000633-00 for pana@ietf.org; Tue, 27 Jan 2004 15:47:04 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ala6b-0005zm-00 for pana@ietf.org; Tue, 27 Jan 2004 15:46:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0RKkeN9014215; Wed, 28 Jan 2004 05:46:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0RKkeD0017954; Wed, 28 Jan 2004 05:46:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA17953 ; Wed, 28 Jan 2004 05:46:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA12152; Wed, 28 Jan 2004 05:46:39 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA09317; Wed, 28 Jan 2004 05:46:39 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0RKkc0j000052; Wed, 28 Jan 2004 05:46:38 +0900 (JST) Received: from steelhead ([159.119.168.109]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS60078H1PO4W@tsbpo1.po.toshiba.co.jp>; Wed, 28 Jan 2004 05:46:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ala4V-0002Mr-00; Tue, 27 Jan 2004 12:44:31 -0800 Date: Tue, 27 Jan 2004 12:44:31 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040127204431.GX3563@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] unspecified address clean-up (new issue) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think it's time to remove unspecified IP address support from PANA specification. Are we ready for the following changes? In section 4.1.2, change: "PaC MAY use unspecified IP address for communicating with PAA." to: "PaC MUST NOT use an unspecified IP address for communicating with PAA." Change the first two paragraphs in section 4.2 from: "4.2 Discovery and Initial Handshake Phase When a PaC attaches to a network, and knows that it has to discover PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- known link local multicast address (TBD) and UDP port (TBD). The source address is set to the unspecified IP address if the PaC has not configured an address yet. PANA PAA discovery assumes that PaC and PAA are one hop away from each other. If PaC knows the IP address of the PAA (some pre-configuration), it MAY unicast the PANA discovery message to that address. PAA SHOULD answer to the PANA-PAA-Discover message with a PANA-Start-Request message. When the PAA receives such a request, or upon receiving some lower layer indications of a new PaC, PAA SHOULD unicast a PANA-Start-Request message. The destination address may be unspecified IP address, but the L2 destination would be a unicast address (something for the implementations to deal with)." to: "4.2 Discovery and Initial Handshake Phase When a PaC attaches to a network, and knows that it has to discover PAA for PANA, it SHOULD send a PANA-PAA-Discover message to a well- known link local multicast address (TBD) and UDP port (TBD). PANA PAA discovery assumes that PaC and PAA are one hop away from each other. If PaC knows the IP address of the PAA (some pre-configuration), it MAY unicast the PANA discovery message to that address. PAA SHOULD answer to the PANA-PAA-Discover message with a PANA-Start-Request message. When the PAA receives such a request, or upon receiving some lower layer indications of a new PaC, PAA SHOULD unicast a PANA-Start-Request message." Delete the following paragraph entirely from section 4.7: "When IPsec-based access control is used but the PaC is using an unspecified IP address in the authentication phase, the device ID reported by the PaC MUST be either 0.0.0.0 or 0::0. This device ID MUST be recorded as a temporary one by the PAA until the PaC obtains a valid one and informs the PAA. Eventually PaC MUST obtain an IP address, possibly by relying on the newly-created PANA session [I-D.tschofenig-pana-bootstrap-rfc3118], in order to gain full access to the network. PaC MUST update the device identifier registered on the PAA from unspecified to the valid IP address by initiating a PANA-Reauth-Request/PANA-Reauth-Answer exchange in which the IP address of the PaC is contained in the Device-Id AVP." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 17:28:33 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27270 for ; Tue, 27 Jan 2004 17:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albgf-0000Av-Fi; Tue, 27 Jan 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albgd-0000AW-P5 for pana@optimus.ietf.org; Tue, 27 Jan 2004 17:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27246 for ; Tue, 27 Jan 2004 17:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Albgb-00069R-00 for pana@ietf.org; Tue, 27 Jan 2004 17:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Albfd-00065H-00 for pana@ietf.org; Tue, 27 Jan 2004 17:26:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Albef-0005zx-00 for pana@ietf.org; Tue, 27 Jan 2004 17:25:57 -0500 Date: Tue, 27 Jan 2004 14:25:52 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Tschofenig Hannes CC: Message-ID: In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC05F5@mchp905a.mch.sbs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>>> When the PANA session expires, if the peers are interested in >>>> continuing the "access", another run of EAP is executed >>>> inside PANA. This should create a new EAP SA, hence a new PANA SA. >>> >>> does this lead to a new session identifier? >> >> I think I should have said "before the PANA session expires", >> and in that >> case I'd answer your question as "the same session identifier >> is preserved". >> It's like extending the lifetime of the ongoing session. If >> the session >> expires on the PAA, I think we can consider it's gone and a >> new session >> identifier will be allocated. > > in this case you might want to have two sas concurrently to safely switch > from one sa to the other. to avoid some error cases where the pac or the paa > end up having no valid security association you need to distinguish these > two somehow. If we are talking about refreshing the current (unexpired) PANA session with a new EAP run (and getting a new EAP keying material), then I think we can just update the PANA SA with the new key. Next time secure association protocol runs, it takes this new key. So, one PANA SA at a time should be sufficient, imo. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 17:30:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27303 for ; Tue, 27 Jan 2004 17:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albie-0000GO-5Y for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 17:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RMU4xQ000999 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 17:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albib-0000Fj-Je for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 17:30:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27294 for ; Tue, 27 Jan 2004 17:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlbiZ-0006GC-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 17:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Albhd-0006DQ-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 17:29:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Albgj-0006Ag-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 17:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albgf-0000Av-Fi; Tue, 27 Jan 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albgd-0000AW-P5 for pana@optimus.ietf.org; Tue, 27 Jan 2004 17:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27246 for ; Tue, 27 Jan 2004 17:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Albgb-00069R-00 for pana@ietf.org; Tue, 27 Jan 2004 17:27:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Albfd-00065H-00 for pana@ietf.org; Tue, 27 Jan 2004 17:26:58 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Albef-0005zx-00 for pana@ietf.org; Tue, 27 Jan 2004 17:25:57 -0500 Date: Tue, 27 Jan 2004 14:25:52 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Tschofenig Hannes CC: Message-ID: In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC05F5@mchp905a.mch.sbs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>> When the PANA session expires, if the peers are interested in >>>> continuing the "access", another run of EAP is executed >>>> inside PANA. This should create a new EAP SA, hence a new PANA SA. >>> >>> does this lead to a new session identifier? >> >> I think I should have said "before the PANA session expires", >> and in that >> case I'd answer your question as "the same session identifier >> is preserved". >> It's like extending the lifetime of the ongoing session. If >> the session >> expires on the PAA, I think we can consider it's gone and a >> new session >> identifier will be allocated. > > in this case you might want to have two sas concurrently to safely switch > from one sa to the other. to avoid some error cases where the pac or the paa > end up having no valid security association you need to distinguish these > two somehow. If we are talking about refreshing the current (unexpired) PANA session with a new EAP run (and getting a new EAP keying material), then I think we can just update the PANA SA with the new key. Next time secure association protocol runs, it takes this new key. So, one PANA SA at a time should be sufficient, imo. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 18:57:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01086 for ; Tue, 27 Jan 2004 18:57:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald5I-0005Sz-MT; Tue, 27 Jan 2004 18:57:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9Ba-000840-O9 for pana@optimus.ietf.org; Mon, 26 Jan 2004 11:02:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10494 for ; Mon, 26 Jan 2004 11:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9BY-0004a5-00 for pana@ietf.org; Mon, 26 Jan 2004 11:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9Ac-0004Xk-00 for pana@ietf.org; Mon, 26 Jan 2004 11:01:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Al9AD-0004Vx-00 for pana@ietf.org; Mon, 26 Jan 2004 11:00:38 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0QG0aN9010877 for ; Tue, 27 Jan 2004 01:00:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0QG0aw0007554 for ; Tue, 27 Jan 2004 01:00:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA07553 ; Tue, 27 Jan 2004 01:00:36 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA02755; Tue, 27 Jan 2004 01:00:35 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA06787; Tue, 27 Jan 2004 01:00:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0QG0X0j004022 for ; Tue, 27 Jan 2004 01:00:34 +0900 (JST) Received: from steelhead ([159.119.168.110]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS300MRRTSWIO@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Tue, 27 Jan 2004 01:00:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Al98v-00084y-00 for ; Mon, 26 Jan 2004 07:59:17 -0800 Date: Mon, 26 Jan 2004 07:59:17 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040126155917.GC29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 28 (state machine, table available) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , PANA state machines in ascii table format is available at: http://www.danforsberg.info:8080/pana-issues/file20/state-machine-01242004.txt (Thanks Dan for putting the file to the URL.) These are changes from the previous version of state machines in graphic images: ------------- o Retransmission behavior is added. o Decisions on whether to include optional AVP is added, based on the static configurations or dynamic conditions. o Detailed conditions are described for NAP/ISP separate authentication. o Variable name SESSION_RESUM is renamed to MOBILITY. o 2ND_EAP variable in PaC state machine is removed. Instead, Result-Code AVP value in PBR is checked. o In PAA state machine, OFFLINE state is devided into OFFLINE and STATEFUL_DISC states in order to distingish stateful discovery and stateless discovery. o "Session Timeout" signal in PAA state machine is replaced with EAP_REAUTH event. o "Timeout" signal in PaC and PAA state machines are replaced with SESS_TIMEOUT event. How it looks like? Comments are appreciated. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 18:57:56 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01084 for ; Tue, 27 Jan 2004 18:57:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald57-0005LL-E3; Tue, 27 Jan 2004 18:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8hb-0006Uj-Q0 for pana@optimus.ietf.org; Mon, 26 Jan 2004 10:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09674 for ; Mon, 26 Jan 2004 10:31:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8hZ-0003BG-00 for pana@ietf.org; Mon, 26 Jan 2004 10:31:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8gg-00038Y-00 for pana@ietf.org; Mon, 26 Jan 2004 10:30:07 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Al8g9-00035w-00 for pana@ietf.org; Mon, 26 Jan 2004 10:29:33 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0QFTVN9003321; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0QFTVdZ027629; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA27628 ; Tue, 27 Jan 2004 00:29:31 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA25463; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA06690; Tue, 27 Jan 2004 00:29:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0QFTT0j022095; Tue, 27 Jan 2004 00:29:30 +0900 (JST) Received: from steelhead ([159.119.168.110]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS300MBLSD3IO@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 00:29:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Al8f3-0007wV-00; Mon, 26 Jan 2004 07:28:25 -0800 Date: Mon, 26 Jan 2004 07:28:25 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] EAP-Payload in PBR (new issue) In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040126152825.GA29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Jan 26, 2004 at 12:23:51PM +0200, Dan.Forsberg@nokia.com wrote: > Ok. In EAP state machine the AAA timeout results as a timeout_failure. > If PBR is used, the result-code AVP should clarify this. I coulnd't find > any directly suitable result-code from rfc3588, though. One that is near > could be this one: > > DIAMETER_UNABLE_TO_COMPLY 5012 > This error is returned when a request is rejected for unspecified > reasons. > > => > > PANA_UNABLE_TO_COMPLY 5012 > > This could then happen in any stage in which the EAP protocol is > involved. I agree. How about having more detailed text (please see below)? " PANA_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. For example, when an EAP authentication fails at an EAP pass-through authenticator without passing an EAP-Failure message to the PAA, a Result-Code AVP with this error code is carried in PANA-Bind-Request message without an EAP-Payload AVP." Regards, Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 22 January, 2004 19:18 > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > Cc: yohba@tari.toshiba.com; pana@ietf.org > > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > > > > I thought that PANA-Error message is used for errors occured within > > PANA. But in this case, the error is an EAP authentication failure > > and I think it should be carried by PANA authentication > > success/failure message (i.e., PBR). > > > > (There is another problem with using PANA-Error for this case: > > Which AVP is considered invalid and carried in Failed-AVP?) > > > > Yoshihiro Ohba > > > > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > > Dan.Forsberg@nokia.com wrote: > > > I guess an error should be sent instead then, not the PBR msg. > > > - Dan > > > > > > > -----Original Message----- > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > > Behalf Of ext Yoshihiro Ohba > > > > Sent: 17 January, 2004 02:44 > > > > To: pana@ietf.org > > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > > > PANA-Bind-Request. However, it is possible that EAP conversation > > > > fails without generating a EAP-Success or EAP-Failure message, > > > > specifically when a AAA timeout occurs (please see EAP Full > > > > Authenticator State Machine diagram in the EAP state > > machines draft, > > > > pdf version). > > > > > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 18:58:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01133 for ; Tue, 27 Jan 2004 18:58:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald5L-0005V7-4O; Tue, 27 Jan 2004 18:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9JK-0000EN-U6 for pana@optimus.ietf.org; Mon, 26 Jan 2004 11:10:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10813 for ; Mon, 26 Jan 2004 11:09:59 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9JI-00050F-00 for pana@ietf.org; Mon, 26 Jan 2004 11:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9IN-0004xy-00 for pana@ietf.org; Mon, 26 Jan 2004 11:09:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Al9Hr-0004vk-00 for pana@ietf.org; Mon, 26 Jan 2004 11:08:31 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QG8UV15941 for ; Mon, 26 Jan 2004 18:08:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 18:08:29 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 18:08:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Mon, 26 Jan 2004 18:08:28 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPkJjBbJUtMFvHvR3iiolUQeoUfEAAAGJgg To: Cc: X-OriginalArrivalTime: 26 Jan 2004 16:08:28.0744 (UTC) FILETIME=[A2C86C80:01C3E426] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 26 January, 2004 17:28 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > On Mon, Jan 26, 2004 at 12:23:51PM +0200, > Dan.Forsberg@nokia.com wrote: > > Ok. In EAP state machine the AAA timeout results as a > timeout_failure. > > If PBR is used, the result-code AVP should clarify this. I > coulnd't find > > any directly suitable result-code from rfc3588, though. One > that is near > > could be this one: > > > > DIAMETER_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for > unspecified > > reasons. > > > > => > > > > PANA_UNABLE_TO_COMPLY 5012 > > > > This could then happen in any stage in which the EAP protocol is > > involved. > > I agree. How about having more detailed text (please see below)? > > " PANA_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for > unspecified reasons. For example, when an EAP authentication > fails at an EAP pass-through authenticator without passing an > EAP-Failure message to the PAA, a Result-Code AVP with this > error code is carried in PANA-Bind-Request message without an > EAP-Payload AVP." > > > Regards, > > Yoshihiro Ohba > > > > > > > > - Dan > > > > > -----Original Message----- > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: 22 January, 2004 19:18 > > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > > Cc: yohba@tari.toshiba.com; pana@ietf.org > > > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > I thought that PANA-Error message is used for errors > occured within > > > PANA. But in this case, the error is an EAP > authentication failure > > > and I think it should be carried by PANA authentication > > > success/failure message (i.e., PBR). > > > > > > (There is another problem with using PANA-Error for this case: > > > Which AVP is considered invalid and carried in Failed-AVP?) > > > > > > Yoshihiro Ohba > > > > > > > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > > > Dan.Forsberg@nokia.com wrote: > > > > I guess an error should be sent instead then, not the PBR msg. > > > > - Dan > > > > > > > > > -----Original Message----- > > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > > > Behalf Of ext Yoshihiro Ohba > > > > > Sent: 17 January, 2004 02:44 > > > > > To: pana@ietf.org > > > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a > required AVP for > > > > > PANA-Bind-Request. However, it is possible that EAP > conversation > > > > > fails without generating a EAP-Success or EAP-Failure message, > > > > > specifically when a AAA timeout occurs (please see EAP Full > > > > > Authenticator State Machine diagram in the EAP state > > > machines draft, > > > > > pdf version). > > > > > > > > > > Thus, EAP-Payload AVP should be optional for > PANA-Bind-Request. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 19:11:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02701 for ; Tue, 27 Jan 2004 19:11:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldIK-0001xA-N4; Tue, 27 Jan 2004 19:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlEEp-0001CP-On for pana@optimus.ietf.org; Mon, 26 Jan 2004 16:25:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20754 for ; Mon, 26 Jan 2004 16:25:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEEd-0004z6-00 for pana@ietf.org; Mon, 26 Jan 2004 16:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlECy-0004v2-00 for pana@ietf.org; Mon, 26 Jan 2004 16:23:49 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AlEBb-0004pN-00 for pana@ietf.org; Mon, 26 Jan 2004 16:22:24 -0500 Date: Mon, 26 Jan 2004 13:21:55 -0800 Subject: Re: [Pana] issue 40 (proposed text) From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040124034310.GZ26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Any considerations regarding whether the key ID should be monotonically increasing or just a random value? Alper > Here is a proposed text for issue 40. > (Sorry if I had already sent this.) > > > - Add the following item in section 4.1.1: > > "o Key-Id AVP: contains an MSK identifier." > > > - In section 4.1.5, Change: > > "A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a Master Session Key (MSK) > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > authentication fails or no MSK is produced by any EAP authentication > method. In the case where two EAP authentications are performed in a > sequence in a single PANA authentication, it is possible that two > MSKs are derived. If this happens, the PANA SA MUST be bound to the > MSK derived from the first EAP authentication. When a new MSK is > derived as a result of EAP-based re-authentication, any key derived > from the old MSK MUST be updated to a new one that is derived from > the new MSK." > > to: > > A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a Master Session Key > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > PANA authentication fails or no MSK is produced by any EAP > authentication method. In the case where two EAP authentications > are performed in a sequence in a single PANA authentication, it is > possible that two MSKs are derived. If this happens, the PANA SA > MUST be bound to the MSK derived from the first EAP authentication. > When a new MSK is derived as a result of EAP-based > re-authentication, any key derived from the old MSK MUST be updated > to a new one that is derived from the new MSK. In order to > distinguish the new MSK from old ones, one Key-Id AVP MUST be > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > end of the authentication phase which resulted in deriving a new > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > that uniquely identifies the MSK within the PANA session. The > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > identifier carried in the request. PANA-Bind-Request and > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > AVP whose value is computed by using the new MSK." > > > - In section 4.1.5, change: > > > " * PANA SA attributes: > > + MSK > > + PANA_MAC_Key" > > > to: > > " * PANA SA attributes: > > + MSK > > + MSK identifier > > + PANA_MAC_Key" > > > - Add the following section: > > "9.4.16 Key-Id AVP > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > an MSK identifier. The MSK identifier is assigned by PAA and MUST > be unique within the PANA session." > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > contain optional Key-Id AVP. > > > > Comments? > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Jan 27 19:15:00 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02973 for ; Tue, 27 Jan 2004 19:15:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldLg-0003cl-7q; Tue, 27 Jan 2004 19:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHFK-00084A-Fu for pana@optimus.ietf.org; Mon, 26 Jan 2004 19:38:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26556 for ; Mon, 26 Jan 2004 19:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHFI-0006o1-00 for pana@ietf.org; Mon, 26 Jan 2004 19:38:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHEQ-0006lH-00 for pana@ietf.org; Mon, 26 Jan 2004 19:37:30 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AlHDv-0006h0-00 for pana@ietf.org; Mon, 26 Jan 2004 19:36:59 -0500 Date: Mon, 26 Jan 2004 16:37:01 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Hannes Tschofenig CC: Message-ID: In-Reply-To: <007801c3e295$fc5306d0$0105a8c0@verena> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> When the PANA session expires, if the peers are interested in >> continuing the "access", another run of EAP is executed >> inside PANA. This should create a new EAP SA, hence a new PANA SA. > > does this lead to a new session identifier? I think I should have said "before the PANA session expires", and in that case I'd answer your question as "the same session identifier is preserved". It's like extending the lifetime of the ongoing session. If the session expires on the PAA, I think we can consider it's gone and a new session identifier will be allocated. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 19:36:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05349 for ; Tue, 27 Jan 2004 19:36:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldgw-0006py-SN for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 19:36:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0aQAR026276 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 19:36:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aldgw-0006pj-NR for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:36:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05298 for ; Tue, 27 Jan 2004 19:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aldgv-00026X-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:36:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alde8-0001R2-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:33:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aldcq-00017H-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:32:12 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldR1-00062U-8P for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:19:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldLg-0003cl-7q; Tue, 27 Jan 2004 19:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlHFK-00084A-Fu for pana@optimus.ietf.org; Mon, 26 Jan 2004 19:38:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26556 for ; Mon, 26 Jan 2004 19:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlHFI-0006o1-00 for pana@ietf.org; Mon, 26 Jan 2004 19:38:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlHEQ-0006lH-00 for pana@ietf.org; Mon, 26 Jan 2004 19:37:30 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AlHDv-0006h0-00 for pana@ietf.org; Mon, 26 Jan 2004 19:36:59 -0500 Date: Mon, 26 Jan 2004 16:37:01 -0800 Subject: Re: [Pana] EAP keying issues and PANA From: Alper Yegin To: Hannes Tschofenig CC: Message-ID: In-Reply-To: <007801c3e295$fc5306d0$0105a8c0@verena> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> When the PANA session expires, if the peers are interested in >> continuing the "access", another run of EAP is executed >> inside PANA. This should create a new EAP SA, hence a new PANA SA. > > does this lead to a new session identifier? I think I should have said "before the PANA session expires", and in that case I'd answer your question as "the same session identifier is preserved". It's like extending the lifetime of the ongoing session. If the session expires on the PAA, I think we can consider it's gone and a new session identifier will be allocated. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 20:05:45 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07376 for ; Tue, 27 Jan 2004 20:05:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale8q-0000QH-KF for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:05:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S15Gee001619 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:05:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ale8q-0000Q2-2C for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07343 for ; Tue, 27 Jan 2004 20:05:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ale8o-0004ml-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:05:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ale7s-0004iO-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:04:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ale7Z-0004eG-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:03:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald57-0005LL-E3; Tue, 27 Jan 2004 18:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al8hb-0006Uj-Q0 for pana@optimus.ietf.org; Mon, 26 Jan 2004 10:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09674 for ; Mon, 26 Jan 2004 10:31:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8hZ-0003BG-00 for pana@ietf.org; Mon, 26 Jan 2004 10:31:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8gg-00038Y-00 for pana@ietf.org; Mon, 26 Jan 2004 10:30:07 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Al8g9-00035w-00 for pana@ietf.org; Mon, 26 Jan 2004 10:29:33 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0QFTVN9003321; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0QFTVdZ027629; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA27628 ; Tue, 27 Jan 2004 00:29:31 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA25463; Tue, 27 Jan 2004 00:29:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA06690; Tue, 27 Jan 2004 00:29:30 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0QFTT0j022095; Tue, 27 Jan 2004 00:29:30 +0900 (JST) Received: from steelhead ([159.119.168.110]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS300MBLSD3IO@tsbpo1.po.toshiba.co.jp>; Tue, 27 Jan 2004 00:29:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Al8f3-0007wV-00; Mon, 26 Jan 2004 07:28:25 -0800 Date: Mon, 26 Jan 2004 07:28:25 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] EAP-Payload in PBR (new issue) In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040126152825.GA29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Jan 26, 2004 at 12:23:51PM +0200, Dan.Forsberg@nokia.com wrote: > Ok. In EAP state machine the AAA timeout results as a timeout_failure. > If PBR is used, the result-code AVP should clarify this. I coulnd't find > any directly suitable result-code from rfc3588, though. One that is near > could be this one: > > DIAMETER_UNABLE_TO_COMPLY 5012 > This error is returned when a request is rejected for unspecified > reasons. > > => > > PANA_UNABLE_TO_COMPLY 5012 > > This could then happen in any stage in which the EAP protocol is > involved. I agree. How about having more detailed text (please see below)? " PANA_UNABLE_TO_COMPLY 5012 This error is returned when a request is rejected for unspecified reasons. For example, when an EAP authentication fails at an EAP pass-through authenticator without passing an EAP-Failure message to the PAA, a Result-Code AVP with this error code is carried in PANA-Bind-Request message without an EAP-Payload AVP." Regards, Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 22 January, 2004 19:18 > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > Cc: yohba@tari.toshiba.com; pana@ietf.org > > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > > > > I thought that PANA-Error message is used for errors occured within > > PANA. But in this case, the error is an EAP authentication failure > > and I think it should be carried by PANA authentication > > success/failure message (i.e., PBR). > > > > (There is another problem with using PANA-Error for this case: > > Which AVP is considered invalid and carried in Failed-AVP?) > > > > Yoshihiro Ohba > > > > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > > Dan.Forsberg@nokia.com wrote: > > > I guess an error should be sent instead then, not the PBR msg. > > > - Dan > > > > > > > -----Original Message----- > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > > Behalf Of ext Yoshihiro Ohba > > > > Sent: 17 January, 2004 02:44 > > > > To: pana@ietf.org > > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a required AVP for > > > > PANA-Bind-Request. However, it is possible that EAP conversation > > > > fails without generating a EAP-Success or EAP-Failure message, > > > > specifically when a AAA timeout occurs (please see EAP Full > > > > Authenticator State Machine diagram in the EAP state > > machines draft, > > > > pdf version). > > > > > > > > Thus, EAP-Payload AVP should be optional for PANA-Bind-Request. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 20:11:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07742 for ; Tue, 27 Jan 2004 20:11:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleEV-0000sA-TU for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:11:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1B7eM003348 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:11:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AleEV-0000rs-LX for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:11:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07727 for ; Tue, 27 Jan 2004 20:11:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AleET-0005Il-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleDa-0005Fw-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:10:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AleCn-0005Cn-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald5I-0005Sz-MT; Tue, 27 Jan 2004 18:57:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9Ba-000840-O9 for pana@optimus.ietf.org; Mon, 26 Jan 2004 11:02:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10494 for ; Mon, 26 Jan 2004 11:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9BY-0004a5-00 for pana@ietf.org; Mon, 26 Jan 2004 11:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9Ac-0004Xk-00 for pana@ietf.org; Mon, 26 Jan 2004 11:01:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Al9AD-0004Vx-00 for pana@ietf.org; Mon, 26 Jan 2004 11:00:38 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0QG0aN9010877 for ; Tue, 27 Jan 2004 01:00:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0QG0aw0007554 for ; Tue, 27 Jan 2004 01:00:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA07553 ; Tue, 27 Jan 2004 01:00:36 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA02755; Tue, 27 Jan 2004 01:00:35 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA06787; Tue, 27 Jan 2004 01:00:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0QG0X0j004022 for ; Tue, 27 Jan 2004 01:00:34 +0900 (JST) Received: from steelhead ([159.119.168.110]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS300MRRTSWIO@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Tue, 27 Jan 2004 01:00:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Al98v-00084y-00 for ; Mon, 26 Jan 2004 07:59:17 -0800 Date: Mon, 26 Jan 2004 07:59:17 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040126155917.GC29975@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] issue 28 (state machine, table available) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 PANA state machines in ascii table format is available at: http://www.danforsberg.info:8080/pana-issues/file20/state-machine-01242004.txt (Thanks Dan for putting the file to the URL.) These are changes from the previous version of state machines in graphic images: ------------- o Retransmission behavior is added. o Decisions on whether to include optional AVP is added, based on the static configurations or dynamic conditions. o Detailed conditions are described for NAP/ISP separate authentication. o Variable name SESSION_RESUM is renamed to MOBILITY. o 2ND_EAP variable in PaC state machine is removed. Instead, Result-Code AVP value in PBR is checked. o In PAA state machine, OFFLINE state is devided into OFFLINE and STATEFUL_DISC states in order to distingish stateful discovery and stateless discovery. o "Session Timeout" signal in PAA state machine is replaced with EAP_REAUTH event. o "Timeout" signal in PaC and PAA state machines are replaced with SESS_TIMEOUT event. How it looks like? Comments are appreciated. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Jan 27 20:34:37 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09047 for ; Tue, 27 Jan 2004 20:34:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aleam-0001tA-SG for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S1Y8KY007254 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 20:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aleam-0001sv-OM for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 20:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09034 for ; Tue, 27 Jan 2004 20:34:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aleak-0007MA-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AleZn-0007JD-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:33:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AleZT-0007GS-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 20:32:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldIK-0001xA-N4; Tue, 27 Jan 2004 19:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlEEp-0001CP-On for pana@optimus.ietf.org; Mon, 26 Jan 2004 16:25:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20754 for ; Mon, 26 Jan 2004 16:25:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEEd-0004z6-00 for pana@ietf.org; Mon, 26 Jan 2004 16:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlECy-0004v2-00 for pana@ietf.org; Mon, 26 Jan 2004 16:23:49 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AlEBb-0004pN-00 for pana@ietf.org; Mon, 26 Jan 2004 16:22:24 -0500 Date: Mon, 26 Jan 2004 13:21:55 -0800 Subject: Re: [Pana] issue 40 (proposed text) From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040124034310.GZ26285@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Any considerations regarding whether the key ID should be monotonically increasing or just a random value? Alper > Here is a proposed text for issue 40. > (Sorry if I had already sent this.) > > > - Add the following item in section 4.1.1: > > "o Key-Id AVP: contains an MSK identifier." > > > - In section 4.1.5, Change: > > "A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a Master Session Key (MSK) > [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA > authentication fails or no MSK is produced by any EAP authentication > method. In the case where two EAP authentications are performed in a > sequence in a single PANA authentication, it is possible that two > MSKs are derived. If this happens, the PANA SA MUST be bound to the > MSK derived from the first EAP authentication. When a new MSK is > derived as a result of EAP-based re-authentication, any key derived > from the old MSK MUST be updated to a new one that is derived from > the new MSK." > > to: > > A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a Master Session Key > (MSK) [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the > PANA authentication fails or no MSK is produced by any EAP > authentication method. In the case where two EAP authentications > are performed in a sequence in a single PANA authentication, it is > possible that two MSKs are derived. If this happens, the PANA SA > MUST be bound to the MSK derived from the first EAP authentication. > When a new MSK is derived as a result of EAP-based > re-authentication, any key derived from the old MSK MUST be updated > to a new one that is derived from the new MSK. In order to > distinguish the new MSK from old ones, one Key-Id AVP MUST be > carried in PANA-Bind-Request and PANA-Bind-Answer message at the > end of the authentication phase which resulted in deriving a new > MSK. The Key-Id AVP is of type Unsigned32 and MUST contain a value > that uniquely identifies the MSK within the PANA session. The > PANA-Bind-Answer message sent in response to a PANA-Bind-Request > with a Key-Id AVP MUST contain a Key-Id AVP with the same MSK > identifier carried in the request. PANA-Bind-Request and > PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC > AVP whose value is computed by using the new MSK." > > > - In section 4.1.5, change: > > > " * PANA SA attributes: > > + MSK > > + PANA_MAC_Key" > > > to: > > " * PANA SA attributes: > > + MSK > > + MSK identifier > > + PANA_MAC_Key" > > > - Add the following section: > > "9.4.16 Key-Id AVP > > The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains > an MSK identifier. The MSK identifier is assigned by PAA and MUST > be unique within the PANA session." > > - Update ABNF and AVP occurrence table for PANA-Bind-Request/Answer to > contain optional Key-Id AVP. > > > > Comments? > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Jan 28 13:07:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17474 for ; Wed, 28 Jan 2004 13:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5d-0003df-5k; Wed, 28 Jan 2004 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5Z-0003a0-MA for pana@optimus.ietf.org; Wed, 28 Jan 2004 13:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17448 for ; Wed, 28 Jan 2004 13:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu5X-0007DX-00 for pana@ietf.org; Wed, 28 Jan 2004 13:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu4c-00076v-00 for pana@ietf.org; Wed, 28 Jan 2004 13:05:58 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Alu49-000708-00 for pana@ietf.org; Wed, 28 Jan 2004 13:05:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0SI5RN9024518; Thu, 29 Jan 2004 03:05:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0SI5RjD004329; Thu, 29 Jan 2004 03:05:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA04328 ; Thu, 29 Jan 2004 03:05:27 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA18357; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA17361; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0SI5Pgf005412; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from steelhead ([159.119.168.180]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS700GRBOWZ1O@tsbpo1.po.toshiba.co.jp>; Thu, 29 Jan 2004 03:05:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Alu2i-0003sR-00; Wed, 28 Jan 2004 10:04:00 -0800 Date: Wed, 28 Jan 2004 10:04:00 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040128180400.GF12912@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] pana specification snapshot (03b) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Updated PANA specification snapshot (draft-ietf-pana-pana-03b) is avalable at: http://www.toshiba.com/tari/pana/pana-spec.html Comments are appreciated. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Jan 28 13:09:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17675 for ; Wed, 28 Jan 2004 13:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu7b-00045V-8W for pana-archive@odin.ietf.org; Wed, 28 Jan 2004 13:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SI93d0015707 for pana-archive@odin.ietf.org; Wed, 28 Jan 2004 13:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu7b-00045G-3P for pana-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17620 for ; Wed, 28 Jan 2004 13:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu7Z-0007Xx-00 for pana-web-archive@ietf.org; Wed, 28 Jan 2004 13:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu6e-0007O3-00 for pana-web-archive@ietf.org; Wed, 28 Jan 2004 13:08:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alu5g-0007F9-00 for pana-web-archive@ietf.org; Wed, 28 Jan 2004 13:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5d-0003df-5k; Wed, 28 Jan 2004 13:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu5Z-0003a0-MA for pana@optimus.ietf.org; Wed, 28 Jan 2004 13:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17448 for ; Wed, 28 Jan 2004 13:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu5X-0007DX-00 for pana@ietf.org; Wed, 28 Jan 2004 13:06:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu4c-00076v-00 for pana@ietf.org; Wed, 28 Jan 2004 13:05:58 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Alu49-000708-00 for pana@ietf.org; Wed, 28 Jan 2004 13:05:29 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0SI5RN9024518; Thu, 29 Jan 2004 03:05:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0SI5RjD004329; Thu, 29 Jan 2004 03:05:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA04328 ; Thu, 29 Jan 2004 03:05:27 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA18357; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA17361; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0SI5Pgf005412; Thu, 29 Jan 2004 03:05:26 +0900 (JST) Received: from steelhead ([159.119.168.180]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS700GRBOWZ1O@tsbpo1.po.toshiba.co.jp>; Thu, 29 Jan 2004 03:05:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Alu2i-0003sR-00; Wed, 28 Jan 2004 10:04:00 -0800 Date: Wed, 28 Jan 2004 10:04:00 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040128180400.GF12912@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.4i Subject: [Pana] pana specification snapshot (03b) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Updated PANA specification snapshot (draft-ietf-pana-pana-03b) is avalable at: http://www.toshiba.com/tari/pana/pana-spec.html Comments are appreciated. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 29 09:27:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19062 for ; Thu, 29 Jan 2004 09:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD8F-0002qT-S7; Thu, 29 Jan 2004 09:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD7b-0002iK-T9 for pana@optimus.ietf.org; Thu, 29 Jan 2004 09:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18959 for ; Thu, 29 Jan 2004 09:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmD7Z-0002Se-00 for pana@ietf.org; Thu, 29 Jan 2004 09:26:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmD6b-0002KX-00 for pana@ietf.org; Thu, 29 Jan 2004 09:25:17 -0500 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AmD5c-0002AM-00 for pana@ietf.org; Thu, 29 Jan 2004 09:24:16 -0500 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 0C65B2FBB0; Thu, 29 Jan 2004 15:23:43 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004012915234310742 ; Thu, 29 Jan 2004 15:23:43 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id ED5FC2FBB0; Thu, 29 Jan 2004 15:23:42 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AmD31-000IJS-R5; Thu, 29 Jan 2004 15:21:35 +0100 Date: Thu, 29 Jan 2004 15:21:35 +0100 From: Julien Bournelle To: yohba@tari.toshiba.com Cc: pana@ietf.org Subject: Re: [Pana] comments on pana-03a Message-ID: <20040129142135.GH70159@ipv6-5.int-evry.fr> References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> <20040127011853.GJ29975@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040127011853.GJ29975@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi yoshihiro, On Mon, Jan 26, 2004 at 05:18:53PM -0800, Yoshihiro Ohba wrote: > > > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > > not set the S-FLag ? > > > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > > I will add this explicit text. > > > > ok, but in this case, which EAP authentication occurs ? (ISP ?) > > I think in this case there is no distinction between NAP and ISP > authentication (but the PaC can still declare its desire to use > specific ISP). well, I'm not sure to well understand.. if the PAA sets the S-flag, it means that there is a distinction between NAP and ISP. So, if the pac does not the S-flag, I can understand that there is only one EAP authentication but either the NAP or the ISP couldn't authenticate this pac. Do I miss something ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 29 09:29:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19154 for ; Thu, 29 Jan 2004 09:29:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD9m-0002xI-62 for pana-archive@odin.ietf.org; Thu, 29 Jan 2004 09:28:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TESY5G011356 for pana-archive@odin.ietf.org; Thu, 29 Jan 2004 09:28:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD9m-0002x5-1Y for pana-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 09:28:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19131 for ; Thu, 29 Jan 2004 09:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmD9k-0002mE-00 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 09:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmD8l-0002di-00 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 09:27:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmD8L-0002WL-00 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 09:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD8F-0002qT-S7; Thu, 29 Jan 2004 09:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmD7b-0002iK-T9 for pana@optimus.ietf.org; Thu, 29 Jan 2004 09:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18959 for ; Thu, 29 Jan 2004 09:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmD7Z-0002Se-00 for pana@ietf.org; Thu, 29 Jan 2004 09:26:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmD6b-0002KX-00 for pana@ietf.org; Thu, 29 Jan 2004 09:25:17 -0500 Received: from sparte.int-evry.fr ([157.159.10.11]) by ietf-mx with esmtp (Exim 4.12) id 1AmD5c-0002AM-00 for pana@ietf.org; Thu, 29 Jan 2004 09:24:16 -0500 Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 0C65B2FBB0; Thu, 29 Jan 2004 15:23:43 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.1.0.29) with SMTP id M2004012915234310742 ; Thu, 29 Jan 2004 15:23:43 +0100 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by sparte.int-evry.fr (Postfix) with ESMTP id ED5FC2FBB0; Thu, 29 Jan 2004 15:23:42 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1AmD31-000IJS-R5; Thu, 29 Jan 2004 15:21:35 +0100 Date: Thu, 29 Jan 2004 15:21:35 +0100 From: Julien Bournelle To: yohba@tari.toshiba.com Cc: pana@ietf.org Subject: Re: [Pana] comments on pana-03a Message-ID: <20040129142135.GH70159@ipv6-5.int-evry.fr> References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> <20040127011853.GJ29975@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040127011853.GJ29975@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi yoshihiro, On Mon, Jan 26, 2004 at 05:18:53PM -0800, Yoshihiro Ohba wrote: > > > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > > not set the S-FLag ? > > > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > > I will add this explicit text. > > > > ok, but in this case, which EAP authentication occurs ? (ISP ?) > > I think in this case there is no distinction between NAP and ISP > authentication (but the PaC can still declare its desire to use > specific ISP). well, I'm not sure to well understand.. if the PAA sets the S-flag, it means that there is a distinction between NAP and ISP. So, if the pac does not the S-flag, I can understand that there is only one EAP authentication but either the NAP or the ISP couldn't authenticate this pac. Do I miss something ? -- julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Jan 29 12:38:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03708 for ; Thu, 29 Jan 2004 12:38:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG77-0000OM-BK; Thu, 29 Jan 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG6a-0000BX-Gv for pana@optimus.ietf.org; Thu, 29 Jan 2004 12:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03648 for ; Thu, 29 Jan 2004 12:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmG6Y-0005pH-00 for pana@ietf.org; Thu, 29 Jan 2004 12:37:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmG5g-0005jU-00 for pana@ietf.org; Thu, 29 Jan 2004 12:36:33 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AmG53-0005dV-00 for pana@ietf.org; Thu, 29 Jan 2004 12:35:53 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0THZpN9014740; Fri, 30 Jan 2004 02:35:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0THZpXe021060; Fri, 30 Jan 2004 02:35:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA21059 ; Fri, 30 Jan 2004 02:35:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA23211; Fri, 30 Jan 2004 02:35:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA08058; Fri, 30 Jan 2004 02:35:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0THZnvb001059; Fri, 30 Jan 2004 02:35:49 +0900 (JST) Received: from steelhead ([159.119.168.155]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS90022MI7N7S@tsbpo1.po.toshiba.co.jp>; Fri, 30 Jan 2004 02:35:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AmG3S-0005Zb-00; Thu, 29 Jan 2004 09:34:14 -0800 Date: Thu, 29 Jan 2004 09:34:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040129142135.GH70159@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040129173414.GB12912@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> <20040127011853.GJ29975@steelhead> <20040129142135.GH70159@ipv6-5.int-evry.fr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Jan 29, 2004 at 03:21:35PM +0100, Julien Bournelle wrote: > Hi yoshihiro, > > On Mon, Jan 26, 2004 at 05:18:53PM -0800, Yoshihiro Ohba wrote: > > > > > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > > > not set the S-FLag ? > > > > > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > > > I will add this explicit text. > > > > > > ok, but in this case, which EAP authentication occurs ? (ISP ?) > > > > I think in this case there is no distinction between NAP and ISP > > authentication (but the PaC can still declare its desire to use > > specific ISP). > > well, I'm not sure to well understand.. if the PAA sets the S-flag, it > means that there is a distinction between NAP and ISP. So, if the pac > does not the S-flag, I can understand that there is only one EAP > authentication but either the NAP or the ISP couldn't authenticate this > pac. Do I miss something ? If the PAA sets the S-flag, it means that a distinction between NAP and ISP will be made if the PaC aggrees to have the distinction. If the PaC does not set the S-flag, it means the PaC did not agree to have the distinction, and no distinction is made as a consequence. Yoshihiro Ohba > > -- > julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Jan 29 12:45:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04155 for ; Thu, 29 Jan 2004 12:45:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGDh-0001eu-PN for pana-archive@odin.ietf.org; Thu, 29 Jan 2004 12:44:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THinS6006372 for pana-archive@odin.ietf.org; Thu, 29 Jan 2004 12:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGDh-0001eh-LM for pana-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04066 for ; Thu, 29 Jan 2004 12:44:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGDg-0006xx-00 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 12:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGBT-0006Q8-00 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 12:42:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGA8-00068L-05 for pana-web-archive@ietf.org; Thu, 29 Jan 2004 12:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG77-0000OM-BK; Thu, 29 Jan 2004 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmG6a-0000BX-Gv for pana@optimus.ietf.org; Thu, 29 Jan 2004 12:37:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03648 for ; Thu, 29 Jan 2004 12:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmG6Y-0005pH-00 for pana@ietf.org; Thu, 29 Jan 2004 12:37:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmG5g-0005jU-00 for pana@ietf.org; Thu, 29 Jan 2004 12:36:33 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AmG53-0005dV-00 for pana@ietf.org; Thu, 29 Jan 2004 12:35:53 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i0THZpN9014740; Fri, 30 Jan 2004 02:35:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i0THZpXe021060; Fri, 30 Jan 2004 02:35:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA21059 ; Fri, 30 Jan 2004 02:35:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA23211; Fri, 30 Jan 2004 02:35:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA08058; Fri, 30 Jan 2004 02:35:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i0THZnvb001059; Fri, 30 Jan 2004 02:35:49 +0900 (JST) Received: from steelhead ([159.119.168.155]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HS90022MI7N7S@tsbpo1.po.toshiba.co.jp>; Fri, 30 Jan 2004 02:35:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AmG3S-0005Zb-00; Thu, 29 Jan 2004 09:34:14 -0800 Date: Thu, 29 Jan 2004 09:34:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] comments on pana-03a In-reply-to: <20040129142135.GH70159@ipv6-5.int-evry.fr> To: Julien Bournelle Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040129173414.GB12912@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Julien Bournelle , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <20040123151746.GF49972@ipv6-5.int-evry.fr> <20040123163713.GQ26285@steelhead> <20040126131908.GH59634@ipv6-5.int-evry.fr> <20040127011853.GJ29975@steelhead> <20040129142135.GH70159@ipv6-5.int-evry.fr> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Jan 29, 2004 at 03:21:35PM +0100, Julien Bournelle wrote: > Hi yoshihiro, > > On Mon, Jan 26, 2004 at 05:18:53PM -0800, Yoshihiro Ohba wrote: > > > > > > On Fri, Jan 23, 2004 at 08:37:14AM -0800, Yoshihiro Ohba wrote: > > > > > > > > > > -1- The PAA set the S-flag if we want to do ISP and NAP authentication > > > > > and the PaC set the S-flag if it is ok. But what do we do if pac does > > > > > not set the S-FLag ? > > > > > > > > When PaC does not set the S-fLag, only one EAP authentication occurs. > > > > I will add this explicit text. > > > > > > ok, but in this case, which EAP authentication occurs ? (ISP ?) > > > > I think in this case there is no distinction between NAP and ISP > > authentication (but the PaC can still declare its desire to use > > specific ISP). > > well, I'm not sure to well understand.. if the PAA sets the S-flag, it > means that there is a distinction between NAP and ISP. So, if the pac > does not the S-flag, I can understand that there is only one EAP > authentication but either the NAP or the ISP couldn't authenticate this > pac. Do I miss something ? If the PAA sets the S-flag, it means that a distinction between NAP and ISP will be made if the PaC aggrees to have the distinction. If the PaC does not set the S-flag, it means the PaC did not agree to have the distinction, and no distinction is made as a consequence. Yoshihiro Ohba > > -- > julien.bournelle@int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana