From pana-request@research.telcordia.com Wed Jun 4 18:38:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16344 for ; Wed, 4 Jun 2003 18:38:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h54MYIV9023846; Wed, 4 Jun 2003 18:34:18 -0400 (EDT) Resent-Date: Wed, 4 Jun 2003 18:34:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 04 Jun 2003 15:35:22 -0700 Subject: comments on the requirements I-D From: Alper Yegin To: pana Message-ID: In-Reply-To: <200306031357.h53DvZof081157@givry.rennes.enst-bretagne.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA16344 These are Francis Dupont's comments on the PANA requirements draft. Thanks Francis! Alper ------ Forwarded Message From: Francis Dupont Date: Tue, 03 Jun 2003 15:57:35 +0200 To: Alper Yegin Cc: "Patil Basavaraj (NET/Dallas)" Subject: Re: last call In draft-ietf-pana-requirements-06.txt: - 3. Terminology (possible spelling error) link-layer address, switch port number, etc. of a connected ^ comma? - same (wording) The entity whose responsibility is to authenticate the credentials provided by a PANA client and grant network => the object of the authentication is not the credentials, I propose something like "verify" in place of "authenticate" but this is an English terminology pb (so ask a native :-). See 4.1.1 intro too. - 4.1.1. Authentication of Client (wording) authenticating the PaC is not sufficient. Mutual authentication capability is necessary in some environments but not in all of them. => s/necessary/required/ ? I have a little concern about the wording, to summary (from 802.1aa D5): "It should also be noted that from the point of view of security, two one-way authentication exchanges in each direction are not equivalent to a single mutual authentication exchange, since the two one-way authentication exchanges are not cryptographically bound together." So I propose to change: Both the PaC and the PAA MUST be able to authenticate each other for into something like Both the PaC and the PAA MUST be able to perform a mutual authentication for - 4.1.2. Authorization, Accounting and Access Control (Microsoft bug) verify the authorization of a PaC so that PaC’s device may send and ^ use a ' - idem (question) check why RADIUS and Diameter use different cases (IMHO the reason is that RADIUS is an abbrev and Diameter a full name). - 4.1.4. Identifiers (wording) PaCI (e.g., username, NAI, FQDN, etc.). This requirement generally => if (and only if :-) someone complains about jargon usage, replace FQDN by something else (like DNS name). - 4.2. IP Address Assignment (wording) address before using this protocol. Allocating an IP address to unauthenticated PaCs may create security vulnerabilities, such as IP => either "IP addresses" or "an unauthenticated PaC" (IMHO all plural is the best as the issue involves repetition). - 4.4. PAA-to-EP Protocol (wording) PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-to-EP protocol ^^ exchange per PaC) or the push model (i.e., PAA initiating the - same (same) same => IMHO "either" introduces an "exclusive or" so I dislike the final "or both". (again, ask a native :-) - same (possible spelling error) end of a successful PANA exchange without the EP ever sending a ^^^^ even? - 4.6. Interaction with Other Protocols (wording) be able to co-exist and not interfere with various mobility ^ add "badly" here => rationale: good interferences should be allowed. - same (same) [DHCP]. It MUST NOT make any assumptions on the protocols or => add DHCPV6, i.e., s/[DHCP]/[DHCP,DHCPV6]/ - 5. Security Considerations (wording) => please add here a reference to [SECTHREAT]! - 8.2. Informative References (refs) => please update the 8021X reference (the IEEE standard is no more a draft!) - same (same) => please add a reference for [DHCPV6] Thanks Francis.Dupont@enst-bretagne.fr ------ End of Forwarded Message From pana-request@research.telcordia.com Wed Jun 4 20:42:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20036 for ; Wed, 4 Jun 2003 20:42:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h550dJX7002121; Wed, 4 Jun 2003 20:39:19 -0400 (EDT) Resent-Date: Wed, 4 Jun 2003 20:39:19 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 04 Jun 2003 17:40:08 -0700 Subject: FW: comments on the requirements I-D From: Alper Yegin To: pana Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Francis, I agree with all, except .... please see below.. > - 4.6. Interaction with Other Protocols (wording) > be able to co-exist and not interfere with various mobility > ^ add "badly" here > > => rationale: good interferences should be allowed. I'm not sure what would be an example of good interference. I can say "PANA should not untentionally interfere", rather than getting into good vs.bad interference. Alper From pana-request@research.telcordia.com Wed Jun 4 20:46:43 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20166 for ; Wed, 4 Jun 2003 20:46:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h550iNr3002407; Wed, 4 Jun 2003 20:44:23 -0400 (EDT) Resent-Date: Wed, 4 Jun 2003 20:44:23 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 04 Jun 2003 17:45:09 -0700 Subject: Re: last call review of PANA Requirements document. From: Alper Yegin To: pana CC: , Bernard Aboba Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit And these are Bernard Aboba's comments. Thanks Bernard! (sorry for late fwds. I was away from the office until today) Alper On 5/30/03 9:47 PM, "Bernard Aboba" wrote: > OK. Here are my comments. Since some of them are based on the AAA keying > requirements presented by Russ Housley at IETF 56, I'm CC:'ing Russ. > > " The protocol design will be limited to defining a client-server > messaging protocol (i.e., a carrier) that will allow authentication > payload to be carried between the host/client and an agent/server in > the access network for authentication and authorization purposes > regardless of the AAA infrastructure that may (or may not) reside on > the network. As a network-layer protocol, it will be independent of > the underlying access technologies. It will also be applicable to > any network topology." > > Is it really a requirement that the protocol by assymetric > (client/server)? For example, EAP is a peer-to-peer protocol. I ask this > because certain wireless scenarios such as adhoc are inherently symmetric, > and it may be awkward to solve these problems with a client/server > protocol. > > " The Working Group will not invent new security protocols and > mechanisms but instead it will use the existing mechanisms. In > particular, the Working Group will not define new authentication > protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key > agreement protocols, or key derivation methods." > > EAP and AAA only provide two legs of the security > relationship between the EAP peer, Authenticator and AAA server. The > third leg is the "secure association" protocol that negotiates the > security association (including ciphersuites and other communications > characteristics) between the EAP peer and authenticator. In this > regard, EAP is similar to IKE Phase 1 (authentication and keying > material) while the "secure association" protocol is like IKE Phase 2 > (security parameter negotiation). An example of a "secure association" > protocol is the IEEE 802.11i 4-way handshake. > > In general, the properties of the "secure association" protocol > (such as mutual authentication and guaranteed freshness of transient > session keys) are critical to the overall security of the system. So > unless PANA is planning on reusing or repurposing the 4-way handshake, > where EAP is being used to generate keys on a physically insecure link, > it's difficult to see how the overall system will be able to meet > the AAA key requirements presented at IETF 56. > > "PANA MUST only grant network access > service to the device identified by the DI, rather than granting > separate access to multiple simultaneous users of the device." > > I'm not clear why PANA requires that only a single security association > can exist between a PANA client and potential endpoints. In protocols > such as PPPOE it is possible for multiple services to exist on the same > wire and for a client to connect to multiple such services, with separate > security associations for each. Whether the security associations apply > to the machine as a whole or individual users is really an operating > system issue, not something that the PANA protocol should care about. > > " > Providing authentication, integrity and replay protection for data > traffic after a successful PANA exchange is outside the scope of > this protocol. In networks where physical layer security is not > present, link-layer or network-layer (e.g., IPsec) ciphering can be > used to provide such security. These mechanisms require presence of > cryptographic keying material at PaC and EP, which can be generated > by various EAP methods." > > The last sentence seems to imply that EAP by itself is sufficient to > provide keying material for a ciphersuite. In general, this is not the > case. EAP provides only authentication and basic keying material, but > does not negotiate the properties of the security association, or > guarantee liveness in cases where keying material is cached, > This is the task of the "secure association" protocol. Given the critical > role of this "third leg" of the EAP/AAA triangle, it seems to me that if > PANA is using EAP for key generation that either a "secure association" > protocol is supplied or the protocol will not meet the security > requirements. > > For example, without a "secure association" protocol to guarantee > freshness of transient keys, it is possible that transient keys will be > reused, > compromising security. > > "Although PANA does not deal with key > derivation or distribution, it indirectly enables this by the virtue > of carrying EAP. " > > EAP is not sufficient for key derivation or exchange on physically > insecure media -- a "secure association" protocol is required in addition. > > "The keying material produced by EAP methods cannot > be directly used with IPsec. In that case these initial keys can be > used with an IPsec key management protocol like IKE to generate the > required security associations." > > The use of EAP to generate IKE pre-shared keys does take care of the need > for a "secure association" protocol since IKE Phase 2 takes on that role. > However there is still the need to specify exactly what EAP keying > material is used, and how it is processed. Overall, I think that > there is a lot that is being glossed over here. > > " After a device is authenticated using PANA, it MUST be authorized > for network access. That is, the core requirement of PANA is to > verify the authorization of a PaC so that PaCs device may send and > receive any IP packets." > > Using PANA for authorization seems to me to be problematic because EAP > assumes that access is allowed or denied based on the EAP authentication > process alone. We've already addressed conflicts between the AAA > result (Accept/Reject) and EAP result (Success/Failure) in RFC 2869bis, > and now in 2284bis we are having to reconcile the EAP method result with > the EAP result. Given this, adding a PANA authorization result as well > will just add to the confusion. > > "PANA SHOULD have a > mechanism to provide disconnect indication. When such indications > are not protected by means of physical or link-layer mechanisms, > PANA MUST ensure this protection to prevent attackers from > leveraging this extension for DoS attacks." > > Just as it is important to have a secure mechanism > for establishing a security association, it is also important to have a > secure mechanism for tearing one down. That is what a secure disconnect > indication is, and this is something that needs to be provided within > the same protocol as handles security association setup. So I'd claim > that PANA MUST deal with this regardless of physical or link-layer > mechanisms. > > "5. Security Considerations > > This document identifies requirements for the PANA protocol design. > Due to the nature of this protocol most of the requirements are > security related. The actual protocol design is not specified in > this document." > > I think there needs to be expanded discussion of issues relating to > keying, if in fact this is relevant to PANA. As noted earlier, once > EAP is used to generate keys on a physically insecure network, > a "third leg" is required, in addition to the EAP and AAA legs. After > reading this document I'm not clear about the requirements for that > leg or how PANA could be considered secure without such a leg. > From pana-request@research.telcordia.com Wed Jun 4 22:12:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22419 for ; Wed, 4 Jun 2003 22:12:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5529sK6007674; Wed, 4 Jun 2003 22:09:54 -0400 (EDT) Resent-Date: Wed, 4 Jun 2003 22:09:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 04 Jun 2003 19:10:42 -0700 Subject: Re: last call review of PANA Requirements document. From: Alper Yegin To: Bernard Aboba CC: Russ Housley , pana Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > " The protocol design will be limited to defining a client-server > messaging protocol (i.e., a carrier) that will allow authentication > payload to be carried between the host/client and an agent/server in > the access network for authentication and authorization purposes > regardless of the AAA infrastructure that may (or may not) reside on > the network. As a network-layer protocol, it will be independent of > the underlying access technologies. It will also be applicable to > any network topology." > > Is it really a requirement that the protocol by assymetric > (client/server)? For example, EAP is a peer-to-peer protocol. I ask this > because certain wireless scenarios such as adhoc are inherently symmetric, > and it may be awkward to solve these problems with a client/server > protocol. I don't think that was intentional. We don't mean to require that this is a strictly client-server design. Hence, I'd remove the term "client-server" from the text. > > " The Working Group will not invent new security protocols and > mechanisms but instead it will use the existing mechanisms. In > particular, the Working Group will not define new authentication > protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key > agreement protocols, or key derivation methods." > > EAP and AAA only provide two legs of the security > relationship between the EAP peer, Authenticator and AAA server. The > third leg is the "secure association" protocol that negotiates the > security association (including ciphersuites and other communications > characteristics) between the EAP peer and authenticator. In this > regard, EAP is similar to IKE Phase 1 (authentication and keying > material) while the "secure association" protocol is like IKE Phase 2 > (security parameter negotiation). An example of a "secure association" > protocol is the IEEE 802.11i 4-way handshake. > > In general, the properties of the "secure association" protocol > (such as mutual authentication and guaranteed freshness of transient > session keys) are critical to the overall security of the system. So > unless PANA is planning on reusing or repurposing the 4-way handshake, > where EAP is being used to generate keys on a physically insecure link, > it's difficult to see how the overall system will be able to meet > the AAA key requirements presented at IETF 56. Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue. There is already an I-D for this purpose: draft-mohanp-pana-ipsec-00.txt > > "PANA MUST only grant network access > service to the device identified by the DI, rather than granting > separate access to multiple simultaneous users of the device." > > I'm not clear why PANA requires that only a single security association > can exist between a PANA client and potential endpoints. In protocols > such as PPPOE it is possible for multiple services to exist on the same > wire and for a client to connect to multiple such services, with separate > security associations for each. Whether the security associations apply > to the machine as a whole or individual users is really an operating > system issue, not something that the PANA protocol should care about. Actually this requirement does not say one client is entitled to at most one security association. This text is meant to reflect what you point out in your last sentence. Regarding the PPPoE example, unless these users use different DIs (device identifiers), the enforcement points cannot distinguish one's traffic from the others'. So, as long as DIs are unique, there should not be a problem for PANA to deal with. > > " > Providing authentication, integrity and replay protection for data > traffic after a successful PANA exchange is outside the scope of > this protocol. In networks where physical layer security is not > present, link-layer or network-layer (e.g., IPsec) ciphering can be > used to provide such security. These mechanisms require presence of > cryptographic keying material at PaC and EP, which can be generated > by various EAP methods." > > The last sentence seems to imply that EAP by itself is sufficient to > provide keying material for a ciphersuite. In general, this is not the > case. EAP provides only authentication and basic keying material, but > does not negotiate the properties of the security association, or > guarantee liveness in cases where keying material is cached, We say that later: The keying material produced by EAP methods cannot be directly used with IPsec. But I see your point. I'd rewrite the relevant text (please see the bottom of this message) > This is the task of the "secure association" protocol. Given the critical > role of this "third leg" of the EAP/AAA triangle, it seems to me that if > PANA is using EAP for key generation that either a "secure association" > protocol is supplied or the protocol will not meet the security > requirements. > > For example, without a "secure association" protocol to guarantee > freshness of transient keys, it is possible that transient keys will be > reused, > compromising security. > > "Although PANA does not deal with key > derivation or distribution, it indirectly enables this by the virtue > of carrying EAP. " > > EAP is not sufficient for key derivation or exchange on physically > insecure media -- a "secure association" protocol is required in addition. OK. > > "The keying material produced by EAP methods cannot > be directly used with IPsec. In that case these initial keys can be > used with an IPsec key management protocol like IKE to generate the > required security associations." > > The use of EAP to generate IKE pre-shared keys does take care of the need > for a "secure association" protocol since IKE Phase 2 takes on that role. > However there is still the need to specify exactly what EAP keying > material is used, and how it is processed. Agreed. The PANA draft will specify how PANA SA is generated at the end of a successful PANA exchange. But PANA SA is not same as IPsec SA. A separate draft, like the one I referenced earlier, will define how PANA SA is turned into IPsec SA. > Overall, I think that > there is a lot that is being glossed over here. The details are left to the solution drafts. > > " After a device is authenticated using PANA, it MUST be authorized > for network access. That is, the core requirement of PANA is to > verify the authorization of a PaC so that PaCs device may send and > receive any IP packets." > > Using PANA for authorization seems to me to be problematic because EAP > assumes that access is allowed or denied based on the EAP authentication > process alone. Actually all this requirement says is that at the end of a PANA authentication, client is either authorized to access the network or not. It does not really say anythign regarding whether PANA carries authorization, or EAP carries authentication, etc. PANA can satisfy the above requirement by simply carrying EAP, and not carrying any other result codes. It may also have its own result field, but we need to deal with this issue separately. At least, this is not a requirements issue, I think. > We've already addressed conflicts between the AAA > result (Accept/Reject) and EAP result (Success/Failure) in RFC 2869bis, > and now in 2284bis we are having to reconcile the EAP method result with > the EAP result. Given this, adding a PANA authorization result as well > will just add to the confusion. I don't think this matter boils down to "PANA must not have an authorization result field", or the opposite. So, I'm not sure if this is for the requirements draft to deal with. [if the PANA result field proves not useful or problematic, we can remove it from the design] > > "PANA SHOULD have a > mechanism to provide disconnect indication. When such indications > are not protected by means of physical or link-layer mechanisms, > PANA MUST ensure this protection to prevent attackers from > leveraging this extension for DoS attacks." > > Just as it is important to have a secure mechanism > for establishing a security association, it is also important to have a > secure mechanism for tearing one down. That is what a secure disconnect > indication is, and this is something that needs to be provided within > the same protocol as handles security association setup. So I'd claim > that PANA MUST deal with this regardless of physical or link-layer > mechanisms. OK, I'd rewrite this text as: PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks. > > "5. Security Considerations > > This document identifies requirements for the PANA protocol design. > Due to the nature of this protocol most of the requirements are > security related. The actual protocol design is not specified in > this document." > > I think there needs to be expanded discussion of issues relating to > keying, if in fact this is relevant to PANA. As noted earlier, once > EAP is used to generate keys on a physically insecure network, > a "third leg" is required, in addition to the EAP and AAA legs. After > reading this document I'm not clear about the requirements for that > leg or how PANA could be considered secure without such a leg. Updated text for section 4.1.1: Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer (e.g., IPsec) ciphering can be used to provide such security. These mechanisms require presence of cryptographic keying material at PaC and EP. Although PANA does not deal with key derivation or distribution, it indirectly enables this by the virtue of carrying EAP. Various EAP methods are capable of generating basic keying material. The keying material produced by EAP methods cannot be directly used with IPsec as it lacks the properties of an IPsec SA (security association). These basic (initial) keys can be used with an IPsec key management protocol like IKE to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they are sent between the EP and PaC. Also, some updates for section 4.1.2: Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via access network. Access control can involve setting access control lists on the EPs. Identification of clients that are authorized to access the network is done by the PANA protocol exchange. If IPsec-based access control is deployed in an access network, PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs based on EAP keys is outside the scope of PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1). Alper From pana-request@research.telcordia.com Thu Jun 5 05:48:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12912 for ; Thu, 5 Jun 2003 05:47:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h559iI3B005108; Thu, 5 Jun 2003 05:44:18 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 05:44:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 5 Jun 2003 02:07:30 -0700 (PDT) Old-From: Bernard Aboba To: Alper Yegin cc: Russ Housley , pana Old-Subject: Re: last call review of PANA Requirements document. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) From: Subir Das Subject: Re: last call review of PANA Requirements document. [originally from Bernard Aboba] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue. > There is already an I-D for this purpose: draft-mohanp-pana-ipsec-00.txt Is it fair to say that the *only* intended use of PANA for keying is described by this document? > Regarding the PPPoE example, unless these users use different DIs (device > identifiers), the enforcement points cannot distinguish one's traffic from > the others'. So, as long as DIs are unique, there should not be a problem > for PANA to deal with. In this particular example, the "session identifier" can differentiate sessions between identical endpoints. Does this qualify as a "DI"? > The keying material produced by EAP methods cannot be directly used with > IPsec. > > But I see your point. I'd rewrite the relevant text (please see the bottom > of this message) The issue is that setup of an IPsec SA requires more than just keying material and authentication -- which is all EAP provides. > Agreed. The PANA draft will specify how PANA SA is generated at the end of a > successful PANA exchange. But PANA SA is not same as IPsec SA. A separate > draft, like the one I referenced earlier, will define how PANA SA is turned > into IPsec SA. Yes. The PANA SA only provides authentication and key material. You need another protocol to negotiate an IKE Phase 2 SA so as to be able to use IPsec. That protocol could of course be IKE itself. > > Overall, I think that > > there is a lot that is being glossed over here. > > The details are left to the solution drafts. That's fair -- but I think that you need to expand on the nature of the PANA SA and how it compares to an IKE Phase 1 and Phase 2 SA. > PANA can satisfy the above requirement by simply carrying EAP, and not > carrying any other result codes. It may also have its own result field, but > we need to deal with this issue separately. At least, this is not a > requirements issue, I think. OK. > [if the PANA result field proves not useful or problematic, we can remove it > from the design] Sure. I agree this is not a requirement. > OK, I'd rewrite this text as: > > PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST > be capable of securing disconnect messages in order to prevent malicious > nodes from leveraging this extension for DoS attacks. Yes, that's better. > Updated text for section 4.1.1: > > Providing authentication, integrity and replay protection for data > traffic after a successful PANA exchange is outside the scope of > this protocol. In networks where physical layer security is not > present, link-layer or network-layer (e.g., IPsec) ciphering can be > used to provide such security. These mechanisms require presence of > cryptographic keying material at PaC and EP. Although PANA does not deal > with key derivation or distribution, it indirectly enables this by the > virtue of carrying EAP. Various EAP methods are capable of generating > basic keying material. > > The keying material produced by EAP methods cannot be directly used with > IPsec as it lacks the properties of an IPsec SA (security association). which include secure ciphersuite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. > These basic (initial) keys can be used with an IPsec key management > protocol like IKE to generate the required security associations. A > separate protocol, called secure association protocol, is required to > generate IPsec SAs based on the basic EAP keys. This protocol MUST be > capable of enabling IPsec-based access control on the EPs. IPsec SAs > MUST enable authentication, integrity and replay protection of > data packets as they are sent between the EP and PaC. > From pana-request@research.telcordia.com Thu Jun 5 06:59:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14513 for ; Thu, 5 Jun 2003 06:59:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h55Atr3W013942; Thu, 5 Jun 2003 06:55:53 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 06:55:53 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: last call review of PANA Requirements document. Date: Thu, 5 Jun 2003 13:52:03 +0300 Message-ID: Thread-Topic: last call review of PANA Requirements document. Thread-Index: AcMrB7QnarsgKHfZSxCASVYh5YC5uwALyRFw From: To: , Cc: , X-OriginalArrivalTime: 05 Jun 2003 10:52:04.0036 (UTC) FILETIME=[7FF0A040:01C32B50] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA14513 Hi, Just a request for conclusion. The third leg (creating the SA) then is IKE in PANA scope? The first case where we need this SA is PANA SA! (IPSec is out of the scope of PANA). PANA has at least these building blocks: - Discovery (bootstrapping..) - Carry EAP (authentication) - Manage lifetimes (session management) - retransmissions, msg formatting, etc. (protocol core) - Use IKE(v2) (SA negotation)?? Now, PaC and PAA could do SA negotiation before the EAP provides the session key! When the SA parameters are negotiated the EAP session key is derived and used with the right SA parameters? Needles to say that there are other protocols that create SAs too, like TLS handshake. As Bernard pointed out we need to take a closer look to the key derivation problem in PANA. One question is, if the PANA session key should be independent of the key(s) it has been derived from? [otherwise it may be possible by knowing the EAP Session key and sniffing the link to create PANA SA]. Further more, if PANA SA is used to bootstrap other SAs, how to make sure that the derived SA is independent of PANA SA (conceptually similar case). The property that PANA SA could give is *authentication* (based on the EAP negotiation). So by creating the session key partly from the PANA SA would give this property to derived session keys. Br, - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 05 June, 2003 05:11 > To: Bernard Aboba > Cc: Russ Housley; pana > Subject: Re: last call review of PANA Requirements document. > > > > " The protocol design will be limited to defining a client-server > > messaging protocol (i.e., a carrier) that will allow authentication > > payload to be carried between the host/client and an > agent/server in > > the access network for authentication and authorization purposes > > regardless of the AAA infrastructure that may (or may not) > reside on > > the network. As a network-layer protocol, it will be independent of > > the underlying access technologies. It will also be applicable to > > any network topology." > > > > Is it really a requirement that the protocol by assymetric > > (client/server)? For example, EAP is a peer-to-peer > protocol. I ask this > > because certain wireless scenarios such as adhoc are > inherently symmetric, > > and it may be awkward to solve these problems with a client/server > > protocol. > > I don't think that was intentional. We don't mean to require > that this is a > strictly client-server design. Hence, I'd remove the term > "client-server" > from the text. > > > > > " The Working Group will not invent new security protocols and > > mechanisms but instead it will use the existing mechanisms. In > > particular, the Working Group will not define new authentication > > protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key > > agreement protocols, or key derivation methods." > > > > EAP and AAA only provide two legs of the security > > relationship between the EAP peer, Authenticator and AAA server. The > > third leg is the "secure association" protocol that negotiates the > > security association (including ciphersuites and other > communications > > characteristics) between the EAP peer and authenticator. In this > > regard, EAP is similar to IKE Phase 1 (authentication and keying > > material) while the "secure association" protocol is like > IKE Phase 2 > > (security parameter negotiation). An example of a "secure > association" > > protocol is the IEEE 802.11i 4-way handshake. > > > > In general, the properties of the "secure association" protocol > > (such as mutual authentication and guaranteed freshness of transient > > session keys) are critical to the overall security of the system. So > > unless PANA is planning on reusing or repurposing the 4-way > handshake, > > where EAP is being used to generate keys on a physically > insecure link, > > it's difficult to see how the overall system will be able to meet > > the AAA key requirements presented at IETF 56. > > Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue. > There is already an I-D for this purpose: > draft-mohanp-pana-ipsec-00.txt > > > > > "PANA MUST only grant network access > > service to the device identified by the DI, rather than granting > > separate access to multiple simultaneous users of the device." > > > > I'm not clear why PANA requires that only a single security > association > > can exist between a PANA client and potential endpoints. > In protocols > > such as PPPOE it is possible for multiple services to exist > on the same > > wire and for a client to connect to multiple such services, > with separate > > security associations for each. Whether the security > associations apply > > to the machine as a whole or individual users is really an operating > > system issue, not something that the PANA protocol should > care about. > > Actually this requirement does not say one client is entitled > to at most one > security association. This text is meant to reflect what you > point out in > your last sentence. > > Regarding the PPPoE example, unless these users use > different DIs (device > identifiers), the enforcement points cannot distinguish one's > traffic from > the others'. So, as long as DIs are unique, there should not > be a problem > for PANA to deal with. > > > > > " > > Providing authentication, integrity and replay protection for data > > traffic after a successful PANA exchange is outside the scope of > > this protocol. In networks where physical layer security is not > > present, link-layer or network-layer (e.g., IPsec) ciphering can be > > used to provide such security. These mechanisms require presence of > > cryptographic keying material at PaC and EP, which can be generated > > by various EAP methods." > > > > The last sentence seems to imply that EAP by itself is sufficient to > > provide keying material for a ciphersuite. In general, > this is not the > > case. EAP provides only authentication and basic keying > material, but > > does not negotiate the properties of the security association, or > > guarantee liveness in cases where keying material is cached, > > We say that later: > > The keying material produced by EAP methods cannot be > directly used with > IPsec. > > But I see your point. I'd rewrite the relevant text (please > see the bottom > of this message) > > > This is the task of the "secure association" protocol. > Given the critical > > role of this "third leg" of the EAP/AAA triangle, it seems > to me that if > > PANA is using EAP for key generation that either a "secure > association" > > protocol is supplied or the protocol will not meet the security > > requirements. > > > > For example, without a "secure association" protocol to guarantee > > freshness of transient keys, it is possible that transient > keys will be > > reused, > > compromising security. > > > > "Although PANA does not deal with key > > derivation or distribution, it indirectly enables this by > the virtue > > of carrying EAP. " > > > > EAP is not sufficient for key derivation or exchange on physically > > insecure media -- a "secure association" protocol is > required in addition. > > OK. > > > > > "The keying material produced by EAP methods cannot > > be directly used with IPsec. In that case these initial keys can be > > used with an IPsec key management protocol like IKE to generate the > > required security associations." > > > > The use of EAP to generate IKE pre-shared keys does take > care of the need > > for a "secure association" protocol since IKE Phase 2 takes > on that role. > > However there is still the need to specify exactly what EAP keying > > material is used, and how it is processed. > > Agreed. The PANA draft will specify how PANA SA is generated > at the end of a > successful PANA exchange. But PANA SA is not same as IPsec > SA. A separate > draft, like the one I referenced earlier, will define how > PANA SA is turned > into IPsec SA. > > > Overall, I think that > > there is a lot that is being glossed over here. > > The details are left to the solution drafts. > > > > > " After a device is authenticated using PANA, it MUST be > authorized > > for network access. That is, the core requirement of PANA is to > > verify the authorization of a PaC so that PaCs device may send and > > receive any IP packets." > > > > Using PANA for authorization seems to me to be problematic > because EAP > > assumes that access is allowed or denied based on the EAP > authentication > > process alone. > > Actually all this requirement says is that at the end of a PANA > authentication, client is either authorized to access the > network or not. It > does not really say anythign regarding whether PANA carries > authorization, > or EAP carries authentication, etc. > > PANA can satisfy the above requirement by simply carrying EAP, and not > carrying any other result codes. It may also have its own > result field, but > we need to deal with this issue separately. At least, this is not a > requirements issue, I think. > > > We've already addressed conflicts between the AAA > > result (Accept/Reject) and EAP result (Success/Failure) in > RFC 2869bis, > > and now in 2284bis we are having to reconcile the EAP > method result with > > the EAP result. Given this, adding a PANA authorization > result as well > > will just add to the confusion. > > I don't think this matter boils down to "PANA must not have > an authorization > result field", or the opposite. So, I'm not sure if this is for the > requirements draft to deal with. > > [if the PANA result field proves not useful or problematic, > we can remove it > from the design] > > > > > "PANA SHOULD have a > > mechanism to provide disconnect indication. When such indications > > are not protected by means of physical or link-layer mechanisms, > > PANA MUST ensure this protection to prevent attackers from > > leveraging this extension for DoS attacks." > > > > Just as it is important to have a secure mechanism > > for establishing a security association, it is also > important to have a > > secure mechanism for tearing one down. That is what a > secure disconnect > > indication is, and this is something that needs to be > provided within > > the same protocol as handles security association setup. So > I'd claim > > that PANA MUST deal with this regardless of physical or link-layer > > mechanisms. > > OK, I'd rewrite this text as: > > PANA SHOULD have a mechanism to provide disconnect > indication. PANA MUST > be capable of securing disconnect messages in order to > prevent malicious > nodes from leveraging this extension for DoS attacks. > > > > > > "5. Security Considerations > > > > This document identifies requirements for the PANA protocol design. > > Due to the nature of this protocol most of the requirements are > > security related. The actual protocol design is not specified in > > this document." > > > > I think there needs to be expanded discussion of issues relating to > > keying, if in fact this is relevant to PANA. As noted earlier, once > > EAP is used to generate keys on a physically insecure network, > > a "third leg" is required, in addition to the EAP and AAA > legs. After > > reading this document I'm not clear about the requirements for that > > leg or how PANA could be considered secure without such a leg. > > Updated text for section 4.1.1: > > Providing authentication, integrity and replay protection for data > traffic after a successful PANA exchange is outside the scope of > this protocol. In networks where physical layer security is not > present, link-layer or network-layer (e.g., IPsec) ciphering can be > used to provide such security. These mechanisms require presence of > cryptographic keying material at PaC and EP. Although PANA > does not deal > with key derivation or distribution, it indirectly enables > this by the > virtue of carrying EAP. Various EAP methods are capable of > generating > basic keying material. > > The keying material produced by EAP methods cannot be > directly used with > IPsec as it lacks the properties of an IPsec SA (security > association). > These basic (initial) keys can be used with an IPsec key management > protocol like IKE to generate the required security > associations. A > separate protocol, called secure association protocol, is > required to > generate IPsec SAs based on the basic EAP keys. This > protocol MUST be > capable of enabling IPsec-based access control on the EPs. > IPsec SAs > MUST enable authentication, integrity and replay protection of > data packets as they are sent between the EP and PaC. > > Also, some updates for section 4.1.2: > > Providing access control functionality in the network is > outside the > scope of PANA. Client access authentication SHOULD be followed by > access control to make sure only authenticated and authorized > clients can send and receive IP packets via access network. Access > control can involve setting access control lists on the EPs. > Identification of clients that are authorized to access the network > is done by the PANA protocol exchange. If IPsec-based > access control is > deployed in an access network, PaC and EPs should have the > required IPsec > SA in place. Generating the IPsec SAs based on EAP keys is > outside the > scope of PANA protocol. This transformation MUST be handled by a > separate secure association protocol (see section 4.1.1). > > > Alper > > From pana-request@research.telcordia.com Thu Jun 5 15:02:26 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11065 for ; Thu, 5 Jun 2003 15:02:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h55IxB0a016411; Thu, 5 Jun 2003 14:59:11 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 14:59:11 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 05 Jun 2003 12:00:01 -0700 Subject: Re: last call review of PANA Requirements document. [originally from Bernard Aboba] From: Alper Yegin To: Bernard Aboba CC: Russ Housley , pana Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue. >> There is already an I-D for this purpose: draft-mohanp-pana-ipsec-00.txt > > Is it fair to say that the *only* intended use of PANA for keying is > described by this document? No. This draft describes using PANA for keying for access control (IPsec). This is what is needed for PANA WG. There are other potential consumers of keying, such as bootstraping RFC3118 for DHCP security, but that is not for PANA WG. It solves a problem for DHCP WG. > >> Regarding the PPPoE example, unless these users use different DIs (device >> identifiers), the enforcement points cannot distinguish one's traffic from >> the others'. So, as long as DIs are unique, there should not be a problem >> for PANA to deal with. > > In this particular example, the "session identifier" can differentiate > sessions between identical endpoints. Does this qualify as a "DI"? I don't see why not. > >> The keying material produced by EAP methods cannot be directly used with >> IPsec. >> >> But I see your point. I'd rewrite the relevant text (please see the bottom >> of this message) > > The issue is that setup of an IPsec SA requires more than just keying > material and authentication -- which is all EAP provides. > >> Agreed. The PANA draft will specify how PANA SA is generated at the end of a >> successful PANA exchange. But PANA SA is not same as IPsec SA. A separate >> draft, like the one I referenced earlier, will define how PANA SA is turned >> into IPsec SA. > > Yes. The PANA SA only provides authentication and key material. You need > another protocol to negotiate an IKE Phase 2 SA so as to be able to use IPsec. > That protocol could of course be IKE itself. > >>> Overall, I think that >>> there is a lot that is being glossed over here. >> >> The details are left to the solution drafts. > > That's fair -- but I think that you need to expand on the nature of the > PANA SA and how it compares to an IKE Phase 1 and Phase 2 SA. > >> PANA can satisfy the above requirement by simply carrying EAP, and not >> carrying any other result codes. It may also have its own result field, but >> we need to deal with this issue separately. At least, this is not a >> requirements issue, I think. > > OK. > >> [if the PANA result field proves not useful or problematic, we can remove it >> from the design] > > Sure. I agree this is not a requirement. > >> OK, I'd rewrite this text as: >> >> PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST >> be capable of securing disconnect messages in order to prevent malicious >> nodes from leveraging this extension for DoS attacks. > > Yes, that's better. > >> Updated text for section 4.1.1: >> >> Providing authentication, integrity and replay protection for data >> traffic after a successful PANA exchange is outside the scope of >> this protocol. In networks where physical layer security is not >> present, link-layer or network-layer (e.g., IPsec) ciphering can be >> used to provide such security. These mechanisms require presence of >> cryptographic keying material at PaC and EP. Although PANA does not deal >> with key derivation or distribution, it indirectly enables this by the >> virtue of carrying EAP. Various EAP methods are capable of generating >> basic keying material. >> >> The keying material produced by EAP methods cannot be directly used with >> IPsec as it lacks the properties of an IPsec SA (security association). > which include secure ciphersuite negotiation, mutual proof of possession > of keying material, freshness of transient session keys, key naming, etc. I will add these to the text. > >> These basic (initial) keys can be used with an IPsec key management >> protocol like IKE to generate the required security associations. A >> separate protocol, called secure association protocol, is required to >> generate IPsec SAs based on the basic EAP keys. This protocol MUST be >> capable of enabling IPsec-based access control on the EPs. IPsec SAs >> MUST enable authentication, integrity and replay protection of >> data packets as they are sent between the EP and PaC. >> Alper From pana-request@research.telcordia.com Thu Jun 5 15:11:15 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12055 for ; Thu, 5 Jun 2003 15:11:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h55J7wHG016982; Thu, 5 Jun 2003 15:07:58 -0400 (EDT) Resent-Date: Thu, 5 Jun 2003 15:07:58 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 05 Jun 2003 12:08:52 -0700 Subject: Re: last call review of PANA Requirements document. From: Alper Yegin To: , CC: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, > Just a request for conclusion. The third leg (creating the SA) then is IKE in > PANA scope? Creating an "IPsec SA for access control" might be done by IKE, as proposed in draft-mohanp-pana-ipsec-00.txt. This is not same as PANA SA, which is created at the end of EAP authentication over PANA. > The first case where we need this SA is PANA SA! (IPSec is out of > the scope of PANA). > > PANA has at least these building blocks: > - Discovery (bootstrapping..) > - Carry EAP (authentication) > - Manage lifetimes (session management) > - retransmissions, msg formatting, etc. (protocol core) > - Use IKE(v2) (SA negotation)?? No, this last piece is not part of the PANA protocol. It is separately done by another mechanism, like draft-mohanp-pana-ipsec-00.txt, only when needed. The resultant SA is IPsec SA for access control. > > Now, PaC and PAA could do SA negotiation before the EAP provides the session > key! When the SA parameters are negotiated the EAP session key is derived and > used with the right SA parameters? please see above... > > Needles to say that there are other protocols that create SAs too, like TLS > handshake. > > As Bernard pointed out we need to take a closer look to the key derivation > problem in PANA. One question is, if the PANA session key should be > independent of the key(s) it has been derived from? [otherwise it may be > possible by knowing the EAP Session key and sniffing the link to create PANA > SA]. Further more, if PANA SA is used to bootstrap other SAs, how to make sure > that the derived SA is independent of PANA SA (conceptually similar case). Yes. > > The property that PANA SA could give is *authentication* (based on the EAP > negotiation). So by creating the session key partly from the PANA SA would > give this property to derived session keys. Yes. Alper > > > Br, > - Dan > > > > > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 05 June, 2003 05:11 >> To: Bernard Aboba >> Cc: Russ Housley; pana >> Subject: Re: last call review of PANA Requirements document. >> >> >>> " The protocol design will be limited to defining a client-server >>> messaging protocol (i.e., a carrier) that will allow authentication >>> payload to be carried between the host/client and an >> agent/server in >>> the access network for authentication and authorization purposes >>> regardless of the AAA infrastructure that may (or may not) >> reside on >>> the network. As a network-layer protocol, it will be independent of >>> the underlying access technologies. It will also be applicable to >>> any network topology." >>> >>> Is it really a requirement that the protocol by assymetric >>> (client/server)? For example, EAP is a peer-to-peer >> protocol. I ask this >>> because certain wireless scenarios such as adhoc are >> inherently symmetric, >>> and it may be awkward to solve these problems with a client/server >>> protocol. >> >> I don't think that was intentional. We don't mean to require >> that this is a >> strictly client-server design. Hence, I'd remove the term >> "client-server" >> from the text. >> >>> >>> " The Working Group will not invent new security protocols and >>> mechanisms but instead it will use the existing mechanisms. In >>> particular, the Working Group will not define new authentication >>> protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key >>> agreement protocols, or key derivation methods." >>> >>> EAP and AAA only provide two legs of the security >>> relationship between the EAP peer, Authenticator and AAA server. The >>> third leg is the "secure association" protocol that negotiates the >>> security association (including ciphersuites and other >> communications >>> characteristics) between the EAP peer and authenticator. In this >>> regard, EAP is similar to IKE Phase 1 (authentication and keying >>> material) while the "secure association" protocol is like >> IKE Phase 2 >>> (security parameter negotiation). An example of a "secure >> association" >>> protocol is the IEEE 802.11i 4-way handshake. >>> >>> In general, the properties of the "secure association" protocol >>> (such as mutual authentication and guaranteed freshness of transient >>> session keys) are critical to the overall security of the system. So >>> unless PANA is planning on reusing or repurposing the 4-way >> handshake, >>> where EAP is being used to generate keys on a physically >> insecure link, >>> it's difficult to see how the overall system will be able to meet >>> the AAA key requirements presented at IETF 56. >> >> Agreed. 3rd paragraph of section 4.1.1 is meant to address this issue. >> There is already an I-D for this purpose: >> draft-mohanp-pana-ipsec-00.txt >> >>> >>> "PANA MUST only grant network access >>> service to the device identified by the DI, rather than granting >>> separate access to multiple simultaneous users of the device." >>> >>> I'm not clear why PANA requires that only a single security >> association >>> can exist between a PANA client and potential endpoints. >> In protocols >>> such as PPPOE it is possible for multiple services to exist >> on the same >>> wire and for a client to connect to multiple such services, >> with separate >>> security associations for each. Whether the security >> associations apply >>> to the machine as a whole or individual users is really an operating >>> system issue, not something that the PANA protocol should >> care about. >> >> Actually this requirement does not say one client is entitled >> to at most one >> security association. This text is meant to reflect what you >> point out in >> your last sentence. >> >> Regarding the PPPoE example, unless these users use >> different DIs (device >> identifiers), the enforcement points cannot distinguish one's >> traffic from >> the others'. So, as long as DIs are unique, there should not >> be a problem >> for PANA to deal with. >> >>> >>> " >>> Providing authentication, integrity and replay protection for data >>> traffic after a successful PANA exchange is outside the scope of >>> this protocol. In networks where physical layer security is not >>> present, link-layer or network-layer (e.g., IPsec) ciphering can be >>> used to provide such security. These mechanisms require presence of >>> cryptographic keying material at PaC and EP, which can be generated >>> by various EAP methods." >>> >>> The last sentence seems to imply that EAP by itself is sufficient to >>> provide keying material for a ciphersuite. In general, >> this is not the >>> case. EAP provides only authentication and basic keying >> material, but >>> does not negotiate the properties of the security association, or >>> guarantee liveness in cases where keying material is cached, >> >> We say that later: >> >> The keying material produced by EAP methods cannot be >> directly used with >> IPsec. >> >> But I see your point. I'd rewrite the relevant text (please >> see the bottom >> of this message) >> >>> This is the task of the "secure association" protocol. >> Given the critical >>> role of this "third leg" of the EAP/AAA triangle, it seems >> to me that if >>> PANA is using EAP for key generation that either a "secure >> association" >>> protocol is supplied or the protocol will not meet the security >>> requirements. >>> >>> For example, without a "secure association" protocol to guarantee >>> freshness of transient keys, it is possible that transient >> keys will be >>> reused, >>> compromising security. >>> >>> "Although PANA does not deal with key >>> derivation or distribution, it indirectly enables this by >> the virtue >>> of carrying EAP. " >>> >>> EAP is not sufficient for key derivation or exchange on physically >>> insecure media -- a "secure association" protocol is >> required in addition. >> >> OK. >> >>> >>> "The keying material produced by EAP methods cannot >>> be directly used with IPsec. In that case these initial keys can be >>> used with an IPsec key management protocol like IKE to generate the >>> required security associations." >>> >>> The use of EAP to generate IKE pre-shared keys does take >> care of the need >>> for a "secure association" protocol since IKE Phase 2 takes >> on that role. >>> However there is still the need to specify exactly what EAP keying >>> material is used, and how it is processed. >> >> Agreed. The PANA draft will specify how PANA SA is generated >> at the end of a >> successful PANA exchange. But PANA SA is not same as IPsec >> SA. A separate >> draft, like the one I referenced earlier, will define how >> PANA SA is turned >> into IPsec SA. >> >>> Overall, I think that >>> there is a lot that is being glossed over here. >> >> The details are left to the solution drafts. >> >>> >>> " After a device is authenticated using PANA, it MUST be >> authorized >>> for network access. That is, the core requirement of PANA is to >>> verify the authorization of a PaC so that PaCs device may send and >>> receive any IP packets." >>> >>> Using PANA for authorization seems to me to be problematic >> because EAP >>> assumes that access is allowed or denied based on the EAP >> authentication >>> process alone. >> >> Actually all this requirement says is that at the end of a PANA >> authentication, client is either authorized to access the >> network or not. It >> does not really say anythign regarding whether PANA carries >> authorization, >> or EAP carries authentication, etc. >> >> PANA can satisfy the above requirement by simply carrying EAP, and not >> carrying any other result codes. It may also have its own >> result field, but >> we need to deal with this issue separately. At least, this is not a >> requirements issue, I think. >> >>> We've already addressed conflicts between the AAA >>> result (Accept/Reject) and EAP result (Success/Failure) in >> RFC 2869bis, >>> and now in 2284bis we are having to reconcile the EAP >> method result with >>> the EAP result. Given this, adding a PANA authorization >> result as well >>> will just add to the confusion. >> >> I don't think this matter boils down to "PANA must not have >> an authorization >> result field", or the opposite. So, I'm not sure if this is for the >> requirements draft to deal with. >> >> [if the PANA result field proves not useful or problematic, >> we can remove it >> from the design] >> >>> >>> "PANA SHOULD have a >>> mechanism to provide disconnect indication. When such indications >>> are not protected by means of physical or link-layer mechanisms, >>> PANA MUST ensure this protection to prevent attackers from >>> leveraging this extension for DoS attacks." >>> >>> Just as it is important to have a secure mechanism >>> for establishing a security association, it is also >> important to have a >>> secure mechanism for tearing one down. That is what a >> secure disconnect >>> indication is, and this is something that needs to be >> provided within >>> the same protocol as handles security association setup. So >> I'd claim >>> that PANA MUST deal with this regardless of physical or link-layer >>> mechanisms. >> >> OK, I'd rewrite this text as: >> >> PANA SHOULD have a mechanism to provide disconnect >> indication. PANA MUST >> be capable of securing disconnect messages in order to >> prevent malicious >> nodes from leveraging this extension for DoS attacks. >> >> >>> >>> "5. Security Considerations >>> >>> This document identifies requirements for the PANA protocol design. >>> Due to the nature of this protocol most of the requirements are >>> security related. The actual protocol design is not specified in >>> this document." >>> >>> I think there needs to be expanded discussion of issues relating to >>> keying, if in fact this is relevant to PANA. As noted earlier, once >>> EAP is used to generate keys on a physically insecure network, >>> a "third leg" is required, in addition to the EAP and AAA >> legs. After >>> reading this document I'm not clear about the requirements for that >>> leg or how PANA could be considered secure without such a leg. >> >> Updated text for section 4.1.1: >> >> Providing authentication, integrity and replay protection for data >> traffic after a successful PANA exchange is outside the scope of >> this protocol. In networks where physical layer security is not >> present, link-layer or network-layer (e.g., IPsec) ciphering can be >> used to provide such security. These mechanisms require presence of >> cryptographic keying material at PaC and EP. Although PANA >> does not deal >> with key derivation or distribution, it indirectly enables >> this by the >> virtue of carrying EAP. Various EAP methods are capable of >> generating >> basic keying material. >> >> The keying material produced by EAP methods cannot be >> directly used with >> IPsec as it lacks the properties of an IPsec SA (security >> association). >> These basic (initial) keys can be used with an IPsec key management >> protocol like IKE to generate the required security >> associations. A >> separate protocol, called secure association protocol, is >> required to >> generate IPsec SAs based on the basic EAP keys. This >> protocol MUST be >> capable of enabling IPsec-based access control on the EPs. >> IPsec SAs >> MUST enable authentication, integrity and replay protection of >> data packets as they are sent between the EP and PaC. >> >> Also, some updates for section 4.1.2: >> >> Providing access control functionality in the network is >> outside the >> scope of PANA. Client access authentication SHOULD be followed by >> access control to make sure only authenticated and authorized >> clients can send and receive IP packets via access network. Access >> control can involve setting access control lists on the EPs. >> Identification of clients that are authorized to access the network >> is done by the PANA protocol exchange. If IPsec-based >> access control is >> deployed in an access network, PaC and EPs should have the >> required IPsec >> SA in place. Generating the IPsec SAs based on EAP keys is >> outside the >> scope of PANA protocol. This transformation MUST be handled by a >> separate secure association protocol (see section 4.1.1). >> >> >> Alper >> >> > > From pana-request@research.telcordia.com Fri Jun 6 03:54:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13337 for ; Fri, 6 Jun 2003 03:53:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h567o2LO004065; Fri, 6 Jun 2003 03:50:02 -0400 (EDT) Resent-Date: Fri, 6 Jun 2003 03:50:02 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-Id: <200306060746.h567kcof091401@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alper Yegin cc: pana Subject: Re: FW: comments on the requirements I-D In-reply-to: Your message of Wed, 04 Jun 2003 17:40:08 PDT. Date: Fri, 06 Jun 2003 09:46:38 +0200 Sender: Francis.Dupont@enst-bretagne.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com In your previous mail you wrote: I agree with all, except .... please see below.. > - 4.6. Interaction with Other Protocols (wording) > be able to co-exist and not interfere with various mobility > ^ add "badly" here > > => rationale: good interferences should be allowed. I'm not sure what would be an example of good interference. I can say "PANA should not untentionally interfere", rather than getting into good vs.bad interference. => this catches the idea. Fine! Thanks Francis.Dupont@enst-bretagne.fr From pana-request@research.telcordia.com Fri Jun 6 20:07:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19115 for ; Fri, 6 Jun 2003 20:07:48 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h57040DC013251; Fri, 6 Jun 2003 20:04:00 -0400 (EDT) Resent-Date: Fri, 6 Jun 2003 20:04:00 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 06 Jun 2003 17:04:46 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <_fTHQC.A.6OD.wvS4-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Dan Forsberg added the comment: > > New version (c). > Changes: > - Session ID (sec. 9.4.9): Diameter format is MAY not MUST. > - Device ID (sec 9.4.3): Device ID contains type field and > data field in the AVP data part. > - Unknown type for Device-Id and Protection-Capability AVPs > (UNKNOWN 0). Let's start driving these issues to conclusion. Here are my comments on the message formating. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alper>>>: I think we can allocate 32 bits to flags, and another 32 bits to message type. Even this is too many for message types, but I guess that's ok. | Transmitted Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- 9.2 AVP Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Flags | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alper>>>: same here. 32 bits to both. | Vendor-Id (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ 9.3.3 PANA-Start-Request PANA-Start-Request is sent by PAA to PaC. PAA sets the transmission sequence number to an initial random value. The received sequence number is set to zero (0). PANA-Start-Request ::= < PANA-Header: > < Session-ID > < Cookie > * [ AVP ] Alper>>>: I think we can talk about fast re-authentication after movement, and this would impact the way we exchange session IDs. But we should handle this under another issue. This is just a note, no feedback here. 9.3.6 PANA-Auth-Answer PANA-Auth-Answer is sent by PaC to PAA in response to PANA-Auth-Request. PANA-Auth-Answer ::= < PANA-Header: > < Session-ID > < EAP-Payload > * [ AVP ] 0*1 < MAC > Alper>>>: I think ACK bit is missing here. 9.3.7 PANA-Success-Request 9.3.9 PANA-Failure-Request Alper>>>: I think we can combine these messages as "PANA-Result" and differentiate using a flag - Success/Failure. How about that? PANA-Failure-Request is sent by PAA to PaC when PAA receives EAP Failure. Alper>>> Let's just say "A PANA-Result message that has the F-flag set indicates the result of the network access authorization request. If the S-bit is set, it means that the PaC is authorized to access the network. If the S-bit is not set, that means PaC's request is denied." Alper>>> There are currently ongoing discussion on the EAP ML regarding how EAP result and authorization results are tied/related to each other. Let's keep EAP result and PANA result independent of each other for now, until EAP WG mandates otherwise. 9.3.11 PANA-Reauth-Request PANA-Reauth-Request can be send both by PaC and PAA. PANA-Reauth-Request ::= < PANA-Header: > < Session-ID > 0*1 [ Add-Device-ID ] 0*1 [ Remove-Device-ID ] * [ AVP ] 0*1 < MAC > Alper:>>> I don't think we need Add-device-ID and remove-device-ID AVPs in the design. So far we have identified use for add device ID (when a DHCP client gets an IP address and wants/needs to use IPsec for access control), but not for remove-device-id. As for the former necessity, I think we can just include device-id in the above message. Alper:>>> We can assume one device ID is associated with one session at a time. So, when the PaC does PANA with the PAA (before DHCP), the device id can be set to the mac address. After successful PANA, it is only allowed to use DHCP, so it does... Now it has an IP address, it can send a re-auth mesage to change its device-id binding from mac address to its IP address. Does this make sense? 9.3.13 PANA-Termination-Request PANA-Termination-Request is sent by PaC to PAA. Alper:>>> I think both can send this message. 9.4.1 Cookie-AVP The Cookie AVP (Code ) is of type OctetString. Alper:>>> Let's tentatively set the Code's here [so that at least implementors can use them during interop testing...] Alper:>>> should we say the data is opaque and the exact content is outside the scope of this protocol. 9.4.2 MAC AVP The MAC AVP (Code ) is of type OctetString. Alper:>>> We need to specify the content here. 9.4.3 Device-ID AVP The Device-ID AVP (Code ) is of type OctetString. The first octet (8 bits) of the AVP Data contains the device type. Rest of the AVP data payload contains the device data. Possible device types. UNKNOWN 0 IPV6_ADDRESS 1 IPV4_ADDRESS 2 ETHERNET_ADDRESS 3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alper:>>> I had suggested following the lead of NDP protocol for specifying how to represent spefic link-layer addresses. We should capture that in here. 9.4.7 Add-Device-ID 9.4.8 Remove-Device-ID Alper:>>>> I think we don't need these add/remove device-id avps. 9.4.9 Session-ID The Session-ID AVP MAY use the same format as defined in [DIAMETER].PAA chooses the session-id. Alper:>>> "Session-ID AVP has an opaque data field. DIAMETER Session-ID may be used in the data field of this AVP. Session-ID is assigned by the PAA . It must be maintained during the lifetime of a PANA session." Alper From pana-request@research.telcordia.com Mon Jun 9 09:53:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04774 for ; Mon, 9 Jun 2003 09:53:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h59DQxSZ018362; Mon, 9 Jun 2003 09:26:59 -0400 (EDT) Resent-Date: Mon, 9 Jun 2003 09:26:59 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [issue9] Message format Date: Mon, 9 Jun 2003 16:22:58 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcMsiEijDAu7zNiuSCSe1Tew+7/o8AB+Xl6A From: To: , X-OriginalArrivalTime: 09 Jun 2003 13:22:59.0661 (UTC) FILETIME=[3F2A57D0:01C32E8A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04774 Hi, Thank you for your comments. See my comments below. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 07 June, 2003 03:05 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue9] Message format > > > > > Dan Forsberg added the comment: > > > > New version (c). > > Changes: > > - Session ID (sec. 9.4.9): Diameter format is MAY not MUST. > > - Device ID (sec 9.4.3): Device ID contains type field and > > data field in the AVP data part. > > - Unknown type for Device-Id and Protection-Capability AVPs > > (UNKNOWN 0). > > Let's start driving these issues to conclusion. > > Here are my comments on the message formating. > > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Message Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Message Type > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Alper>>>: I think we can allocate 32 bits to flags, and > another 32 bits to > message type. Even this is too many for message types, but I > guess that's > ok. Why do you want to change this? The size of the header is not an issue, but why to make it bigger if there is no reason for that. > > > > | Transmitted Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Received Sequence Number > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > 9.2 AVP Header > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVP Flags | AVP Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Alper>>>: same here. 32 bits to both. You mean 32bits for AVP flags and 32bits for AVP Length? The AVP length can't be bigger than the whole message length! Currently both fields are 16bit. Why do you want to change this? See my comment above. If we can maintain the compatibility with for example Diameter, let's do so. Otherwise we have to specify all AVPs in the PANA doc. Even if we want to specify them all in the PANA doc, I don't get the point. Are you against Diameter compatibility? If so, why? > > > | Vendor-Id (opt) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ > > 9.3.3 PANA-Start-Request > > PANA-Start-Request is sent by PAA to PaC. PAA sets the > transmission sequence number to an initial random value. The > received sequence number is set to zero (0). > > PANA-Start-Request ::= < PANA-Header: > > < Session-ID > > < Cookie > > * [ AVP ] > > Alper>>>: I think we can talk about fast re-authentication > after movement, > and this would impact the way we exchange session IDs. But we > should handle > this under another issue. This is just a note, no feedback here. > > > > 9.3.6 PANA-Auth-Answer > > PANA-Auth-Answer is sent by PaC to PAA in response to > PANA-Auth-Request. > > PANA-Auth-Answer ::= < PANA-Header: > > < Session-ID > > < EAP-Payload > > * [ AVP ] > 0*1 < MAC > > > Alper>>>: I think ACK bit is missing here. The current message formatting section is using R(equest) bit, because it reflects better to the message names and Diameter. > > 9.3.7 PANA-Success-Request > 9.3.9 PANA-Failure-Request > > Alper>>>: I think we can combine these messages as "PANA-Result" and > differentiate using a flag - Success/Failure. How about that? How about using Result-Code AVP? In Failure case, more information could be delivered (see Diameter spec.). > > > PANA-Failure-Request is sent by PAA to PaC when PAA receives EAP > Failure. > > Alper>>> Let's just say "A PANA-Result message that has the F-flag set > indicates the result of the network access authorization > request. If the > S-bit is set, it means that the PaC is authorized to access > the network. If > the S-bit is not set, that means PaC's request is denied." > > Alper>>> There are currently ongoing discussion on the EAP ML > regarding how > EAP result and authorization results are tied/related to each > other. Let's > keep EAP result and PANA result independent of each other for > now, until EAP > WG mandates otherwise. Ok. > > > 9.3.11 PANA-Reauth-Request > > PANA-Reauth-Request can be send both by PaC and PAA. > > PANA-Reauth-Request ::= < PANA-Header: > > < Session-ID > > 0*1 [ Add-Device-ID ] > 0*1 [ Remove-Device-ID ] > * [ AVP ] > 0*1 < MAC > > > Alper:>>> I don't think we need Add-device-ID and > remove-device-ID AVPs in > the design. So far we have identified use for add device ID > (when a DHCP > client gets an IP address and wants/needs to use IPsec for > access control), > but not for remove-device-id. As for the former necessity, I > think we can > just include device-id in the above message. What about multihoming, MIP, and site local addresses in IPv6? Does PaC create another session? > Alper:>>> We can assume one device ID is associated with one > session at a > time. So, when the PaC does PANA with the PAA (before DHCP), > the device id > can be set to the mac address. After successful PANA, it is > only allowed to > use DHCP, so it does... Now it has an IP address, it can send > a re-auth > mesage to change its device-id binding from mac address to > its IP address. > Does this make sense? See my comment above. I see the Session-Id as the static identifier for the PANA session. > > > 9.3.13 PANA-Termination-Request > > PANA-Termination-Request is sent by PaC to PAA. > > Alper:>>> I think both can send this message. ok, that's true. > > > > 9.4.1 Cookie-AVP > > The Cookie AVP (Code ) is of type OctetString. > > Alper:>>> Let's tentatively set the Code's here [so that at least > implementors can use them during interop testing...] What's the scope of the number space? I guess it's not good way to specify something and then later change the numbers.. or does other specs do so? > > Alper:>>> should we say the data is opaque and the exact > content is outside > the scope of this protocol. OctetString is definition of the type not the content. You think we should change the type? > > > 9.4.2 MAC AVP > > The MAC AVP (Code ) is of type OctetString. > > Alper:>>> We need to specify the content here. The content is specified in section 4.1.5 "Message Authentication Code". Do we need something else? "The MAC AVP (Code ) is of type OctetString. The content is specified in section 4.1.5." > > 9.4.3 Device-ID AVP > > The Device-ID AVP (Code ) is of type OctetString. The first > octet (8 bits) of the AVP Data contains the device type. Rest > of the AVP data payload contains the device data. Possible device > types. > > UNKNOWN 0 > IPV6_ADDRESS 1 > IPV4_ADDRESS 2 > ETHERNET_ADDRESS 3 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Data... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Alper:>>> I had suggested following the lead of NDP protocol > for specifying > how to represent spefic link-layer addresses. We should > capture that in > here. Can you give me a reference to NDP protocol? I don't remember your comment about it. > > > 9.4.7 Add-Device-ID > 9.4.8 Remove-Device-ID > > Alper:>>>> I think we don't need these add/remove device-id avps. > > > 9.4.9 Session-ID > > The Session-ID AVP MAY use the same format as defined in > [DIAMETER].PAA chooses the session-id. > > > Alper:>>> "Session-ID AVP has an opaque data field. DIAMETER > Session-ID may > be used in the data field of this AVP. Session-ID is assigned > by the PAA . > It must be maintained during the lifetime of a PANA session." How about this: "Session-Id AVP has an opaque data field, which is assigned by the PAA. The Session-ID AVP MAY use Diameter [DIAMETER] message formatting and it MUST be maintained during the lifetime of a PANA session." - Dan > > > Alper > > From pana-request@research.telcordia.com Mon Jun 9 21:25:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27630 for ; Mon, 9 Jun 2003 21:25:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5A1LjcA011170; Mon, 9 Jun 2003 21:21:45 -0400 (EDT) Resent-Date: Mon, 9 Jun 2003 21:21:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 09 Jun 2003 18:22:38 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, >> Alper>>>: I think we can allocate 32 bits to flags, and >> another 32 bits to >> message type. Even this is too many for message types, but I >> guess that's >> ok. > > Why do you want to change this? The size of the header is not an issue, but > why to make it bigger if there is no reason for that. I meant to say 16 bits each, not 32. Sorry. Currently flags have only 8 bits (too few) and message type has 24 bits (too many, we ar not going to define 2^24 AVPs).I can see us quickly running out of flags if we keep it 8 bits only. >> 9.2 AVP Header >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AVP Code >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AVP Flags | AVP Length >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Alper>>>: same here. 32 bits to both. Same here, I meant to say 16bits each. Same reasons. > > You mean 32bits for AVP flags and 32bits for AVP Length? The AVP length can't > be bigger than the whole message length! Currently both fields are 16bit. > > Why do you want to change this? See my comment above. > > If we can maintain the compatibility with for example Diameter, let's do so. > Otherwise we have to specify all AVPs in the PANA doc. Even if we want to > specify them all in the PANA doc, I don't get the point. > > Are you against Diameter compatibility? If so, why? > >> >> 9.3.6 PANA-Auth-Answer >> >> PANA-Auth-Answer is sent by PaC to PAA in response to >> PANA-Auth-Request. >> >> PANA-Auth-Answer ::= < PANA-Header: > >> < Session-ID > >> < EAP-Payload > >> * [ AVP ] >> 0*1 < MAC > >> >> Alper>>>: I think ACK bit is missing here. > > The current message formatting section is using R(equest) bit, because it > reflects better to the message names and Diameter. OK, then the ACK bits in other messages should be removed too. PANA_failure_answer, PANA-reauth_answer, etc. have ACK bits. > >> >> 9.3.7 PANA-Success-Request >> 9.3.9 PANA-Failure-Request >> >> Alper>>>: I think we can combine these messages as "PANA-Result" and >> differentiate using a flag - Success/Failure. How about that? > > How about using Result-Code AVP? In Failure case, more information could be > delivered (see Diameter spec.). OK, that makes sense to me. PANA-result message can carry Result-code AVP. >> 9.3.11 PANA-Reauth-Request >> >> PANA-Reauth-Request can be send both by PaC and PAA. >> >> PANA-Reauth-Request ::= < PANA-Header: > >> < Session-ID > >> 0*1 [ Add-Device-ID ] >> 0*1 [ Remove-Device-ID ] >> * [ AVP ] >> 0*1 < MAC > >> >> Alper:>>> I don't think we need Add-device-ID and >> remove-device-ID AVPs in >> the design. So far we have identified use for add device ID >> (when a DHCP >> client gets an IP address and wants/needs to use IPsec for >> access control), >> but not for remove-device-id. As for the former necessity, I >> think we can >> just include device-id in the above message. > > What about multihoming, MIP, and site local addresses in IPv6? Does PaC create > another session? What are the issues that we need to handle there? Can we not handle them with the mechanism I outlined? > >> Alper:>>> We can assume one device ID is associated with one >> session at a >> time. So, when the PaC does PANA with the PAA (before DHCP), >> the device id >> can be set to the mac address. After successful PANA, it is >> only allowed to >> use DHCP, so it does... Now it has an IP address, it can send >> a re-auth >> mesage to change its device-id binding from mac address to >> its IP address. >> Does this make sense? > > See my comment above. I see the Session-Id as the static identifier for the > PANA session. OK, I don't think I'm saying anything to conflict with that. >> 9.4.1 Cookie-AVP >> >> The Cookie AVP (Code ) is of type OctetString. >> >> Alper:>>> Let's tentatively set the Code's here [so that at least >> implementors can use them during interop testing...] > > What's the scope of the number space? I guess it's not good way to specify > something and then later change the numbers.. or does other specs do so? The numbers are tentative until they are officially assigned by the IANA. If you look at other I-Ds, you'll see these type of numbers are set in the document even before they are officially assigned by IANA. > >> >> Alper:>>> should we say the data is opaque and the exact >> content is outside >> the scope of this protocol. > > OctetString is definition of the type not the content. You think we should > change the type? No, I'm not suggesting any change. This is just additional text that does not conflict with yours. > >> >> >> 9.4.2 MAC AVP >> >> The MAC AVP (Code ) is of type OctetString. >> >> Alper:>>> We need to specify the content here. > > The content is specified in section 4.1.5 "Message Authentication Code". Do we > need something else? > > "The MAC AVP (Code ) is of type OctetString. The content > is specified in section 4.1.5." That still does not provide the (much needed) message format (order and size of fields). > >> >> 9.4.3 Device-ID AVP >> >> The Device-ID AVP (Code ) is of type OctetString. The first >> octet (8 bits) of the AVP Data contains the device type. Rest >> of the AVP data payload contains the device data. Possible device >> types. >> >> UNKNOWN 0 >> IPV6_ADDRESS 1 >> IPV4_ADDRESS 2 >> ETHERNET_ADDRESS 3 >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Data... >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Alper:>>> I had suggested following the lead of NDP protocol >> for specifying >> how to represent spefic link-layer addresses. We should >> capture that in >> here. > > Can you give me a reference to NDP protocol? I don't remember your comment > about it. This is in reference to IPv6 Neighbor Discovery Protocol, RFC 2461. For example: 4.6.1. Source/Target Link-layer Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. >> 9.4.9 Session-ID >> >> The Session-ID AVP MAY use the same format as defined in >> [DIAMETER].PAA chooses the session-id. >> >> >> Alper:>>> "Session-ID AVP has an opaque data field. DIAMETER >> Session-ID may >> be used in the data field of this AVP. Session-ID is assigned >> by the PAA . >> It must be maintained during the lifetime of a PANA session." > > How about this: > > "Session-Id AVP has an opaque data field, which is assigned by the > PAA. The Session-ID AVP MAY use Diameter [DIAMETER] message > formatting and it MUST be maintained during the lifetime of a PANA > session." Looks good to me. Thanks. Alper > > - Dan > >> >> >> Alper >> >> > > > From pana-request@research.telcordia.com Tue Jun 10 09:52:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00071 for ; Tue, 10 Jun 2003 09:52:05 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5ADnKpf009694; Tue, 10 Jun 2003 09:49:20 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 09:49:20 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Session-Id in the first PANA-Auth-Request Date: Tue, 10 Jun 2003 16:45:29 +0300 Message-ID: Thread-Topic: Session-Id in the first PANA-Auth-Request Thread-Index: AcMvVo4K8RbjKslbSNCJ2//Iuqh5Qw== From: To: X-OriginalArrivalTime: 10 Jun 2003 13:45:29.0994 (UTC) FILETIME=[8E708EA0:01C32F56] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00071 Hi, These questions are relevant to the state initialization in PAA. When should PAA send the Session-Id? In the first PANA-Auth-Request after PaC has answered with PANA-Start-Answer? - Dan From pana-request@research.telcordia.com Tue Jun 10 09:53:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00143 for ; Tue, 10 Jun 2003 09:53:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5ADf5oK009030; Tue, 10 Jun 2003 09:41:05 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 09:41:05 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: FW: AAAWG: Diameter vulnerability to connection depletion DoS attacks Date: Tue, 10 Jun 2003 16:41:00 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Thread-Index: AcMqidCTBRHDFdtCQgKhl0roVEm5twEy/iFA From: To: X-OriginalArrivalTime: 10 Jun 2003 13:41:01.0208 (UTC) FILETIME=[EE3B1180:01C32F55] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00143 Hi, FYI: Here is a comment from AAA WG mailing list about client puzzles. - Dan -----Original Message----- From: ext Floroiu John [mailto:jfl@mobile-ip.de] Sent: 04 June, 2003 13:57 To: Avi Lior Cc: 'David Mitton'; 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Thanks everybody for your answers, I will merge my comments into this reply. > The second issue is about how much information is kept in the server during > each transaction. You can certainly design a protocol that minimize or even > elliminates the need to keep any information in memory. However, that comes > at a price. You either have to give up functionality, or have message > bloat. I perfectly agree with that. Myself, however I regarded Diameter primarly as an authentication protocol and there are examples of protocols that require participants neither to perform expensive computations nor to create state unless the peer is known to be legitimate. > For example, in AAA we belive that an intermediary AAA server should be able > to detect a timeout and act on that timeout for each transaction. Therefore > it must as a minimum store each message, as well as an associated timer, and > where it sent that message. You can do away with this memory burden but > then how would you meet this requirement? You certainly can't store > information in the message to solve this problem. I agree with that, too: one cannot perform retransimissions based on the information contained in a lost packet (and if the packet is not lost then one doesn't need that information anyway). But on the other hand if an AAA server retransimits forged requests, then this aggravates the impact of any potential DoS attack. As another message in this thread has suggested, the matter could be delegated to the AAA front-end protocols (such as PANA). However, in the case of inter-domain roaming scenarios, for instance, when the mobile users and the NASs do not share any pre-existent trust relationship, such protocols cannot prevent forged authentication requests from entering the AAA infrastructure. Cookies can only protect against blind attacks. Relevant to http://danforsberg.info:8080/pana-issues/issue15, client puzzles are also ineffective because malicious nodes may pose as NASs and perform computational DoS against legitimate nodes by proposing "difficult" puzzles. Since there is no pre-existent trust relationship between "pac" and "paa" puzzle proposals may only be authenticated using asymmetric cryptography ([1]), which is however also a source of computational DoS attacks. Maybe the safest approach would be to provide a real stateless AAA client operation and support more features (retransimissions, security contexts, just to refer to those already mentioned in this context) after the client has been successfully authenticated. Just an opinion... John. [1] T. Aura, P. Nikander, J. Leiwo - DoS-resistant Authentication with Client Puzzles From pana-request@research.telcordia.com Tue Jun 10 09:59:47 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00405 for ; Tue, 10 Jun 2003 09:59:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5ADvI9v010426; Tue, 10 Jun 2003 09:57:18 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 09:57:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [issue9] Message format Date: Tue, 10 Jun 2003 16:57:13 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcMu7p+7rBr21zV3TVueu7ssVBPKnAAVu4IQ From: To: , X-OriginalArrivalTime: 10 Jun 2003 13:57:14.0385 (UTC) FILETIME=[324A1810:01C32F58] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00405 Alper, Here are my comments. A new version of message format is available from the issue tracker. I'll forward the notification to this list. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 10 June, 2003 04:23 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue9] Message format > > > Hi Dan, > > >> Alper>>>: I think we can allocate 32 bits to flags, and > >> another 32 bits to > >> message type. Even this is too many for message types, but I > >> guess that's > >> ok. > > > > Why do you want to change this? The size of the header is > not an issue, but > > why to make it bigger if there is no reason for that. > > > I meant to say 16 bits each, not 32. Sorry. > > Currently flags have only 8 bits (too few) and message type > has 24 bits (too > many, we ar not going to define 2^24 AVPs).I can see us > quickly running out > of flags if we keep it 8 bits only. So far we have used only two flags (FIN & REQ), six left. I don't see this as a good enaough reason. I think the protocol is way too complicated if we need all the 8 different flags, worse if more than that (16). Btw, AVPs can be used for that purpose too (null data part). Anyway, if we change this for the AVP header we can't use existing AVPs (Result-Code, Session-Id, Termination-Cause, EAP, etc.). > > >> 9.3.6 PANA-Auth-Answer > >> > >> PANA-Auth-Answer is sent by PaC to PAA in response to > >> PANA-Auth-Request. > >> > >> PANA-Auth-Answer ::= < PANA-Header: > > >> < Session-ID > > >> < EAP-Payload > > >> * [ AVP ] > >> 0*1 < MAC > > >> > >> Alper>>>: I think ACK bit is missing here. > > > > The current message formatting section is using R(equest) > bit, because it > > reflects better to the message names and Diameter. > > OK, then the ACK bits in other messages should be removed too. > PANA_failure_answer, PANA-reauth_answer, etc. have ACK bits. Ok, fixed. > >> 9.3.11 PANA-Reauth-Request > >> > >> PANA-Reauth-Request can be send both by PaC and PAA. > >> > >> PANA-Reauth-Request ::= < PANA-Header: > > >> < Session-ID > > >> 0*1 [ Add-Device-ID ] > >> 0*1 [ Remove-Device-ID ] > >> * [ AVP ] > >> 0*1 < MAC > > >> > >> Alper:>>> I don't think we need Add-device-ID and > >> remove-device-ID AVPs in > >> the design. So far we have identified use for add device ID > >> (when a DHCP > >> client gets an IP address and wants/needs to use IPsec for > >> access control), > >> but not for remove-device-id. As for the former necessity, I > >> think we can > >> just include device-id in the above message. > > > > What about multihoming, MIP, and site local addresses in > IPv6? Does PaC create > > another session? > > What are the issues that we need to handle there? Can we not > handle them > with the mechanism I outlined? What if the MN wants to access the local network with link local or site local addresses at the same time with a global CoA address? What if the MN has multiple interfaces (WLAN, Bluetooth, Ethernet, 3G, etc.) that all get a separate IP address from the same NAP through the same PAA? It's better to have one PANA session but add/delete addresses/interfaces. Another possibility is to use only Device-Id AVP, but to send multiple AVPs (list of currently used Device Ids). > >> 9.4.1 Cookie-AVP > >> > >> The Cookie AVP (Code ) is of type OctetString. > >> > >> Alper:>>> Let's tentatively set the Code's here [so that at least > >> implementors can use them during interop testing...] > > > > What's the scope of the number space? I guess it's not good > way to specify > > something and then later change the numbers.. or does other > specs do so? > > The numbers are tentative until they are officially assigned > by the IANA. > If you look at other I-Ds, you'll see these type of numbers > are set in the > document even before they are officially assigned by IANA. Ok. We could propose to use space from 1024 onwards for PANA AVPs and from 1 onwards for message types. > > > >> > >> Alper:>>> should we say the data is opaque and the exact > >> content is outside > >> the scope of this protocol. > > > > OctetString is definition of the type not the content. You > think we should > > change the type? > > No, I'm not suggesting any change. This is just additional > text that does > not conflict with yours. Ah, ok. Should we make the Cookie AVP optional then? (i.e. no mandatoryy flag in the AVP header). > > > >> > >> > >> 9.4.2 MAC AVP > >> > >> The MAC AVP (Code ) is of type OctetString. > >> > >> Alper:>>> We need to specify the content here. > > > > The content is specified in section 4.1.5 "Message > Authentication Code". Do we > > need something else? > > > > "The MAC AVP (Code ) is of type OctetString. The content > > is specified in section 4.1.5." > > That still does not provide the (much needed) message format > (order and size > of fields). Ok. I've tried to catch this now. > > > > >> > >> 9.4.3 Device-ID AVP > >> > >> The Device-ID AVP (Code ) is of type OctetString. > The first > >> octet (8 bits) of the AVP Data contains the device type. Rest > >> of the AVP data payload contains the device data. > Possible device > >> types. > >> > >> UNKNOWN 0 > >> IPV6_ADDRESS 1 > >> IPV4_ADDRESS 2 > >> ETHERNET_ADDRESS 3 > >> > >> 0 1 2 > 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type | Data... > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> Alper:>>> I had suggested following the lead of NDP protocol > >> for specifying > >> how to represent spefic link-layer addresses. We should > >> capture that in > >> here. > > > > Can you give me a reference to NDP protocol? I don't > remember your comment > > about it. > > This is in reference to IPv6 Neighbor Discovery Protocol, RFC 2461. > > For example: > > > > 4.6.1. Source/Target Link-layer Address > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Link-Layer Address ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Link-Layer Address > The variable length link-layer address. > > The content and format of this field (including > byte and bit ordering) is expected to be > specified > in specific documents that describe how IPv6 > operates over different link layers. > For instance, > [IPv6-ETHER]. Sounds good. Fixed this. > > >> 9.4.9 Session-ID > >> > >> The Session-ID AVP MAY use the same format as defined in > >> [DIAMETER].PAA chooses the session-id. > >> > >> > >> Alper:>>> "Session-ID AVP has an opaque data field. DIAMETER > >> Session-ID may > >> be used in the data field of this AVP. Session-ID is assigned > >> by the PAA . > >> It must be maintained during the lifetime of a PANA session." > > > > How about this: > > > > "Session-Id AVP has an opaque data field, which is assigned by the > > PAA. The Session-ID AVP MAY use Diameter [DIAMETER] message > > formatting and it MUST be maintained during the lifetime of a PANA > > session." > > > Looks good to me. I changed this a bit after the AVP type code allocation proposal. - Dan > > Thanks. > > Alper > > > > > > > - Dan > > > >> > >> > >> Alper > >> > >> > > > > > > > > From pana-request@research.telcordia.com Tue Jun 10 10:12:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01719 for ; Tue, 10 Jun 2003 10:11:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5AE9Q6H011753; Tue, 10 Jun 2003 10:09:26 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 10:09:26 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [issue9] Message format Date: Tue, 10 Jun 2003 17:09:22 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcMvWawqVUuUT1AKTgCeRVvE9hs7fwAABy9Q From: To: X-OriginalArrivalTime: 10 Jun 2003 14:09:23.0408 (UTC) FILETIME=[E4D22D00:01C32F59] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01719 Dan Forsberg added the comment: New version (d). Changes: - Changed ACK bits to FIN bits. - Added AVP tables. - Using 1024-> values for AVP types for now. - Using 1-> values for Message types for now. - Cookie is not mandatory. - Defined MAC AVP with two possible algorithms (HMAC-MD5 & HMAC-SHA1). - Using external documents to specify l2 addresses. - For now removed Session-Id from PANA-Start-Request and PANA-Start-Answer to keep PAA stateless before first answer from PaC. - Misc editorial fixes. ---------- assignedto: -> dforsber _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue9 _______________________________________________ From pana-request@research.telcordia.com Tue Jun 10 14:04:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11066 for ; Tue, 10 Jun 2003 14:04:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5AI1BkN028999; Tue, 10 Jun 2003 14:01:11 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 14:01:11 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 10:57:46 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, >> I meant to say 16 bits each, not 32. Sorry. >> >> Currently flags have only 8 bits (too few) and message type >> has 24 bits (too >> many, we ar not going to define 2^24 AVPs).I can see us >> quickly running out >> of flags if we keep it 8 bits only. > > So far we have used only two flags (FIN & REQ), six left. I don't see this as > a good enaough reason. It's safer to allocate the bits while we have spare ones. Maybe we won't need them, but if we do, we'll have the space. Clearly 24bits for AVP space won't be utilized. The chances of requiring more than 8 flags is much more than having nearly 2^24 AVPs. > I think the protocol is way too complicated if we need > all the 8 different flags, worse if more than that (16). Btw, AVPs can be used > for that purpose too (null data part). This would not be a clean solution, right? > > Anyway, if we change this for the AVP header we can't use existing AVPs > (Result-Code, Session-Id, Termination-Cause, EAP, etc.). I see. I understand the desire (not a requirement) to re-use pre-defined data types, but we need to evaluate pros and cons. >>>> Alper:>>> I don't think we need Add-device-ID and >>>> remove-device-ID AVPs in >>>> the design. So far we have identified use for add device ID >>>> (when a DHCP >>>> client gets an IP address and wants/needs to use IPsec for >>>> access control), >>>> but not for remove-device-id. As for the former necessity, I >>>> think we can >>>> just include device-id in the above message. >>> >>> What about multihoming, MIP, and site local addresses in >> IPv6? Does PaC create >>> another session? >> >> What are the issues that we need to handle there? Can we not >> handle them >> with the mechanism I outlined? > > What if the MN wants to access the local network with link local or site local > addresses at the same time with a global CoA address? We have discussed this. Depending on the DI: - if MAC address: then there is no issue. PaC can configure any IP address on the specified MAC address. Access control is based on the MAC address. - if IP address: This is the case where IPsec is used. For this, PaC determines one of the IP addresses as DI, most probably a link-local address. The traffic is tunneled using this DI as the local end point. See PANA-Ipsec draft. Now, if the PaC wants to use other IP addresses, they will be used only within the tunnel, hence the access control does not care about them. > > What if the MN has multiple interfaces (WLAN, Bluetooth, Ethernet, 3G, etc.) > that all get a separate IP address from the same NAP through the same PAA? > It's better to have one PANA session but add/delete addresses/interfaces. The simple answer is: all physical interfaces should do PANA independently. Is there a problem with that? > > Another possibility is to use only Device-Id AVP, but to send multiple AVPs > (list of currently used Device Ids). > >>>> Alper:>>> should we say the data is opaque and the exact >>>> content is outside >>>> the scope of this protocol. >>> >>> OctetString is definition of the type not the content. You >> think we should >>> change the type? >> >> No, I'm not suggesting any change. This is just additional >> text that does >> not conflict with yours. > > Ah, ok. Should we make the Cookie AVP optional then? (i.e. no mandatoryy flag > in the AVP header). If PAA includes the cookie in the message, PaC MUST copy it back. But yes, we can say inclusion of cookie by PAA is optional. In some environments, cookie might not be needed (e.g., over physical links). Alper From pana-request@research.telcordia.com Tue Jun 10 16:58:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17706 for ; Tue, 10 Jun 2003 16:58:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5AKsE4P011472; Tue, 10 Jun 2003 16:54:14 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 16:54:14 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 13:55:18 -0700 Subject: Re: Session-Id in the first PANA-Auth-Request and Issue 7 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, I think PANA issue #7 is related, therefore I'm including both discussions here. > Hi, > > These questions are relevant to the state initialization in PAA. > > When should PAA send the Session-Id? > > In the first PANA-Auth-Request after PaC has answered with PANA-Start-Answer? I think this makes sense. As for Issue #7: If PaC wants to resume an ongoing PANA session at another access link, it can send the unexpired PANA session id in its PANA_start message. In the absence of session id AVP in this message, PAA can assume this is a fresh session and assign a new session ID in the first PANA-auth-req message. If PAA receives a session id in the PANA-start message, and it is configured to enable "fast re-auth", it should retrieve the PANA SA from the old PAA. The mechanism required to retrieve the PANA SA is outside the scope of PANA protocol. [Seamoby context transfer protocol should help]. If the PAA is not configured to enable fast re-auth, or cannot retrieve the PANA SA, or the PANA SA has expired, PAA can send the PANA-start message with a new session ID and let the PANA exchange take its usual course. Otherwise, continue the PANA session with PANA-reauth exchange (rather than PANA-auth which, in most of the time, means full authentication). Device ID AVPs must be included to bind the new DIs to the PANA SA. Comments? Alper From pana-request@research.telcordia.com Tue Jun 10 17:11:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18164 for ; Tue, 10 Jun 2003 17:11:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5AL9SGR012655; Tue, 10 Jun 2003 17:09:28 -0400 (EDT) Resent-Date: Tue, 10 Jun 2003 17:09:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 14:10:26 -0700 Subject: Issue 8 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit http://danforsberg.info:8080/pana-issues/issue8 How about if we: - define a refresh (re-auth) lifetime AVP. - PAA MUST include this AVP in the PANA_success to provide the maximum allowed refresh lifetime for the PANA session. - PAA MAY include this AVP in the PANA_success_ack to lower the required PANA refresh lifetime. At the end of PANA_success round, both PAA and PaC knows the refresh frequency. PaC MAY send PANA_reauth before this period expires. PAA MUST send PANA-reauth if there was no PANA-reauth exchange for one full period. Comments? Alper From pana-request@research.telcordia.com Wed Jun 11 06:04:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01191 for ; Wed, 11 Jun 2003 06:04:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BA0cEU000354; Wed, 11 Jun 2003 06:00:38 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 06:00:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Issue 8 Date: Wed, 11 Jun 2003 12:56:33 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcMvlKryajpKTRR9RciMaLT21/G+bQAZwEqw From: To: , X-OriginalArrivalTime: 11 Jun 2003 09:56:34.0383 (UTC) FILETIME=[BDCA65F0:01C32FFF] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <8h5VP.A.ZF.G3v5-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA01191 Alper, Here are some comments. - We need a grace period too: Authorization-Lifetime + Auth-Grace-Period <= Session-Timeout Here Auth-Grace-Period < Authorization-Lifetime Unit is seconds. Auth-Grace-Period is a configurable parameter and delivered from PAA to PaC. - PaC should propose something and PAA then decides the actual refresh period and session lifetime (the network knows better the upper and lower limits for re-auth etc.). PaC can optionally propose a Authorization-Lifetime to PAA within a PANA-Auth-Request message. PAA sends Authorization-Lifetime and Auth-Grace-Period AVPs to PaC in PANA-Result-Request message. PAA can also send Session-Timeout AVP to denote the total lifetime of the session. - PANA-Reauth-Request from PAA can optionally contain Authorization-Lifetime AVP to denote the re-auth interval (if network wants to change it)? Br, - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 11 June, 2003 00:10 > To: pana@research.telcordia.com > Subject: Issue 8 > > > > http://danforsberg.info:8080/pana-issues/issue8 > > > How about if we: > > - define a refresh (re-auth) lifetime AVP. > - PAA MUST include this AVP in the PANA_success to provide the maximum > allowed refresh lifetime for the PANA session. > - PAA MAY include this AVP in the PANA_success_ack to lower > the required > PANA refresh lifetime. > > At the end of PANA_success round, both PAA and PaC knows the refresh > frequency. > > PaC MAY send PANA_reauth before this period expires. PAA MUST send > PANA-reauth if there was no PANA-reauth exchange for one full period. > > Comments? > > Alper > > From pana-request@research.telcordia.com Wed Jun 11 06:39:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01878 for ; Wed, 11 Jun 2003 06:39:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BAb8FO005919; Wed, 11 Jun 2003 06:37:08 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 06:37:08 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [issue9] Message format Date: Wed, 11 Jun 2003 13:37:04 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcMveabC8GedqbNRQ96NVrSj/Tf18AAhiDdw From: To: , X-OriginalArrivalTime: 11 Jun 2003 10:37:05.0301 (UTC) FILETIME=[66BB0C50:01C33005] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA01878 Hi Alper, Some comments below. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 10 June, 2003 20:58 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue9] Message format > > > Hi Dan, > > >> I meant to say 16 bits each, not 32. Sorry. > >> > >> Currently flags have only 8 bits (too few) and message type > >> has 24 bits (too > >> many, we ar not going to define 2^24 AVPs).I can see us > >> quickly running out > >> of flags if we keep it 8 bits only. > > > > So far we have used only two flags (FIN & REQ), six left. I > don't see this as > > a good enaough reason. > > It's safer to allocate the bits while we have spare ones. > Maybe we won't > need them, but if we do, we'll have the space. Clearly 24bits > for AVP space > won't be utilized. The chances of requiring more than 8 flags > is much more > than having nearly 2^24 AVPs. I don't see this a valid argument against Diameter AVP compatibility. Anyway, 16 bits for flags is not a requirement and I have expressed my opinion about it's suitability for (PANA) protocol already. It's much easier for vendors to specify one AVP that can be used with PANA and with Diameter, when there is no difference with the AVP format. Or let's say to use already specified AVPs with PANA. I see that this kind of approach favors PANA. > > I think the protocol is way too complicated if we need > > all the 8 different flags, worse if more than that (16). > Btw, AVPs can be used > > for that purpose too (null data part). > > This would not be a clean solution, right? It's used already in other protocols in application level (i.e. kind of optional binary AVPs). > > > > > Anyway, if we change this for the AVP header we can't use > existing AVPs > > (Result-Code, Session-Id, Termination-Cause, EAP, etc.). > > I see. I understand the desire (not a requirement) to re-use > pre-defined > data types, but we need to evaluate pros and cons. I guess we have been doing this.. > > > > >>>> Alper:>>> I don't think we need Add-device-ID and > >>>> remove-device-ID AVPs in > >>>> the design. So far we have identified use for add device ID > >>>> (when a DHCP > >>>> client gets an IP address and wants/needs to use IPsec for > >>>> access control), > >>>> but not for remove-device-id. As for the former necessity, I > >>>> think we can > >>>> just include device-id in the above message. > >>> > >>> What about multihoming, MIP, and site local addresses in > >> IPv6? Does PaC create > >>> another session? > >> > >> What are the issues that we need to handle there? Can we not > >> handle them > >> with the mechanism I outlined? > > > > What if the MN wants to access the local network with link > local or site local > > addresses at the same time with a global CoA address? > > We have discussed this. Depending on the DI: > > - if MAC address: then there is no issue. PaC can configure any > IP address on the specified MAC address. Access control is based on > the MAC address. Where is this kind of scenario feasible? That would mean that PaC can freely spoof IP addresses. I don't think it's a good idea. Filtering should be based on IP addresses as well. PANA is IP level protocol.. > - if IP address: This is the case where IPsec is used. For this, PaC > determines one of the IP addresses as DI, most probably a link-local > address. The traffic is tunneled using this DI as the local > end point. See > PANA-Ipsec draft. Now, if the PaC wants to use other IP > addresses, they > will be used only within the tunnel, hence the access control does not > care about them. If DI is IP address, IPSec is not always used (physically secure links for example or links that provide L2 protection). Right? > > > > > What if the MN has multiple interfaces (WLAN, Bluetooth, > Ethernet, 3G, etc.) > > that all get a separate IP address from the same NAP > through the same PAA? > > It's better to have one PANA session but add/delete > addresses/interfaces. > > The simple answer is: all physical interfaces should do PANA > independently. > Is there a problem with that? This is not a good approach. Just think about the re-auth message flood, multiple session state information and even possibly multiple AAA backend sessions on the core network. Not scalable. Consumes resources on the client and on the network unnecessarily. Another point is that adding new interface to the existing session is faster than doing the whole AA process from scratch. > > > > Another possibility is to use only Device-Id AVP, but to > send multiple AVPs > > (list of currently used Device Ids). > > > >>>> Alper:>>> should we say the data is opaque and the exact > >>>> content is outside > >>>> the scope of this protocol. > >>> > >>> OctetString is definition of the type not the content. You > >> think we should > >>> change the type? > >> > >> No, I'm not suggesting any change. This is just additional > >> text that does > >> not conflict with yours. > > > > Ah, ok. Should we make the Cookie AVP optional then? (i.e. > no mandatoryy flag > > in the AVP header). > > If PAA includes the cookie in the message, PaC MUST copy it back. > But yes, we can say inclusion of cookie by PAA is optional. In some > environments, cookie might not be needed (e.g., over physical links). Ok. > > Alper > > From pana-request@research.telcordia.com Wed Jun 11 10:19:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10757 for ; Wed, 11 Jun 2003 10:19:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BEFx3Z019007; Wed, 11 Jun 2003 10:15:59 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 10:15:59 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 05:17:11 -0700 To: pana@research.telcordia.com Subject: test Message-ID: <20030610121711.GE5024@steelhead> Mail-Followup-To: pana@research.telcordia.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 1 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is test. Please ignore. From pana-request@research.telcordia.com Wed Jun 11 14:51:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21309 for ; Wed, 11 Jun 2003 14:51:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BIlSCr009027; Wed, 11 Jun 2003 14:47:28 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 14:47:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 11:48:28 -0700 Subject: Re: Issue 8 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, > - We need a grace period too: > Authorization-Lifetime + Auth-Grace-Period <= Session-Timeout > Here > Auth-Grace-Period < Authorization-Lifetime > Unit is seconds. Auth-Grace-Period is a configurable parameter > and delivered from PAA to PaC. I agree there might be a grace period, but I think this can be a local decision (via implementation, configuration). Does the protocol have to carry this information to the other end (PaC)? > - PaC should propose something and PAA then decides the actual > refresh period and session lifetime (the network knows better > the upper and lower limits for re-auth etc.). Now that I'm thinking, maybe we should only pass the Session-lifetime between PAA and PaC, and not worry about Reauth-lifetime. PaC and PAA don't need to share the Reauth-lifetime, each can trigger reauth as often as they like/need. But for Session-lifetime, PaC should know it so that it can perform PANA authentication again before its session expires and PAA disables network access. > PaC can optionally > propose a Authorization-Lifetime to PAA within a PANA-Auth-Request > message. I also thought about first PaC requesting a value and PAA granting one. But then looking at the message flows, the other direction seems to better fit the current design. Instead of one of the PANA-auth messages carrying this info from PaC to PAA, and the response coming back in PANA-success, I think doing it symmetrically in PANA-success/ack is better. PANA module on the PaC won't really know in which PANA-auth message this AVP should be included. > PAA sends Authorization-Lifetime and Auth-Grace-Period > AVPs to PaC in PANA-Result-Request message. PAA can also send > Session-Timeout AVP to denote the total lifetime of the session. I don't think we need to pass the grace-period to the PaC. (well, if we do, it is no longer seen as grace period, but as part of granted period :) How about this: - PAA sends (offered) session-lifetime in PANA-success message to the PaC. If PaC wants to lower the session-lifetime, it MAY include a lower session-lifetime in PANA-success-ack. - It's the responsibility of PaC to perform PANA before its current session expires. [note: here we are talking about full authentication where an EAP method is executed, not re-auth] - Both PaC and PAA can initiate re-auth whenever they need to. Does this make sense? > > - PANA-Reauth-Request from PAA can optionally contain > Authorization-Lifetime AVP to denote the re-auth interval > (if network wants to change it)? > > Alper > Br, > - Dan > > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 11 June, 2003 00:10 >> To: pana@research.telcordia.com >> Subject: Issue 8 >> >> >> >> http://danforsberg.info:8080/pana-issues/issue8 >> >> >> How about if we: >> >> - define a refresh (re-auth) lifetime AVP. >> - PAA MUST include this AVP in the PANA_success to provide the maximum >> allowed refresh lifetime for the PANA session. >> - PAA MAY include this AVP in the PANA_success_ack to lower >> the required >> PANA refresh lifetime. >> >> At the end of PANA_success round, both PAA and PaC knows the refresh >> frequency. >> >> PaC MAY send PANA_reauth before this period expires. PAA MUST send >> PANA-reauth if there was no PANA-reauth exchange for one full period. >> >> Comments? >> >> Alper >> >> > > > From pana-request@research.telcordia.com Wed Jun 11 15:05:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21974 for ; Wed, 11 Jun 2003 15:05:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BJ2oNW010212; Wed, 11 Jun 2003 15:02:50 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 15:02:50 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 12:03:43 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> What if the MN wants to access the local network with link >> local or site local >>> addresses at the same time with a global CoA address? >> >> We have discussed this. Depending on the DI: >> >> - if MAC address: then there is no issue. PaC can configure any >> IP address on the specified MAC address. Access control is based on >> the MAC address. > > Where is this kind of scenario feasible? In scenarios described in sections 4.1 and 4.2 of the usage scenarios draft, plus 4.3 where link-layer ciphers are enabled at the end of PANA. Effectively, almost anywhere IPsec is not used for access control. > > That would mean that PaC can freely spoof IP addresses. Exactly. But, this is a SEND problem, not PANA problem. > I don't think it's a > good idea. Filtering should be based on IP addresses as well. PANA is IP level > protocol.. > >> - if IP address: This is the case where IPsec is used. For this, PaC >> determines one of the IP addresses as DI, most probably a link-local >> address. The traffic is tunneled using this DI as the local >> end point. See >> PANA-Ipsec draft. Now, if the PaC wants to use other IP >> addresses, they >> will be used only within the tunnel, hence the access control does not >> care about them. > > If DI is IP address, IPSec is not always used (physically secure links for > example or links that provide L2 protection). Right? If we are not using IPsec,it does not make sense to use IP address as the DI, unless we are trying to solve SEND problems here. We should use lower-layer identifiers. > >> >>> >>> What if the MN has multiple interfaces (WLAN, Bluetooth, >> Ethernet, 3G, etc.) >>> that all get a separate IP address from the same NAP >> through the same PAA? >>> It's better to have one PANA session but add/delete >> addresses/interfaces. >> >> The simple answer is: all physical interfaces should do PANA >> independently. >> Is there a problem with that? > > This is not a good approach. Just think about the re-auth message flood, > multiple session state information and even possibly multiple AAA backend > sessions on the core network. Not scalable. Consumes resources on the client > and on the network unnecessarily. > > Another point is that adding new interface to the existing session is faster > than doing the whole AA process from scratch. You are talking about room for possible optimizations, not problems. I suggest we open this as a new issue, and follow it up from there. Rather than continuously optimizing the basic design. I think such optimizations touch more than the PANA design, so we should do a more thorough analysis. Alper From pana-request@research.telcordia.com Wed Jun 11 16:38:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00468 for ; Wed, 11 Jun 2003 16:38:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5BKZtD7017799; Wed, 11 Jun 2003 16:35:55 -0400 (EDT) Resent-Date: Wed, 11 Jun 2003 16:35:55 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 10:17:05 -0700 To: Alper Yegin Cc: Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030610171705.GE6685@steelhead> Mail-Followup-To: Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 108 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Alper, Are you suggesting either IP address or MAC address is always enough as DI? I am asking this because I thought that there is a consensus on supporting an option not only for using either L2 or L3 ciphers but also for using both L2 and L3 ciphers. This is because L2 ciphers does not solve the problem of spoofing of network layer information such as IP address. SEND will solve IP address spoofing for ND but I think subsequent data traffic can be still spoofed if it is not protected with IPsec. And the discussion result is reflected in the current design of Protection-Capability AVP: 9.4.5 Protection-Capability AVP The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data is used as a collection of flags for different data ^^^^^^^^^^^^^^^^^^^^^^^^ protection capability indications. Below is a list of specified data protection capabilities: 0 UNKNOWN 1 L2_PROTECTION 2 IPSEC_PROTECTION So 3(=1+2) can be specified as the AVP value. Note that this does not necessarily mean that {Add,Delete}-Device-Id AVP is needed. Alternatively, PaC can always send the list of device identifiers currently in use. Yoshihiro Ohba On Wed, Jun 11, 2003 at 12:03:43PM -0700, Alper Yegin wrote: > >>> What if the MN wants to access the local network with link > >> local or site local > >>> addresses at the same time with a global CoA address? > >> > >> We have discussed this. Depending on the DI: > >> > >> - if MAC address: then there is no issue. PaC can configure any > >> IP address on the specified MAC address. Access control is based on > >> the MAC address. > > > > Where is this kind of scenario feasible? > > In scenarios described in sections 4.1 and 4.2 of the usage scenarios draft, > plus 4.3 where link-layer ciphers are enabled at the end of PANA. > Effectively, almost anywhere IPsec is not used for access control. > > > > > That would mean that PaC can freely spoof IP addresses. > > Exactly. But, this is a SEND problem, not PANA problem. > > > I don't think it's a > > good idea. Filtering should be based on IP addresses as well. PANA is IP level > > protocol.. > > > >> - if IP address: This is the case where IPsec is used. For this, PaC > >> determines one of the IP addresses as DI, most probably a link-local > >> address. The traffic is tunneled using this DI as the local > >> end point. See > >> PANA-Ipsec draft. Now, if the PaC wants to use other IP > >> addresses, they > >> will be used only within the tunnel, hence the access control does not > >> care about them. > > > > If DI is IP address, IPSec is not always used (physically secure links for > > example or links that provide L2 protection). Right? > > If we are not using IPsec,it does not make sense to use IP address as the > DI, unless we are trying to solve SEND problems here. We should use > lower-layer identifiers. > > > > >> > >>> > >>> What if the MN has multiple interfaces (WLAN, Bluetooth, > >> Ethernet, 3G, etc.) > >>> that all get a separate IP address from the same NAP > >> through the same PAA? > >>> It's better to have one PANA session but add/delete > >> addresses/interfaces. > >> > >> The simple answer is: all physical interfaces should do PANA > >> independently. > >> Is there a problem with that? > > > > This is not a good approach. Just think about the re-auth message flood, > > multiple session state information and even possibly multiple AAA backend > > sessions on the core network. Not scalable. Consumes resources on the client > > and on the network unnecessarily. > > > > Another point is that adding new interface to the existing session is faster > > than doing the whole AA process from scratch. > > You are talking about room for possible optimizations, not problems. > I suggest we open this as a new issue, and follow it up from there. Rather > than continuously optimizing the basic design. I think such optimizations > touch more than the PANA design, so we should do a more thorough analysis. > > > Alper > > From pana-request@research.telcordia.com Thu Jun 12 00:15:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14010 for ; Thu, 12 Jun 2003 00:15:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5C4CC0H015842; Thu, 12 Jun 2003 00:12:12 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 00:12:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 21:13:16 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <20030610171705.GE6685@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yoshi, > Are you suggesting either IP address or MAC address is always enough > as DI? For solving in-scope problems, yes. > > I am asking this because I thought that there is a consensus on > supporting an option not only for using either L2 or L3 ciphers but > also for using both L2 and L3 ciphers. This is because L2 ciphers > does not solve the problem of spoofing of network layer information > such as IP address. SEND will solve IP address spoofing for ND but I > think subsequent data traffic can be still spoofed if it is not > protected with IPsec. And the discussion result is reflected in the > current design of Protection-Capability AVP: > > 9.4.5 Protection-Capability AVP > > The Protection-Capability AVP (Code 1028) is of type Unsigned32. > The AVP data is used as a collection of flags for different data > ^^^^^^^^^^^^^^^^^^^^^^^^ > protection capability indications. Below is a list of specified > data protection capabilities: > > 0 UNKNOWN > 1 L2_PROTECTION > 2 IPSEC_PROTECTION > > So 3(=1+2) can be specified as the AVP value. > > Note that this does not necessarily mean that {Add,Delete}-Device-Id > AVP is needed. Alternatively, PaC can always send the list of device > identifiers currently in use. I'm not sure if this is something we should solve, or we can solve easily in PANA. We are dealing with authorization to send and receive packets, not authorization to use a particular IP address. How is this solved today, or is it solved elsewhere? There might be non-protocol solutions to this problem. For example, when there is either link-layer encryption or IPsec encryption, an attacker cannot easily figure out the IP address of a victim. If the attacker tries different random addresses, its activity can be detected by its EP. If it somehow learns the IP address of the victim, the anomaly (same IP address coming from different locations) may be detected. Alper > > Yoshihiro Ohba > > On Wed, Jun 11, 2003 at 12:03:43PM -0700, Alper Yegin wrote: >>>>> What if the MN wants to access the local network with link >>>> local or site local >>>>> addresses at the same time with a global CoA address? >>>> >>>> We have discussed this. Depending on the DI: >>>> >>>> - if MAC address: then there is no issue. PaC can configure any >>>> IP address on the specified MAC address. Access control is based on >>>> the MAC address. >>> >>> Where is this kind of scenario feasible? >> >> In scenarios described in sections 4.1 and 4.2 of the usage scenarios draft, >> plus 4.3 where link-layer ciphers are enabled at the end of PANA. >> Effectively, almost anywhere IPsec is not used for access control. >> >>> >>> That would mean that PaC can freely spoof IP addresses. >> >> Exactly. But, this is a SEND problem, not PANA problem. > >> >>> I don't think it's a >>> good idea. Filtering should be based on IP addresses as well. PANA is IP >>> level >>> protocol.. >>> >>>> - if IP address: This is the case where IPsec is used. For this, PaC >>>> determines one of the IP addresses as DI, most probably a link-local >>>> address. The traffic is tunneled using this DI as the local >>>> end point. See >>>> PANA-Ipsec draft. Now, if the PaC wants to use other IP >>>> addresses, they >>>> will be used only within the tunnel, hence the access control does not >>>> care about them. >>> >>> If DI is IP address, IPSec is not always used (physically secure links for >>> example or links that provide L2 protection). Right? >> >> If we are not using IPsec,it does not make sense to use IP address as the >> DI, unless we are trying to solve SEND problems here. We should use >> lower-layer identifiers. >> >>> >>>> >>>>> >>>>> What if the MN has multiple interfaces (WLAN, Bluetooth, >>>> Ethernet, 3G, etc.) >>>>> that all get a separate IP address from the same NAP >>>> through the same PAA? >>>>> It's better to have one PANA session but add/delete >>>> addresses/interfaces. >>>> >>>> The simple answer is: all physical interfaces should do PANA >>>> independently. >>>> Is there a problem with that? >>> >>> This is not a good approach. Just think about the re-auth message flood, >>> multiple session state information and even possibly multiple AAA backend >>> sessions on the core network. Not scalable. Consumes resources on the client >>> and on the network unnecessarily. >>> >>> Another point is that adding new interface to the existing session is faster >>> than doing the whole AA process from scratch. >> >> You are talking about room for possible optimizations, not problems. >> I suggest we open this as a new issue, and follow it up from there. Rather >> than continuously optimizing the basic design. I think such optimizations >> touch more than the PANA design, so we should do a more thorough analysis. >> >> >> Alper >> >> > > From pana-request@research.telcordia.com Thu Jun 12 01:30:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15326 for ; Thu, 12 Jun 2003 01:30:03 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5C5Rh05003836; Thu, 12 Jun 2003 01:27:43 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 01:27:43 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 10 Jun 2003 19:15:01 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030611021501.GE7682@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <20030610171705.GE6685@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 72 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Jun 11, 2003 at 09:13:16PM -0700, Alper Yegin wrote: > > Hi Yoshi, > > > Are you suggesting either IP address or MAC address is always enough > > as DI? > > For solving in-scope problems, yes. > > > > > I am asking this because I thought that there is a consensus on > > supporting an option not only for using either L2 or L3 ciphers but > > also for using both L2 and L3 ciphers. This is because L2 ciphers > > does not solve the problem of spoofing of network layer information > > such as IP address. SEND will solve IP address spoofing for ND but I > > think subsequent data traffic can be still spoofed if it is not > > protected with IPsec. And the discussion result is reflected in the > > current design of Protection-Capability AVP: > > > > 9.4.5 Protection-Capability AVP > > > > The Protection-Capability AVP (Code 1028) is of type Unsigned32. > > The AVP data is used as a collection of flags for different data > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > protection capability indications. Below is a list of specified > > data protection capabilities: > > > > 0 UNKNOWN > > 1 L2_PROTECTION > > 2 IPSEC_PROTECTION > > > > So 3(=1+2) can be specified as the AVP value. > > > > Note that this does not necessarily mean that {Add,Delete}-Device-Id > > AVP is needed. Alternatively, PaC can always send the list of device > > identifiers currently in use. > > I'm not sure if this is something we should solve, or we can solve easily in > PANA. We are dealing with authorization to send and receive packets, not > authorization to use a particular IP address. I think I don't understand. When PANA is used for bootstraping IKE, how we can dealing with authorization to send and receive packets without authorization to use a particular IP address? > > How is this solved today, or is it solved elsewhere? There might be > non-protocol solutions to this problem. Some enterprise requires the use of IPsec-VPN to access their network via intranet 802.11 AP with WEP. Even WEP will be replaced with 802.11i, they might still require the use of IPsec-VPN to improve enterprise security furthermore. > For example, when there is either > link-layer encryption or IPsec encryption, an attacker cannot easily figure > out the IP address of a victim. If the attacker tries different random > addresses, its activity can be detected by its EP. If it somehow learns the > IP address of the victim, the anomaly (same IP address coming from different > locations) may be detected. - An insider that is authorized at layer-2 can be an attacker at layer-3. - Broadcast/multicast L2 frames reveals the victim's IP address to the insider attacker. - Since IP address is not only the spoofable field, the anomaly does not provide a complete solution. > > Alper > Yoshihiro Ohba From pana-request@research.telcordia.com Thu Jun 12 17:12:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27213 for ; Thu, 12 Jun 2003 17:11:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5CL8GWd024649; Thu, 12 Jun 2003 17:08:16 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 17:08:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 12 Jun 2003 14:09:07 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <20030611021501.GE7682@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> I'm not sure if this is something we should solve, or we can solve easily in >> PANA. We are dealing with authorization to send and receive packets, not >> authorization to use a particular IP address. > > I think I don't understand. When PANA is used for bootstraping IKE, > how we can dealing with authorization to send and receive packets > without authorization to use a particular IP address? Yes, when IPsec is used, the IP address that is used as DI is cryptographically bound to the PaC, hence PaC can: a- prove that it is authorized to send IP packets b- prove that it is authorized to use that particular IP address In the context of PANA, (a) is our goal. (b) is there only because this is how IPsec works. If there were another per-packet protection mechanism that does not need to bind the IP address to the trust relation, we could still satisfy the PANA requirements using that, and that wouldn't involve proving ownership of an IP address. We might (have to) enable proving ownership of one DI to the EP as part of proving authorization to send packets. But we do not have to extend this to enable proving ownership of every IP address used by the PaC. > >> >> How is this solved today, or is it solved elsewhere? There might be >> non-protocol solutions to this problem. > > Some enterprise requires the use of IPsec-VPN to access their network > via intranet 802.11 AP with WEP. Even WEP will be replaced with > 802.11i, they might still require the use of IPsec-VPN to improve > enterprise security furthermore. Does IPsec-VPN provide checks for authorization to use IP addresses, other than the tunnel end point addresses? Does it automatically prevent use of arbitrary IP addresses inside the tunnel? > >> For example, when there is either >> link-layer encryption or IPsec encryption, an attacker cannot easily figure >> out the IP address of a victim. If the attacker tries different random >> addresses, its activity can be detected by its EP. If it somehow learns the >> IP address of the victim, the anomaly (same IP address coming from different >> locations) may be detected. > > - An insider that is authorized at layer-2 can be an attacker at layer-3. > - Broadcast/multicast L2 frames reveals the victim's IP address > to the insider attacker. > - Since IP address is not only the spoofable field, the anomaly > does not provide a complete solution. Alper > >> >> Alper >> > > Yoshihiro Ohba > From pana-request@research.telcordia.com Thu Jun 12 18:51:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00575 for ; Thu, 12 Jun 2003 18:51:11 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5CMmjKq007784; Thu, 12 Jun 2003 18:48:45 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 18:48:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 13:04:27 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030611200427.GC10378@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <20030611021501.GE7682@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 87 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <04MPsC.A.L5B.MNQ6-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree that when IP address is used as DI, binding one IP address (the one used as the IPsec tunnel endpoint address) to a PANA SA might be sufficient. Any IP address that is used only inside the IPsec tunnel does not need to be bound to the PANA SA. On the other hand, this does not mean that we should not use both MAC address and IP address as the DI, if we consider the case in which both L2 and L3 ciphering are used at the same time. Both ciphering can be bootstraped by using PANA at the same time. Regarding existing IPsec-VPN, the IPsec gateway assigns an inner IP address to the IPsec client host. Of course the IPsec gateway does not care if additional level(s) of tunneling is made inside IPsec tunnel and whichever IP address is used at each level, as long as it sees the particular inner IP address when it decapsulate/encapsulate a packet. Yoshihiro Ohba On Thu, Jun 12, 2003 at 02:09:07PM -0700, Alper Yegin wrote: > >> I'm not sure if this is something we should solve, or we can solve easily in > >> PANA. We are dealing with authorization to send and receive packets, not > >> authorization to use a particular IP address. > > > > I think I don't understand. When PANA is used for bootstraping IKE, > > how we can dealing with authorization to send and receive packets > > without authorization to use a particular IP address? > > Yes, when IPsec is used, the IP address that is used as DI is > cryptographically bound to the PaC, hence PaC can: > a- prove that it is authorized to send IP packets > b- prove that it is authorized to use that particular IP address > > In the context of PANA, (a) is our goal. (b) is there only because this is > how IPsec works. If there were another per-packet protection mechanism that > does not need to bind the IP address to the trust relation, we could still > satisfy the PANA requirements using that, and that wouldn't involve proving > ownership of an IP address. > > We might (have to) enable proving ownership of one DI to the EP as part of > proving authorization to send packets. But we do not have to extend this to > enable proving ownership of every IP address used by the PaC. > > > > >> > >> How is this solved today, or is it solved elsewhere? There might be > >> non-protocol solutions to this problem. > > > > Some enterprise requires the use of IPsec-VPN to access their network > > via intranet 802.11 AP with WEP. Even WEP will be replaced with > > 802.11i, they might still require the use of IPsec-VPN to improve > > enterprise security furthermore. > > Does IPsec-VPN provide checks for authorization to use IP addresses, other > than the tunnel end point addresses? Does it automatically prevent use of > arbitrary IP addresses inside the tunnel? > > > > > >> For example, when there is either > >> link-layer encryption or IPsec encryption, an attacker cannot easily figure > >> out the IP address of a victim. If the attacker tries different random > >> addresses, its activity can be detected by its EP. If it somehow learns the > >> IP address of the victim, the anomaly (same IP address coming from different > >> locations) may be detected. > > > > - An insider that is authorized at layer-2 can be an attacker at layer-3. > > - Broadcast/multicast L2 frames reveals the victim's IP address > > to the insider attacker. > > - Since IP address is not only the spoofable field, the anomaly > > does not provide a complete solution. > > > Alper > > > > > >> > >> Alper > >> > > > > Yoshihiro Ohba > > > > From pana-request@research.telcordia.com Thu Jun 12 19:48:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01708 for ; Thu, 12 Jun 2003 19:48:00 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5CNjBom019485; Thu, 12 Jun 2003 19:45:11 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 19:45:11 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 12 Jun 2003 16:46:05 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <20030611200427.GC10378@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit On 6/11/03 1:04 PM, "Yoshihiro Ohba" wrote: > I agree that when IP address is used as DI, binding one IP address > (the one used as the IPsec tunnel endpoint address) to a PANA SA might > be sufficient. Any IP address that is used only inside the IPsec > tunnel does not need to be bound to the PANA SA. > > On the other hand, this does not mean that we should not use both MAC > address and IP address as the DI, if we consider the case in which > both L2 and L3 ciphering are used at the same time. Both ciphering > can be bootstraped by using PANA at the same time. I thought your original message was suggesting using L2 and L3 ciphering at the same time to solve IP address ownership problem. I don't see this problem as a motivation to use L2-L3 ciphering at the same time, since the problem itself is outside the scope of PANA. If we include L2-L3 ciphering for another reason (did we find one?), and it solves this problem with no change to the protocol design, then its fine. > > Regarding existing IPsec-VPN, the IPsec gateway assigns an inner IP > address to the IPsec client host. Of course the IPsec gateway does > not care if additional level(s) of tunneling is made inside IPsec > tunnel and whichever IP address is used at each level, as long as it > sees the particular inner IP address when it decapsulate/encapsulate a > packet. Then probably a DHCP server/proxy co-located with EP is all one needs. Alper > > Yoshihiro Ohba From pana-request@research.telcordia.com Thu Jun 12 21:52:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04561 for ; Thu, 12 Jun 2003 21:52:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5D1diNP025421; Thu, 12 Jun 2003 21:39:44 -0400 (EDT) Resent-Date: Thu, 12 Jun 2003 21:39:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 15:55:24 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030611225523.GA11571@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <20030611200427.GC10378@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 50 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Jun 12, 2003 at 04:46:05PM -0700, Alper Yegin wrote: > On 6/11/03 1:04 PM, "Yoshihiro Ohba" wrote: > > > I agree that when IP address is used as DI, binding one IP address > > (the one used as the IPsec tunnel endpoint address) to a PANA SA might > > be sufficient. Any IP address that is used only inside the IPsec > > tunnel does not need to be bound to the PANA SA. > > > > On the other hand, this does not mean that we should not use both MAC > > address and IP address as the DI, if we consider the case in which > > both L2 and L3 ciphering are used at the same time. Both ciphering > > can be bootstraped by using PANA at the same time. > > I thought your original message was suggesting using L2 and L3 ciphering at > the same time to solve IP address ownership problem. I don't see this > problem as a motivation to use L2-L3 ciphering at the same time, since the > problem itself is outside the scope of PANA. If we include L2-L3 ciphering > for another reason (did we find one?), and it solves this problem with no > change to the protocol design, then its fine. No, I did not mean that the motivation of using L2 and L3 ciphering at the same time was to solve IP address ownership problem. The motivation is to protect network layer traffic (except for neighbor discovery traffic which is solved by using SEND) from being spoofed by insider attackers who uses L2 ciphering. To protect network layer traffic, IPsec tunnel is used and thus bootstrapping IKE from PANA is needed. This is just an additive combination of bootstrapping L2 and L3 ciphering and thus I don't think we need any change to the current protocol design to achieve this. > > > > > Regarding existing IPsec-VPN, the IPsec gateway assigns an inner IP > > address to the IPsec client host. Of course the IPsec gateway does > > not care if additional level(s) of tunneling is made inside IPsec > > tunnel and whichever IP address is used at each level, as long as it > > sees the particular inner IP address when it decapsulate/encapsulate a > > packet. > > Then probably a DHCP server/proxy co-located with EP is all one needs. In addition, DHCP authentication needs to be bootstraped from PANA. > > Alper > Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Fri Jun 13 14:46:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18187 for ; Fri, 13 Jun 2003 14:46:48 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5DIFSht024510; Fri, 13 Jun 2003 14:15:28 -0400 (EDT) Resent-Date: Fri, 13 Jun 2003 14:15:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 13 Jun 2003 11:14:54 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <20030611225523.GA11571@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> I thought your original message was suggesting using L2 and L3 ciphering at >> the same time to solve IP address ownership problem. I don't see this >> problem as a motivation to use L2-L3 ciphering at the same time, since the >> problem itself is outside the scope of PANA. If we include L2-L3 ciphering >> for another reason (did we find one?), and it solves this problem with no >> change to the protocol design, then its fine. > > No, I did not mean that the motivation of using L2 and L3 ciphering at > the same time was to solve IP address ownership problem. The > motivation is to protect network layer traffic (except for neighbor > discovery traffic which is solved by using SEND) from being spoofed by > insider attackers who uses L2 ciphering. To protect network layer > traffic, IPsec tunnel is used and thus bootstrapping IKE from PANA is > needed. This is just an additive combination of bootstrapping L2 and > L3 ciphering and thus I don't think we need any change to the current > protocol design to achieve this. When L2 ciphering is already used in the network, what kind of protection is gained by also enabling IPsec between the PaC and EP (other than potentially solving IP address ownership issues)? > >> >>> >>> Regarding existing IPsec-VPN, the IPsec gateway assigns an inner IP >>> address to the IPsec client host. Of course the IPsec gateway does >>> not care if additional level(s) of tunneling is made inside IPsec >>> tunnel and whichever IP address is used at each level, as long as it >>> sees the particular inner IP address when it decapsulate/encapsulate a >>> packet. >> >> Then probably a DHCP server/proxy co-located with EP is all one needs. > > In addition, DHCP authentication needs to be bootstraped from PANA. Alper From pana-request@research.telcordia.com Fri Jun 13 15:59:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21305 for ; Fri, 13 Jun 2003 15:59:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5DJuuUR017226; Fri, 13 Jun 2003 15:56:56 -0400 (EDT) Resent-Date: Fri, 13 Jun 2003 15:56:56 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 11 Jun 2003 23:36:14 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030612063614.GA13040@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <20030611225523.GA11571@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 31 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Jun 13, 2003 at 11:14:54AM -0700, Alper Yegin wrote: > >> I thought your original message was suggesting using L2 and L3 ciphering at > >> the same time to solve IP address ownership problem. I don't see this > >> problem as a motivation to use L2-L3 ciphering at the same time, since the > >> problem itself is outside the scope of PANA. If we include L2-L3 ciphering > >> for another reason (did we find one?), and it solves this problem with no > >> change to the protocol design, then its fine. > > > > No, I did not mean that the motivation of using L2 and L3 ciphering at > > the same time was to solve IP address ownership problem. The > > motivation is to protect network layer traffic (except for neighbor > > discovery traffic which is solved by using SEND) from being spoofed by > > insider attackers who uses L2 ciphering. To protect network layer > > traffic, IPsec tunnel is used and thus bootstrapping IKE from PANA is > > needed. This is just an additive combination of bootstrapping L2 and > > L3 ciphering and thus I don't think we need any change to the current > > protocol design to achieve this. > > > When L2 ciphering is already used in the network, what kind of protection is > gained by also enabling IPsec between the PaC and EP (other than potentially > solving IP address ownership issues)? Insider attacker (meaning that he has L2 ciphering keys) can spoof other insider's higher-layer fields in data packets (though he cannot spoof L2 headers). I think SEND only protects ND messages, not data packets. For the same reason, DHCP authentication might be useful even when L2 ciphering is used. Yoshihiro Ohba From pana-request@research.telcordia.com Fri Jun 13 18:18:56 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26180 for ; Fri, 13 Jun 2003 18:18:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5DMFYIX003579; Fri, 13 Jun 2003 18:15:34 -0400 (EDT) Resent-Date: Fri, 13 Jun 2003 18:15:34 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Comments on PANA Requirements I-D Date: Fri, 13 Jun 2003 17:11:10 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4401753746@daebe007.americas.nokia.com> Thread-Topic: Comments on PANA Requirements I-D Thread-Index: AcMx+LBcisuYjP0xRqa5dA0fLoka7Q== From: To: Cc: X-OriginalArrivalTime: 13 Jun 2003 22:11:10.0933 (UTC) FILETIME=[B249B050:01C331F8] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <-MWF5C.A.s3.G0k6-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA26180 Hello, Below are my comments on the PANA requirements I-D which completed WG LC yesterday. I hope these will still be taken into account. -Basavaraj I-D: draft-ietf-pana-requirements-06.txt Review Comments: ---------------- 1. "It is expected that future IP devices will have" - I guess IP devices include routers as well. Maybe it is better to mention IP end-hosts instead of IP devices. 2. s/The goal of the PANA is ... access/The goal of this document is to identify the requirements for a protocol that would be able to provide a link-layer agnostic and IPv4/IPv6 compatible client-server protocol which would allow a host be to be authenticated for network access. 3. s/client's device/host device 4. s/agent device/agent 5. Section 1. a. s/to carry authentication methods/to carry authentication parameters b. d/The IETF PANA Working Group has been chartered with the... c. s/A higher-layer authentication is deemed necessary/A higher-layer authentication protocol is deemed necessary d. s/are not available for lack of technology/do not exist in terms of specifications or standards for a specific access technology e. s/overall requirements/overall authentication and security requirements f. s/The Working Group will not invent new security protocols and mechanisms but instead it will use the existing mechanisms./The intent is to not invent new security protocols and mechanisms but to reuse existing mechanisms such as EAP. g. s/the Working Group will not define new authentication/the requirements do not mandate the need to define 6. Section 3: PaC definition - Alternative proposal. a. PaC The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization. b. PAA - s/The entity/The access network side entity of the protocol whose... c. Maybe you also need to add the term PANA PANA - The protocol between the host device and the access network agent for authentication. While PANA is an acronym for Protocol for ... it is also the name for the protocol itself in the context of this draft. 7. Section 4.1.1: " The current thinking is that a sufficient solution would be for PANA to carry EAP [EAP]. If the PANA WG decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions. " Current thinking becomes outdated pretty soon. So it is better to rephrase this sentence. Suggestion: EAP [EAP] is a candidate protocol that satisfies many of the requirements for authentication. PANA would be a carrier protocol for EAP. "it indirectly enables this by the virtue of carrying EAP" Rephrase as: "it enables this by virtue of selecting the appropriate EAP method." The scope of the protocol does not include key distribution. Yet there is a lot of text explaining how it can be accomplished. I do not believe this is required in the I-D. d/Securing IPv6 router discovery and neighbor discovery protocols are within the scope of the IETF SEND Working Group. 8. Section 4.1.2 PaC's s/authorized to the device./authorized for the authenticated device. 9. Section 4.1.3 s/then it can still/it can still 10. Section 4.1.4 "PaCI is used for access control and accounting in the network as" How is the PaCI used in accounting? 11. Section 4.2 s/Providing address assignment functionality is outside the scope of/Assigning an IP address to the client is outside... 12. Section 4.5.2 " In case the clients cannot send explicit disconnect messages to the PAA, PAA can still detect their departure by relying on periodic authentication requests." This is a requirements I-D. So no reason to get into possible solutions to deal with Disconnect Indication. 13. Section 4.5.3 "That is, there must be no IP routers between the two" One hop away may include scenarios where there is a routed network but the packets are tunnelled over the routed network. For example in the case of GPRS, the GGSN is the AR, and it can be considered to be one hop from the MN at the IP layer, but there exists a routed network between the MN and the GGSN. "A PaC MAY NOT be pre-configured with the IP address of PAA." Why not? This is one possible solution that should be okay. 14. Section 4.7 The performance requirement is a bit difficult to quantify. So this requirement would cause some treading on water. 15. Section 6 Move the change log to an appendix. From pana-request@research.telcordia.com Fri Jun 13 19:49:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28821 for ; Fri, 13 Jun 2003 19:49:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5DNlSsN023611; Fri, 13 Jun 2003 19:47:28 -0400 (EDT) Resent-Date: Fri, 13 Jun 2003 19:47:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 13 Jun 2003 16:48:32 -0700 Subject: Re: Comments on PANA Requirements I-D From: Alper Yegin To: CC: Message-ID: In-Reply-To: <697DAA22C5004B4596E033803A7CEF4401753746@daebe007.americas.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Thank you Raj for the feedback. My comments inlined below... > 1. "It is expected that future IP devices will have" - I guess IP > devices include routers as well. Maybe it is better to mention > IP end-hosts instead of IP devices. The PaC might be a router as well. For example, the border gateway router in a NEMO network. > > 2. s/The goal of the PANA is ... access/The goal of this document is > to identify the requirements for a protocol that would be able to > provide a link-layer agnostic and IPv4/IPv6 compatible > client-server protocol which would allow a host be to be > authenticated for network access. I think I should also change the last part to "... allow a host and network authenticate each other for network access". Or else, it sounds like all we care is one way authentication. > > 3. s/client's device/host device "host" might be limiting since it excludes "router." > > 4. s/agent device/agent Ok. > > 5. Section 1. > a. s/to carry authentication methods/to carry authentication > parameters > > b. d/The IETF PANA Working Group has been chartered with the... > > c. s/A higher-layer authentication is deemed necessary/A > higher-layer authentication protocol is deemed necessary > > d. s/are not available for lack of technology/do not exist in terms > of specifications or standards for a specific access technology > > e. s/overall requirements/overall authentication and security > requirements > > f. s/The Working Group will not invent new security protocols and > mechanisms but instead it will use the existing mechanisms./The > intent is to not invent new security protocols and mechanisms but > to reuse existing mechanisms such as EAP. > > g. s/the Working Group will not define new authentication/the > requirements do not mandate the need to define Agreed to all. > > 6. Section 3: > > PaC definition - Alternative proposal. > a. PaC The client side of the protocol that resides in the host > device which is responsible for providing the credentials to prove > its identity for network access authorization. Ok. > > b. PAA - s/The entity/The access network side entity of the > protocol whose... Ok. > > c. Maybe you also need to add the term PANA > PANA - The protocol between the host device and the access network > agent for authentication. While PANA is an acronym for Protocol > for ... it is also the name for the protocol itself in the context > of this draft. I'm not sure about this one, because the full name of the protocol already says "protocol for ....". Does this still leave ambiguity regarding what is PANA (name of the protocol, vs. name of the WG, vs. ...) > > 7. Section 4.1.1: > " > The current thinking is that a sufficient solution would be for > PANA to carry EAP [EAP]. If the PANA WG decides that extensions to > EAP are needed, it will define requirements for the EAP WG instead > of designing such extensions. > " > Current thinking becomes outdated pretty soon. So it is better to > rephrase this sentence. Suggestion: > EAP [EAP] is a candidate protocol that satisfies many of the > requirements for authentication. PANA would be a carrier protocol > for EAP. OK. > > "it indirectly enables this by the virtue of carrying EAP" > Rephrase as: "it enables this by virtue of selecting the appropriate > EAP method." Selection of EAP method is not done by PANA, so I'd say: "It enables this by the virtue of carrying EAP and allowing appropriate EAP method selection." > > The scope of the protocol does not include key distribution. Yet > there is a lot of text explaining how it can be accomplished. I do > not believe this is required in the I-D. Hmmm. We ended up doing this in the process of clarifying how PANA enables per-packet protection. I'd feel uncomfortable removing them, as it'd generate the same set of questions again... > > d/Securing IPv6 router discovery and neighbor discovery protocols > are within the scope of the IETF SEND Working Group. OK, I guess. > > 8. Section 4.1.2 > PaC's > > s/authorized to the device./authorized for the authenticated > device. Ok. > > 9. Section 4.1.3 > s/then it can still/it can still Ok. > > 10. Section 4.1.4 > "PaCI is used for access control and accounting in the network as" > How is the PaCI used in accounting? No, it is the "binding between DI and PaCI" that is used for accounting. The network determines the usage by observing traffic generated with DI and then sends the bill to the user identified by PaCI. > > 11. Section 4.2 > s/Providing address assignment functionality is outside the scope > of/Assigning an IP address to the client is outside... Ok. > > 12. Section 4.5.2 > " In case the clients cannot send explicit disconnect messages to the > PAA, PAA can still detect their departure by relying on periodic > authentication requests." > > This is a requirements I-D. So no reason to get into possible > solutions to deal with Disconnect Indication. This was in response to the question "what happens if PaC cannot send a disconnect". I think this is informative, and not problematic. I'm inclined to keep it. > > 13. Section 4.5.3 > > "That is, there must be no IP routers between the two" > > One hop away may include scenarios where there is a routed network > but the packets are tunnelled over the routed network. For example > in the case of GPRS, the GGSN is the AR, and it can be considered > to be one hop from the MN at the IP layer, but there exists a > routed network between the MN and the GGSN. Agreed. > > "A PaC MAY NOT be pre-configured with the IP address of PAA." > Why not? This is one possible solution that should be okay. OK, the current language is misleading. We meant there is no requirement that PaC will be pre-configured with this information. Maybe I should replace "MAY NOT" with "may or may not". > > 14. Section 4.7 > The performance requirement is a bit difficult to quantify. So > this requirement would cause some treading on water. Yes, all it says is "think about performance too." > > 15. Section 6 > Move the change log to an appendix. I'll remove it. Alper From pana-request@research.telcordia.com Mon Jun 16 20:44:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10603 for ; Mon, 16 Jun 2003 20:44:10 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5H0eGId000161; Mon, 16 Jun 2003 20:40:16 -0400 (EDT) Resent-Date: Mon, 16 Jun 2003 20:40:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 16 Jun 2003 17:42:45 -0700 To: pana@research.telcordia.com Subject: Issue 3: PANA SA Message-ID: <20030617004245.GA746@steelhead> Mail-Followup-To: pana@research.telcordia.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 55 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is the initial text for resolution of Issue 3: PANA SA. So far, I have not seen a requirement for confidentiality provisioning at PANA layer and such provisioning is not included in the initial text. Comments are appreciated. Yoshihiro Ohba ---------- Detailed description on PANA Security Association (PANA SA) o When it is created? 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) [RFC2284bis]. A PANA SA is not created when the EAP authentication fails or does not use an EAP authentication method that creates a MSK. 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. o When it is removed? The created PANA SA is deleted when the corresponding PANA session is deleted. The lifetime of the PANA SA is the same as the lifetime of the PANA session for simplicity. o What information is included in it? PANA SA attributes as well as PANA session attributes are listed below: PANA Session attributes - Session-Id - Device-Id of PaC - Device-Id of PAA - Initial tseq of PaC (ISN_pac) - Initial tseq of PAA (ISN_paa) - Last transmitted tseq value - Last received rseq value - Last transmitted message payload - Retransmission interval - Session lifetime - Protection-Capability - PANA SA attributes + MSK + PANA_MAC_Key o How the PANA_MAC_Key is derived? PANA_MAC_KEY = the first 128 bits of HMAC_SHA1(MSK, ISN_pac | ISN_paa | SessionID) The length of MSK MUST be 128-bit or longer. From pana-request@research.telcordia.com Tue Jun 17 15:23:41 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05941 for ; Tue, 17 Jun 2003 15:23:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5HJKLhN011016; Tue, 17 Jun 2003 15:20:21 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 15:20:21 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on PANA Requirements I-D Date: Tue, 17 Jun 2003 14:15:21 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440175377F@daebe007.americas.nokia.com> Thread-Topic: Comments on PANA Requirements I-D Thread-Index: AcMyCHSocARWzYLHS12ZkHVu6XMbKQC/E/3Q From: To: Cc: X-OriginalArrivalTime: 17 Jun 2003 19:15:22.0433 (UTC) FILETIME=[CC8B5310:01C33504] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05941 Alper Yegin [alper@docomolabs-usa.com] wrote: > >Thank you Raj for the feedback. >My comments inlined below... > >> 1. "It is expected that future IP devices will have" - I guess IP >> devices include routers as well. Maybe it is better to mention >> IP end-hosts instead of IP devices. > >The PaC might be a router as well. For example, the border gateway router in >a NEMO network. Okay. I guess that is true and needs to be tackled by PANA. >> 2. s/The goal of the PANA is ... access/The goal of this document is >> to identify the requirements for a protocol that would be able to >> provide a link-layer agnostic and IPv4/IPv6 compatible >> client-server protocol which would allow a host be to be >> authenticated for network access. > >I think I should also change the last part to "... allow a host and network >authenticate each other for network access". Or else, it sounds like all we >care is one way authentication. Your suggestion for rephrasing sounds good. >> c. Maybe you also need to add the term PANA >> PANA - The protocol between the host device and the access network >> agent for authentication. While PANA is an acronym for Protocol >> for ... it is also the name for the protocol itself in the context >> of this draft. > >I'm not sure about this one, because the full name of the protocol already >says "protocol for ....". Does this still leave ambiguity regarding what is >PANA (name of the protocol, vs. name of the WG, vs. ...) I know. But we tend to use PANA also as the name for a protocol (like Diameter). So that was the reason for suggesting that PANA be not only the acronym for the WG but also the name for the protocol itself. Either way is fine. >> "it indirectly enables this by the virtue of carrying EAP" >> Rephrase as: "it enables this by virtue of selecting the appropriate >> EAP method." > >Selection of EAP method is not done by PANA, so I'd say: > >"It enables this by the virtue of carrying EAP and allowing appropriate EAP >method selection." Okay. > >> >> The scope of the protocol does not include key distribution. Yet >> there is a lot of text explaining how it can be accomplished. I do >> not believe this is required in the I-D. > >Hmmm. We ended up doing this in the process of clarifying how PANA enables >per-packet protection. I'd feel uncomfortable removing them, as it'd >generate the same set of questions again... > Well.. we address this in the FAQ and we mention that this is out of scope. So why go to such length in the draft justifying the reasons for not including key distribution. Minimal text would suffice. >> >> d/Securing IPv6 router discovery and neighbor discovery protocols >> are within the scope of the IETF SEND Working Group. > >OK, I guess. When this document gets published, there may not exist WGs that are referenced here. So in order to keep the text relevant it is better to simply say it is out of scope rather than pointing where the work is done. >> 10. Section 4.1.4 >> "PaCI is used for access control and accounting in the network as" >> How is the PaCI used in accounting? > >No, it is the "binding between DI and PaCI" that is used for accounting. The >network determines the usage by observing traffic generated with DI and then >sends the bill to the user identified by PaCI. Okay. But note that PANA has nothing to do with accounting. >> 12. Section 4.5.2 >> " In case the clients cannot send explicit disconnect messages to the >> PAA, PAA can still detect their departure by relying on periodic >> authentication requests." >> >> This is a requirements I-D. So no reason to get into possible >> solutions to deal with Disconnect Indication. > >This was in response to the question "what happens if PaC cannot send a >disconnect". I think this is informative, and not problematic. I'm inclined >to keep it. Okay. Then maybe the requirement can be better drawn from the problem that is faced in access networks. -Basavaraj From pana-request@research.telcordia.com Tue Jun 17 16:54:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11021 for ; Tue, 17 Jun 2003 16:54:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5HKpsDa008034; Tue, 17 Jun 2003 16:51:54 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 16:51:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 17 Jun 2003 13:53:01 -0700 Subject: Re: Comments on PANA Requirements I-D From: Alper Yegin To: CC: Message-ID: In-Reply-To: <697DAA22C5004B4596E033803A7CEF440175377F@daebe007.americas.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> The scope of the protocol does not include key distribution. Yet >>> there is a lot of text explaining how it can be accomplished. I do >>> not believe this is required in the I-D. >> >> Hmmm. We ended up doing this in the process of clarifying how PANA enables >> per-packet protection. I'd feel uncomfortable removing them, as it'd >> generate the same set of questions again... >> > > Well.. we address this in the FAQ and we mention that this is out of > scope. So why go to such length in the draft justifying the reasons > for not including key distribution. Minimal text would suffice. The problem is, it is hard to capture the current picture in few sentences. Saying key distribution/derivation is outside the scope of PANA is not sufficient, imo. We somehow need to capture that PANA design does nothing more than carrying EAP, and EAP provides key generation functionality. Also, we need to capture that the keys EAP generates are not readily useful for data protection, but then this is also not for PANA to worry about. The relevant text draws a complete picture (from access authentication to per-packet security), and in most of the cases it ends up pointing out what is outside the scope of PANA. Alper From pana-request@research.telcordia.com Tue Jun 17 23:29:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21057 for ; Tue, 17 Jun 2003 23:29:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5I3PXop023582; Tue, 17 Jun 2003 23:25:33 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 23:25:33 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 17 Jun 2003 20:26:35 -0700 Subject: FW: [eap] EAP WG last call on RFC 2284bis From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <9GC0z.A.QwF.tu97-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit FYI.... ------ Forwarded Message From: Bernard Aboba Date: Mon, 16 Jun 2003 05:55:38 -0700 (PDT) To: eap@frascone.com Subject: [eap] EAP WG last call on RFC 2284bis This is an announcement of EAP WG last call on RFC 2284bis, prior to sending it on to the IESG for consideration as an IETF Proposed Standard. The draft is not yet available on the IETF archive, but should be there by Wednesday or Thursday at the latest. Until then, it is available for examination here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.e. txt When it arrives on the archive, the document will be available for examination here: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP WG last call will last until July 7, 2003. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------ End of Forwarded Message From pana-request@research.telcordia.com Tue Jun 17 23:34:15 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21214 for ; Tue, 17 Jun 2003 23:34:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5I3Vnrp019613; Tue, 17 Jun 2003 23:31:49 -0400 (EDT) Resent-Date: Tue, 17 Jun 2003 23:31:49 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments on PANA Requirements I-D Date: Tue, 17 Jun 2003 22:31:05 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF440175378F@daebe007.americas.nokia.com> Thread-Topic: Comments on PANA Requirements I-D Thread-Index: AcM1EkgsBRTN78ueTOWma/N+N2jKlAAN7mUQ From: To: Cc: X-OriginalArrivalTime: 18 Jun 2003 03:31:08.0776 (UTC) FILETIME=[0EBF0E80:01C3354A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21214 > >>> The scope of the protocol does not include key distribution. Yet > >>> there is a lot of text explaining how it can be > accomplished. I do > >>> not believe this is required in the I-D. > >> > >> Hmmm. We ended up doing this in the process of clarifying > how PANA enables > >> per-packet protection. I'd feel uncomfortable removing > them, as it'd > >> generate the same set of questions again... > >> > > > > Well.. we address this in the FAQ and we mention that this is out of > > scope. So why go to such length in the draft justifying the reasons > > for not including key distribution. Minimal text would suffice. > > The problem is, it is hard to capture the current picture in > few sentences. > Saying key distribution/derivation is outside the scope of PANA is not > sufficient, imo. We somehow need to capture that PANA design > does nothing > more than carrying EAP, and EAP provides key generation > functionality. Also, > we need to capture that the keys EAP generates are not > readily useful for > data protection, but then this is also not for PANA to worry > about. The > relevant text draws a complete picture (from access authentication to > per-packet security), and in most of the cases it ends up > pointing out what > is outside the scope of PANA. > Okay. Lets leave it in then. > Alper > -BP From pana-request@research.telcordia.com Wed Jun 18 20:05:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07674 for ; Wed, 18 Jun 2003 20:05:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5J01c1k008101; Wed, 18 Jun 2003 20:01:38 -0400 (EDT) Resent-Date: Wed, 18 Jun 2003 20:01:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 18 Jun 2003 03:09:56 -0700 To: pana@research.telcordia.com Subject: Re: Issue 3: PANA SA Message-ID: <20030618100956.GA1902@steelhead> Mail-Followup-To: pana@research.telcordia.com References: <20030617004245.GA746@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20030617004245.GA746@steelhead> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 62 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com I've added some text to deal with a corner case where two EAP authentications are used and each produces its own MSK, resulting in two MSKs. In this case, binding the PANA SA to one of those MSK might be sufficient. I also updated key derivation expression based on the fact that the default MAC algorithm is HMAC-SHA1 which needs 160-bit key length. (Issue: do we need to support multiple MAC algorithms?) Yoshihiro Ohba ----- Detailed description on PANA Security Association (PANA SA) o When it is created? 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) [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. o When it is removed? The created PANA SA is deleted when the corresponding PANA session is deleted. The lifetime of the PANA SA is the same as the lifetime of the PANA session for simplicity. o What information is included in it? PANA SA attributes as well as PANA session attributes are listed below: PANA Session attributes - Session-Id - Device-Id of PaC - Device-Id of PAA - Initial tseq of PaC (ISN_pac) - Initial tseq of PAA (ISN_paa) - Last transmitted tseq value - Last received rseq value - Last transmitted message payload - Retransmission interval - Session lifetime - Protection-Capability - PANA SA attributes + MSK + PANA_MAC_Key o How the PANA_MAC_Key is derived? PANA_MAC_KEY = HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID) The length of MSK MUST be 160-bit or longer. From pana-request@research.telcordia.com Sat Jun 21 21:53:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20348 for ; Sat, 21 Jun 2003 21:53:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5M1nqOo028636; Sat, 21 Jun 2003 21:49:52 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 21:49:52 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Securing the first hop in PANA using IPsec Date: Sat, 21 Jun 2003 18:49:11 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47C@TNEXVS02.tahoenetworks.com> Thread-Topic: Securing the first hop in PANA using IPsec Thread-Index: AcMhTjLJyirmzlqcRnaCAC0gZbSYxAXEYaGA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Francis Dupont" Cc: "Jean-Michel COMBES" , "Alper Yegin" , "pana" X-OriginalArrivalTime: 22 Jun 2003 01:49:12.0103 (UTC) FILETIME=[7A93D370:01C33860] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Catching up on this thread (back from my vacation) Just on this point... > > > IMHO, a better approach is to mention the possibility of > the two modes > > (i.e., ESP/tunnel mode and ESP/transport mode w/IP-in-IP) for > > protecting traffic PaC and EP with IPsec, and to describe how the > > mode(s) supported by the EP should be indicated to the > PaC by using > > PANA and/or one mode is chosen during IKE negotiation. > > > > => to leave the choice is more complex. Simplicity was a > design goal. > > But is draft-touch-ipsec-vpn-05.txt a standard method? If it is not a > standard method, how can we maintain interoperability if we mandate > the method only. > There is nothing to do with a standard here. If you have a tunnel and have IPsec policy based on the outer header's source address e.g. [IF SRC = OUTER-TUNNEL-SRC-ADDRESS] apply IPsec, then the transport SA you negotiate will protect all traffic coming out of the tunnel. This is standard IPsec. I agree that the document does not discuss the issues related to this well. I will calrify this in my next version. -mohan > > > > > => this is far easier/simpler in the case of double > IPsec, a case which > > > is assumed to be common. > > > > It seems that the issue of double IPsec is all about > implementation > > details. If so, we could remove it from the draft or > move it to an > > appendix. > > > > => it was considered important to have the best support for > this case, > > so it should not be throw away or to an appendix without > strong arguments > > showing that this case (double IPsec) will be marginal. > > I don't understand why the described approach is best because > the draft > does not give enough information or references on why it is considered > to be best. I'd rather think that the best place to discuss double > IPsec is the IPsec WG, not the PANA WG. > > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Sat Jun 21 23:08:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21568 for ; Sat, 21 Jun 2003 23:08:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5M3176N012626; Sat, 21 Jun 2003 23:01:07 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 23:01:07 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Securing the first hop in PANA using IPsec Date: Sat, 21 Jun 2003 20:01:00 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1441@TNEXVS02.tahoenetworks.com> Thread-Topic: Securing the first hop in PANA using IPsec Thread-Index: AcMkHBpXWWNfmAAUTeulVyo3eU5MGAUTdKLA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Francis Dupont" Cc: "Jean-Michel COMBES" , "Alper Yegin" , "pana" X-OriginalArrivalTime: 22 Jun 2003 03:01:00.0948 (UTC) FILETIME=[82D96540:01C3386A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshihiro, A few questions below.. > > On Mon, May 26, 2003 at 05:37:12PM +0200, Francis Dupont wrote: > > In your previous mail you wrote: > > > > How is the policy of using IP-in-IP negotiated in IKE? > > > > => no, IP-in-IP is not negociated by IKE. IKE can only negociate SAs > > and in this case IKE negociates the transport mode SA pair > to protect > > packets going through the IP-in-IP tunnel. > > Yes, that is my understanding. > > > > > If you assume > > a pre-configured policy on this, it is very hard to interoperate > > because (i) in most cases (or policies) transport mode > is used without > > IP-in-IP encapsulation and thus policy mis-configuration > is likely to > > occur, > > > > => the IPsec policy is very simple: protect packets going > through the > > IP-in-IP tunnel, i.e., source and destination = PaC and EP > (link-local) > > addresses, protocol = IP-in-IP (4 or 41). > > This is not simpler than using IPsec tunnel mode, since tunnel mode > automatically comes with tunneling without introducing new policies, > while IP-in-IP/transport mode needs a new policy to use IP-in-IP > encapsulation. I still think that tunnel mode is sufficient. Why do You need an SPD entry for negotiating an IPsec SA in both the cases. What do you mean by "new" policies ? > we need IP-in-IP/transport mode? > > > > > and (ii) it is also difficult to detect the mis-configuration > > in pre-configured policies (PaC and EP will see IKE succeeded but > > subsequent data traffic will not pass). > > > > => I don't understand all this stuff about pre-configured policies. > > Do you talk about SPD entries or something else? > > I'm talking about SPD. I used the term "pre-configured" to be > equivalent to "non-negotiable". If the use of IP-in-IP is not > negotiable in IKE, how can any IPsec entity uniquely determine whether > additional IP-in-IP encapsulation is applied to a transport mode SA? > Or are you proposing that IP-in-IP encapsulation must be always > applied to any transport mode SA? > When you negotiate the transport mode SA you send "4" in the protocol field of ID payload in IKE. -mohan > > > > In addition, PaC and EP may > > use not also IP-in-IP/transport mode (for protecting > traffic to/from > > the Internet) but also just transport mode for local > non-ICMP traffic > > between PaC and EP (in this case IP-in-IP is clearly an > overhead). > > > > => the "local" traffic between the PaC and the EP doesn't matter as > > soon as IKE can bypass protection and IP-in-IP packets are not > > recursively encapsulated. The purpose is to protect traffic to/from > > the Internet and this can be easily done by routing every not-local > > thing through the tunnel as it is done in current "mobile" > IPsec VPNs. > > What do you mean by mobile IPsec VPNs? > > > > > How is the pre-configured policy constructed for this > case? I still > > think using tunnel mode is cleanest for protecting > traffic to/from the > > Internet in the access network since there is not a > policy issue of > > this kind. > > > > => There is no such policy issue. > > Please see my comment on SPD above. > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Sat Jun 21 23:30:23 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21744 for ; Sat, 21 Jun 2003 23:30:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5M3S6sf014804; Sat, 21 Jun 2003 23:28:06 -0400 (EDT) Resent-Date: Sat, 21 Jun 2003 23:28:06 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 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: Securing the first hop in PANA using IPsec Date: Sat, 21 Jun 2003 20:27:36 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47D@TNEXVS02.tahoenetworks.com> Thread-Topic: Securing the first hop in PANA using IPsec Thread-Index: AcMkLkE6rkP+mQYfSe28OsRWpK30RAUPDM6g From: "Mohan Parthasarathy" To: "Francis Dupont" , "Yoshihiro Ohba" Cc: "Jean-Michel COMBES" , "Alper Yegin" , "pana" X-OriginalArrivalTime: 22 Jun 2003 03:27:36.0879 (UTC) FILETIME=[3A1923F0:01C3386E] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Francis, Thanks for your reply.=20 > In your previous mail you wrote: >=20 > > =3D> the IPsec policy is very simple: protect packets=20 > going through the > > IP-in-IP tunnel, i.e., source and destination =3D PaC and=20 > EP (link-local) > > addresses, protocol =3D IP-in-IP (4 or 41). > =20 > This is not simpler than using IPsec tunnel mode, since tunnel mode > automatically comes with tunneling without introducing new=20 > policies, > while IP-in-IP/transport mode needs a new policy to use IP-in-IP > encapsulation. I still think that tunnel mode is=20 > sufficient. Why do > we need IP-in-IP/transport mode? > =20 > =3D> we don't need it but there is a trade-off between the tunnel mode > which is simpler (just because it is very common in fact) with single > encapsulation and the transport mode over IP-in-IP which is far > simpler with double encapsulation (no bypass for the remote IKE for > instance). So to solve the trade-off the important thing is to know I will clarify this a bit more. Let me know if it different from what you think. If you use tunnel mode IPsec in the double IPsec case, there should be a rule in EP to bypass IPsec protection for all IKE packets (or bypass IKE packets destined to the remote networks that will be used by PaCs). In transport, IKE packets to remote network are also protected on the local network. No need for any special bypass rules. You may potentially need a bypass rule for port 4500 (NAT traversal) also. How big is the vulnerability in having such rules in EP ? RFC2401 does discuss about iterated tunneling where this double IPsec case falls. Not sure how many implementations support it. If you are using transport mode as described in = draft-mohanp-pana-ipsec-00.txt, it is transparent to implementations that double IPsec happens. The main objective is to protect all of the local traffic. If you are using the tunnel mode, during the IPsec SA negotiation you need to pass all zero address in the IDci payload which is effectively what transport mode achieves. The main difference between tunnel mode and transport mode is in policy checks. The tunnel mode checks policy with the inner header which is not any useful here. This is not a justification for using tunnel mode but to clarify that nothing is lost using transport mode. > if the double encapsulation will be the standard or a rare case. > As an user of "mobile" IPsec VPNs, I believe that as soon as the > burden of using IPsec doesn't matter (which should be the case here), > the double encapsulation should be very frequent. In fact, I believe > also that legacy auth/XAUTH will be a serious competitor here too. >=20 > I'm talking about SPD. I used the term "pre-configured" to be > equivalent to "non-negotiable". >=20 > =3D> in our case the SPD is not supposed (nor required) to be=20 > negotiable: > the IP-in-IP tunnel and the SPD entries are setup by PANA before IKE > is launched/triggered (so you can come back to the pre-requisites > issue (*) :-) Before the PaC and EP can setup IPsec SA, you need to dynamically add the SPD entry. I will clarify this in the next version.=20 -mohan >=20 > If the use of IP-in-IP is not > negotiable in IKE, how can any IPsec entity uniquely=20 > determine whether > additional IP-in-IP encapsulation is applied to a=20 > transport mode SA? >=20 > =3D> I disagree about the order of applications. No additional = IP-in-IP > is applied to a transport mode SA: an additional transport mode SA > is applied to IP-in-IP. >=20 > Or are you proposing that IP-in-IP encapsulation must be always > applied to any transport mode SA? > =20 > =3D> this makes no sense. >=20 > > =3D> the "local" traffic between the PaC and the EP=20 > doesn't matter as > > soon as IKE can bypass protection and IP-in-IP packets are not > > recursively encapsulated. The purpose is to protect=20 > traffic to/from > > the Internet and this can be easily done by routing=20 > every not-local > > thing through the tunnel as it is done in current=20 > "mobile" IPsec VPNs. > =20 > What do you mean by mobile IPsec VPNs? > =20 > =3D> an IPsec VPN where one end is a host with a dynamic=20 > address. This host > is a "road warrior" and in fact is nomadic but as this term=20 > seems to be > pedantic the common term is "mobile". >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > PS (*): in the document pre-requisites are about required parameters, > not about how to use them (learn/know/acquire, no build/setup/...). >=20 >=20 From pana-request@research.telcordia.com Sun Jun 22 02:02:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25167 for ; Sun, 22 Jun 2003 02:01:11 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5M5uxtt018218; Sun, 22 Jun 2003 01:56:59 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 01:56:59 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 21 Jun 2003 22:56:50 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Francis Dupont , Jean-Michel COMBES , Alper Yegin , pana Subject: Re: Securing the first hop in PANA using IPsec Message-ID: <20030622055611.GA14074@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Francis Dupont , Jean-Michel COMBES , Alper Yegin , pana References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47C@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47C@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 50 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Sat, Jun 21, 2003 at 06:49:11PM -0700, Mohan Parthasarathy wrote: > Catching up on this thread (back from my vacation) > > Just on this point... > > > > > > > IMHO, a better approach is to mention the possibility of > > the two modes > > > (i.e., ESP/tunnel mode and ESP/transport mode w/IP-in-IP) for > > > protecting traffic PaC and EP with IPsec, and to describe how the > > > mode(s) supported by the EP should be indicated to the > > PaC by using > > > PANA and/or one mode is chosen during IKE negotiation. > > > > > > => to leave the choice is more complex. Simplicity was a > > design goal. > > > > But is draft-touch-ipsec-vpn-05.txt a standard method? If it is not a > > standard method, how can we maintain interoperability if we mandate > > the method only. > > > There is nothing to do with a standard here. If you have a tunnel and > have IPsec policy based on the outer header's source address e.g. > [IF SRC = OUTER-TUNNEL-SRC-ADDRESS] apply IPsec, then the transport > SA you negotiate will protect all traffic coming out of the tunnel. This > is standard IPsec. Can IP-in-IP/transport mode support more flexibile policies rather than applying the same type of protection to all traffic? For example, if a PaC have a IPsec-based VPN tunnel to a VPN gateway, the VPN traffic is typically encrypted with the IPsec tunnel used for the VPN, and thus does not need to be encrypted with the IPsec SA established between the PaC and EP, while non-VPN traffic might need to be encrypted in the visiting network. If we use IPsec tunnel mode SA(s) in the visiting network, such a policy can be supported by IKEv2 with using an approprite traffic selector for each SA (i.e., one SA for VPN traffic and the other SA for non-VPN traffic). > > I agree that the document does not discuss the issues related to this > well. I will calrify this in my next version. Yes, I have a strong impression that pros and cons of using IP-in-IP/transport mode are not fully analyzed even in draft-touch-ipsec-vpn-05.txt. Regards, Yoshihiro Ohba From pana-request@research.telcordia.com Sun Jun 22 02:20:55 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06067 for ; Sun, 22 Jun 2003 02:20:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5M6IU5v002019; Sun, 22 Jun 2003 02:18:30 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 02:18:30 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 21 Jun 2003 23:18:32 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Francis Dupont , Jean-Michel COMBES , Alper Yegin , pana Subject: Re: Securing the first hop in PANA using IPsec Message-ID: <20030622061831.GB14074@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Francis Dupont , Jean-Michel COMBES , Alper Yegin , pana References: <416B5AF360DED54088DAD3CA8BFBEA6E016C1441@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1441@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 19 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Sat, Jun 21, 2003 at 08:01:00PM -0700, Mohan Parthasarathy wrote: > > I'm talking about SPD. I used the term "pre-configured" to be > > equivalent to "non-negotiable". If the use of IP-in-IP is not > > negotiable in IKE, how can any IPsec entity uniquely determine whether > > additional IP-in-IP encapsulation is applied to a transport mode SA? > > Or are you proposing that IP-in-IP encapsulation must be always > > applied to any transport mode SA? > > > When you negotiate the transport mode SA you send "4" in the protocol > field of ID payload in IKE. I understood on this part. Thanks for the clarification. > > -mohan > > Yoshihiro Ohba From pana-request@research.telcordia.com Sun Jun 22 20:17:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22440 for ; Sun, 22 Jun 2003 20:17:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5N0DpNc002762; Sun, 22 Jun 2003 20:13:51 -0400 (EDT) Resent-Date: Sun, 22 Jun 2003 20:13:51 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Securing the first hop in PANA using IPsec Date: Sun, 22 Jun 2003 17:13:18 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47E@TNEXVS02.tahoenetworks.com> Thread-Topic: Securing the first hop in PANA using IPsec Thread-Index: AcM4gzAe4ukwYNAWS5igN/v7DLfsxAAl3gPQ From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Francis Dupont" , "Jean-Michel COMBES" , "Alper Yegin" , "pana" X-OriginalArrivalTime: 23 Jun 2003 00:13:18.0937 (UTC) FILETIME=[3FD61C90:01C3391C] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > > > > > > > > > > IMHO, a better approach is to mention the possibility of > > > the two modes > > > > (i.e., ESP/tunnel mode and ESP/transport mode w/IP-in-IP) for > > > > protecting traffic PaC and EP with IPsec, and to > describe how the > > > > mode(s) supported by the EP should be indicated to the > > > PaC by using > > > > PANA and/or one mode is chosen during IKE negotiation. > > > > > > > > => to leave the choice is more complex. Simplicity was a > > > design goal. > > > > > > But is draft-touch-ipsec-vpn-05.txt a standard method? > If it is not a > > > standard method, how can we maintain interoperability if > we mandate > > > the method only. > > > > > There is nothing to do with a standard here. If you have a > tunnel and > > have IPsec policy based on the outer header's source address e.g. > > [IF SRC = OUTER-TUNNEL-SRC-ADDRESS] apply IPsec, then the transport > > SA you negotiate will protect all traffic coming out of the > tunnel. This > > is standard IPsec. > > Can IP-in-IP/transport mode support more flexibile policies rather > than applying the same type of protection to all traffic? For No. > example, if a PaC have a IPsec-based VPN tunnel to a VPN gateway, the > VPN traffic is typically encrypted with the IPsec tunnel used for the > VPN, and thus does not need to be encrypted with the IPsec SA > established between the PaC and EP, while non-VPN traffic might need > to be encrypted in the visiting network. If we use IPsec tunnel mode > SA(s) in the visiting network, such a policy can be supported by IKEv2 > with using an approprite traffic selector for each SA (i.e., one SA > for VPN traffic and the other SA for non-VPN traffic). > Agreed this is a valid scenario where double encryption cannot be avoided with the existing approach. -mohan > > > > I agree that the document does not discuss the issues > related to this > > well. I will calrify this in my next version. > > Yes, I have a strong impression that pros and cons of using > IP-in-IP/transport mode are not fully analyzed even in > draft-touch-ipsec-vpn-05.txt. > > Regards, > Yoshihiro Ohba > > From pana-request@research.telcordia.com Mon Jun 23 05:48:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14104 for ; Mon, 23 Jun 2003 05:47:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5N9bwlW008502; Mon, 23 Jun 2003 05:37:58 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 05:37:58 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue3] PANA SA Date: Mon, 23 Jun 2003 12:37:50 +0300 Message-ID: Thread-Topic: [issue3] PANA SA Thread-Index: AcM5adVgHKQYHJh1Q42xErelSFsJnwAATIWg From: To: X-OriginalArrivalTime: 23 Jun 2003 09:37:51.0222 (UTC) FILETIME=[1D4AA160:01C3396B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: I have formulated a text for issue 3. Thanks, Yoshihiro Ohba _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue3 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 05:48:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14103 for ; Mon, 23 Jun 2003 05:47:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5N9gggb014584; Mon, 23 Jun 2003 05:42:42 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 05:42:42 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue11] Event Notification Date: Mon, 23 Jun 2003 12:38:53 +0300 Message-ID: Thread-Topic: [issue11] Event Notification Thread-Index: AcM5avjPZEuki29xQ/WQIcY9RcQFXQAAEHFQ From: To: X-OriginalArrivalTime: 23 Jun 2003 09:38:54.0040 (UTC) FILETIME=[42BBE580:01C3396B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Text proposal from Alper Yegin. -------- Please change this text: Upon detecting the need to authenticate a client, EP can send a PAC_discovery message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-Id AVP. So that, PAA can send the unsolicited PANA_start message directly to the PaC. If the link between the EP and PAA is not secure, the PAC_discover message sent from EP to PAA MUST be protected by using, e.g., IPsec. To: Upon detecting the need to authenticate a client, EP can send a trigger message to the PAA on behalf of the PaC. This can be one of the messages provided by the PAA-to-EP protocol, or, in the absence of such a facility, PAC_discovery can be used as well. This message MUST carry the device identifier of the PaC. So that, PAA can send the unsolicited PANA_start message directly to the PaC. If the link between the EP and PAA is not secure, this message sent from EP to PAA MUST be protected (e.g., by using IPsec). ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue11 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 06:38:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14105 for ; Mon, 23 Jun 2003 05:47:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5N9ccZY012950; Mon, 23 Jun 2003 05:38:38 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 05:38:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue8] Refresh Interval Negotiation Date: Mon, 23 Jun 2003 12:38:35 +0300 Message-ID: Thread-Topic: [issue8] Refresh Interval Negotiation Thread-Index: AcM5aq9wxDctC8PsS8OWK21z5+MtdgAAH5VA From: To: X-OriginalArrivalTime: 23 Jun 2003 09:38:35.0590 (UTC) FILETIME=[37BCA660:01C3396B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Text proposal from Alper Yegin. ---- The authentication phase also determines the PANA session lifetime when authorization succeeds. The Session-Lifetime AVP (Code XXX) is used to determine the valid lifetime of PANA session. This AVP MUST NOT be included in any message other than PANA-Result-Request and PANA-Result-Answer. It MUST be ignored when received in other messages or the authorization result is a failure. This AVP carries the maximum session lifetime offered by the network when included in the PANA-Result-Request sent by the PAA. If it is omitted, or contains the value 0xFFFFFFFF, this means the session lifetime is infinity. This AVP carries the requested session lifetime when it is sent by the PaC. If requested session lifetime is greater than the offered lifetime, then it is ignored and the offered lifetime becomes the session lifetime. The requested lifetime becomes the session lifetime if it is less than or equal to the offered lifetime. PaC MUST perform PANA authentication (by sending PANA-Start-Request, not PANA-Reauth-Request) before the session lifetime expires. Failure to do so yields in PaC losing network access. ---------- status: Pending -> Text Proposed _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue8 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 06:38:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14102 for ; Mon, 23 Jun 2003 05:47:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5N9g4qC010389; Mon, 23 Jun 2003 05:42:04 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 05:42:04 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue7] Mobility Handling Date: Mon, 23 Jun 2003 12:38:14 +0300 Message-ID: Thread-Topic: [issue7] Mobility Handling Thread-Index: AcM5alg6/AqC8k6lRNmerIicAJJr8wAAMqQg From: To: X-OriginalArrivalTime: 23 Jun 2003 09:38:14.0846 (UTC) FILETIME=[2B5F5DE0:01C3396B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Text proposal from Alper Yegin. ------ If PaC wants to resume an ongoing PANA session after connecting to another link in the same access network, it can send the unexpired PANA session id in its PANA_start message. In the absence of session id AVP in this message, PAA can assume this is a fresh session and assigns a new session ID in the first PANA_auth message. If PAA receives a session id in the PANA_start message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA SA from the previous PAA of the PaC. Determining the previous PAA of the PaC by using the PANA session id is outside the scope of this protocol. A possible solution is to embed the PAA id in the session id. Furthermore, the mechanism required to retrieve the PANA SA from the previous PAA is outside the scope of PANA protocol. Seamoby Context Transfer Protocol [CTP] might be useful here. If the PAA is not configured to enable fast re-authentication, or can not retrieve the PANA SA, or the PANA SA has expired, PAA MUST send the PANA_start message with a new session id and let the PANA exchange take its usual course. Otherwise, PAA MUST continue the PANA session with PANA_reauth exchange (rather than PANA_auth exchange which, in most of the times, means full authentication). Device ID AVPs MUST be included in this exchange to bind the new DIs to the PANA SA. References [CTP] J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, "Context Transfer Protocol", draft-ietf-seamoby-ctp-02.txt, June 2003. Work in progress. ---------- status: Pending -> Text Proposed _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue7 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 06:48:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15619 for ; Mon, 23 Jun 2003 06:48:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NAia4r020608; Mon, 23 Jun 2003 06:44:36 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 06:44:36 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: NEW [issue16] Multihoming support Date: Mon, 23 Jun 2003 13:40:48 +0300 Message-ID: Thread-Topic: [issue16] Multihoming support Thread-Index: AcM5c7kAziVar1G5QRqnmvyyWGGtuAAABW4Q From: To: X-OriginalArrivalTime: 23 Jun 2003 10:40:49.0306 (UTC) FILETIME=[E9347FA0:01C33973] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <3CmYCD.A.TBF.Uot9-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : Devices that have multiple interfaces can have multiple network connections (with different IP addresses) on at the same time. On the IP level the access network may still be the same.. ----------- Dan said: >>> What if the MN has multiple interfaces (WLAN, Bluetooth, >>> Ethernet, 3G, etc.) >>> that all get a separate IP address from the same NAP >>> through the same PAA? >>> It's better to have one PANA session but add/delete >>> addresses/interfaces. Alper said:=20 >> The simple answer is: all physical interfaces should do >> PANA independently. Is there a problem with that? Dan said:=20 > This is not a good approach. Just think about the re-auth > message flood, multiple session state information and even > possibly multiple AAA backend sessions on the core=20 > network. Not scalable. Consumes resources on the client > and on the network unnecessarily. >=20 > Another point is that adding new interface to the existing > session is faster than doing the whole AA process from=20 > scratch. Alper said: You are talking about room for possible optimizations, not problems. I suggest we open this as a new issue, and follow it up from there. Rather than continuously optimizing the basic design. I think such optimizations touch more than the PANA design, so we should do a more thorough analysis. ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 39 nosy: dforsber priority: Should Fix status: No Discussion title: Multihoming support ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue16 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 07:03:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16029 for ; Mon, 23 Jun 2003 07:03:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NB0dUH010073; Mon, 23 Jun 2003 07:00:39 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 07:00:39 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Issue 3: PANA SA Date: Mon, 23 Jun 2003 14:00:30 +0300 Message-ID: Thread-Topic: Issue 3: PANA SA Thread-Index: AcM19h/Rsm5Q5VWRQx2I4FrLkppBvwDgEZsQ From: To: , X-OriginalArrivalTime: 23 Jun 2003 11:00:31.0182 (UTC) FILETIME=[A9A876E0:01C33976] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <802HiB.A.xcC.W3t9-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I also updated key derivation expression based on the fact that the > default MAC algorithm is HMAC-SHA1 which needs 160-bit key length. > (Issue: do we need to support multiple MAC algorithms?) The message format proposal has two types: HMAC-MD5 and HMAC-SHA1. I guess these things should have their own types so that new algorithms can be used in the future more easily. - Dan > > Yoshihiro Ohba From pana-request@research.telcordia.com Mon Jun 23 07:53:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17168 for ; Mon, 23 Jun 2003 07:52:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NBmvg2021313; Mon, 23 Jun 2003 07:48:57 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 07:48:57 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Security threat (was: RE: [issue9] Message format) Date: Mon, 23 Jun 2003 14:44:28 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcMwTAX8S1izR4VTRSiX2MqWXyT5jAJLAtTQ From: To: , X-OriginalArrivalTime: 23 Jun 2003 11:44:28.0472 (UTC) FILETIME=[CD9AFB80:01C3397C] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, I had one week vacation and thus the answers are a bit=20 late. Here are my comments. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 11 June, 2003 22:04 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue9] Message format >=20 >=20 > >>> What if the MN wants to access the local network with link > >> local or site local > >>> addresses at the same time with a global CoA address? > >>=20 > >> We have discussed this. Depending on the DI: > >>=20 > >> - if MAC address: then there is no issue. PaC can configure any > >> IP address on the specified MAC address. Access control is based on > >> the MAC address. > >=20 > > Where is this kind of scenario feasible? >=20 > In scenarios described in sections 4.1 and 4.2 of the usage=20 > scenarios draft, > plus 4.3 where link-layer ciphers are enabled at the end of PANA. > Effectively, almost anywhere IPsec is not used for access control. What if the authenticated PaC itself becomes malicious? It can blindly=20 spoof other PaCs addresses. This is a security threat, even if the MAC=20 address is bound to accounting. >=20 > >=20 > > That would mean that PaC can freely spoof IP addresses. >=20 > Exactly. But, this is a SEND problem, not PANA problem. This problem goes beyond SEND and even IPSec. SEND is for discovery=20 only, not for protecting data packets like IPSec. On the other=20 hand IPSec is used for protecting malicious users from stealing=20 other's connections on the access link, right? Or should we say=20 that IPSec is used for making sure that only "paying" customers=20 can send packets. The access network doesn't want the PaCs to be able to spoof=20 network nodes that are inside the access network (behind the=20 first AR). What the EP wants to do is to make sure that the=20 packet coming from PaCs has an IP address that belongs to the=20 correct subnet prefix (access link prefix). By default the=20 policy in the EP (in most cases) is to deny all IP addresses=20 if not authenticated AND authorized properly. The problem is authorization of data packets that pass through=20 the EP. IPSec takes care of authentication (SEND doesn't do=20 neither). With IPSec tunnel between PaC and PAA, the inner IP address=20 MUST be checked too! Otherwise authenticated and authorized=20 PaCs can spoof IP addresses. >=20 > > I don't think it's a > > good idea. Filtering should be based on IP addresses as=20 > well. PANA is IP level > > protocol.. > >=20 > >> - if IP address: This is the case where IPsec is used. For=20 > this, PaC > >> determines one of the IP addresses as DI, most probably a=20 > link-local > >> address. The traffic is tunneled using this DI as the local > >> end point. See > >> PANA-Ipsec draft. Now, if the PaC wants to use other IP > >> addresses, they > >> will be used only within the tunnel, hence the access=20 > control does not > >> care about them. > >=20 > > If DI is IP address, IPSec is not always used (physically=20 > secure links for > > example or links that provide L2 protection). Right? >=20 > If we are not using IPsec,it does not make sense to use IP=20 > address as the > DI, unless we are trying to solve SEND problems here. We should use > lower-layer identifiers. See my comment above. >=20 > >=20 > >>=20 > >>>=20 > >>> What if the MN has multiple interfaces (WLAN, Bluetooth, > >> Ethernet, 3G, etc.) > >>> that all get a separate IP address from the same NAP > >> through the same PAA? > >>> It's better to have one PANA session but add/delete > >> addresses/interfaces. > >>=20 > >> The simple answer is: all physical interfaces should do PANA > >> independently. > >> Is there a problem with that? > >=20 > > This is not a good approach. Just think about the re-auth=20 > message flood, > > multiple session state information and even possibly=20 > multiple AAA backend > > sessions on the core network. Not scalable. Consumes=20 > resources on the client > > and on the network unnecessarily. > >=20 > > Another point is that adding new interface to the existing=20 > session is faster > > than doing the whole AA process from scratch. >=20 > You are talking about room for possible optimizations, not problems. > I suggest we open this as a new issue, and follow it up from=20 > there. Rather > than continuously optimizing the basic design. I think such=20 > optimizations > touch more than the PANA design, so we should do a more=20 > thorough analysis. Ok. I've created a new issue 16. - Dan >=20 >=20 > Alper >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 08:27:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17950 for ; Mon, 23 Jun 2003 08:27:34 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NCPOBW017238; Mon, 23 Jun 2003 08:25:24 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 08:25:24 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: Issue 8 Date: Mon, 23 Jun 2003 15:25:20 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcMwSeTsOi9jvHpvTU28f/vCDXEPCgDjzvLA From: To: , X-OriginalArrivalTime: 23 Jun 2003 12:25:21.0127 (UTC) FILETIME=[83806F70:01C33982] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi Alper, Here are some comments. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 11 June, 2003 21:48 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: Issue 8 >=20 >=20 > Dan, >=20 > > - We need a grace period too: > > Authorization-Lifetime + Auth-Grace-Period <=3D Session-Timeout > > Here > > Auth-Grace-Period < Authorization-Lifetime > > Unit is seconds. Auth-Grace-Period is a configurable parameter > > and delivered from PAA to PaC. >=20 > I agree there might be a grace period, but I think this can be a local > decision (via implementation, configuration). Does the=20 > protocol have to > carry this information to the other end (PaC)? Grace period depends on the authorization and session lifetime.=20 Network decides both of these (at least the limits), so PaC=20 must be informed. I guess we could have many authorization (refresh) periods in one=20 session lifetime. If PaC fails to reauthenticate (PANA refresh) in=20 the given authorization (refresh) period, the session is also torn down. > > - PaC should propose something and PAA then decides the actual > > refresh period and session lifetime (the network knows better > > the upper and lower limits for re-auth etc.). >=20 > Now that I'm thinking, maybe we should only pass the Session-lifetime > between PAA and PaC, and not worry about Reauth-lifetime. PaC=20 > and PAA don't > need to share the Reauth-lifetime, each can trigger reauth as=20 > often as they > like/need. But for Session-lifetime, PaC should know it so that it can > perform PANA authentication again before its session expires and PAA > disables network access. Is it PaC's or PAA's responsibility to do reauth? Protocol should be=20 clear about this. Otherwise both PaC and PAA might try to do it at the same time. Not clear enough for a protocol spec. One way to go is to let PaC initiate the re-authentication after the=20 authorization lifetime has been exceeded and grace period starts. Grace period is needed for the processing the refresh/reauth (only the network knows how much time a refresh can take). >=20 >=20 > > PaC can optionally > > propose a Authorization-Lifetime to PAA within a PANA-Auth-Request > > message.=20 >=20 > I also thought about first PaC requesting a value and PAA=20 > granting one. But > then looking at the message flows, the other direction seems=20 > to better fit > the current design. Instead of one of the PANA-auth messages=20 > carrying this > info from PaC to PAA, and the response coming back in=20 > PANA-success, I think > doing it symmetrically in PANA-success/ack is better. PANA=20 > module on the PaC > won't really know in which PANA-auth message this AVP should=20 > be included. Yes, this is a problem. If PaC makes the final decision, then=20 the network should inform both the lower and upper limits. We may need more AVPs? >=20 > > PAA sends Authorization-Lifetime and Auth-Grace-Period > > AVPs to PaC in PANA-Result-Request message. PAA can also send > > Session-Timeout AVP to denote the total lifetime of the session. >=20 > I don't think we need to pass the grace-period to the PaC.=20 > (well, if we do, > it is no longer seen as grace period, but as part of granted period :) Grace period doesn't add to the session lifetime, but to the=20 authorization lifetime. authorization_lifetime + grace_period <=3D session_lifetime >=20 >=20 > How about this: >=20 > - PAA sends (offered) session-lifetime in PANA-success=20 > message to the PaC. > If PaC wants to lower the session-lifetime, it MAY include a lower > session-lifetime in PANA-success-ack. We need the lower limit too. I guess this could be stated in the spec, but the scenarios are different and the network may want to use = different=20 limits, even dynamically (depending on the signaling load etc.). >=20 > - It's the responsibility of PaC to perform PANA before its=20 > current session > expires. [note: here we are talking about full authentication=20 > where an EAP > method is executed, not re-auth] Yep. We have two authentications: local refresh, and EAP re-auth. >=20 > - Both PaC and PAA can initiate re-auth whenever they need to. This must be clarified in the spec. The proposal for issue8 doesn't=20 take care of this yet. - Dan >=20 > Does this make sense? >=20 > >=20 > > - PANA-Reauth-Request from PAA can optionally contain > > Authorization-Lifetime AVP to denote the re-auth interval > > (if network wants to change it)? > >=20 > >=20 >=20 >=20 > Alper >=20 > > Br, > > - Dan > >=20 > >=20 > >> -----Original Message----- > >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >> Sent: 11 June, 2003 00:10 > >> To: pana@research.telcordia.com > >> Subject: Issue 8 > >>=20 > >>=20 > >>=20 > >> http://danforsberg.info:8080/pana-issues/issue8 > >>=20 > >>=20 > >> How about if we: > >>=20 > >> - define a refresh (re-auth) lifetime AVP. > >> - PAA MUST include this AVP in the PANA_success to provide=20 > the maximum > >> allowed refresh lifetime for the PANA session. > >> - PAA MAY include this AVP in the PANA_success_ack to lower > >> the required > >> PANA refresh lifetime. > >>=20 > >> At the end of PANA_success round, both PAA and PaC knows=20 > the refresh > >> frequency.=20 > >>=20 > >> PaC MAY send PANA_reauth before this period expires. PAA MUST send > >> PANA-reauth if there was no PANA-reauth exchange for one=20 > full period. > >>=20 > >> Comments? > >>=20 > >> Alper > >>=20 > >>=20 > >=20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 08:55:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18743 for ; Mon, 23 Jun 2003 08:55:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NCr1gH023290; Mon, 23 Jun 2003 08:53:01 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 08:53:01 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [issue14] PANA session term Date: Mon, 23 Jun 2003 15:52:58 +0300 Message-ID: Thread-Topic: [issue14] PANA session term Thread-Index: AcM5hje9suiETwPdStWQul1EJCHO0gAABsDg From: To: X-OriginalArrivalTime: 23 Jun 2003 12:52:58.0923 (UTC) FILETIME=[5FA007B0:01C33986] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: "PANA Session" term exists already. ---------- status: Text Proposed -> Rejected ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue14 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 09:17:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19430 for ; Mon, 23 Jun 2003 09:17:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NDF6k8009641; Mon, 23 Jun 2003 09:15:06 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 09:15:06 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue6] Session Identifier or SPIs Date: Mon, 23 Jun 2003 16:11:18 +0300 Message-ID: Thread-Topic: [issue6] Session Identifier or SPIs Thread-Index: AcM5iHS5F/nOQbUKQ/qUd6iPmvAutwAAGqUQ From: To: X-OriginalArrivalTime: 23 Jun 2003 13:11:18.0586 (UTC) FILETIME=[EF1349A0:01C33988] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Session Identifier: Session-Id AVP (see section 9.x.y) is used to identify the PANA Session. This id is used for disconnect or session revocation indication or for charging purposes. ---------- status: Clarifying Text Required -> Text Proposed _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue6 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 09:59:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20553 for ; Mon, 23 Jun 2003 09:58:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NDsSvF028981; Mon, 23 Jun 2003 09:54:28 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 09:54:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: NEW [issue17] Error handling Date: Mon, 23 Jun 2003 16:50:35 +0300 Message-ID: Thread-Topic: [issue17] Error handling Thread-Index: AcM5jfTgTkrNBCabTHeC5zUkWxYjsQAAGPLw From: To: X-OriginalArrivalTime: 23 Jun 2003 13:50:36.0094 (UTC) FILETIME=[6C4275E0:01C3398E] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : How can PaC or PAA inform each other about errors? ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 42 nosy: dforsber priority: Must Fix status: No Discussion title: Error handling ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue17 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 10:22:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22350 for ; Mon, 23 Jun 2003 10:22:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NEKU8o019257; Mon, 23 Jun 2003 10:20:30 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 10:20:30 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 07:20:25 -0700 To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@research.telcordia.com Subject: Re: Issue 3: PANA SA Message-ID: <20030623141951.GA26027@steelhead> Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 17 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jun 23, 2003 at 02:00:30PM +0300, Dan.Forsberg@nokia.com wrote: > > I also updated key derivation expression based on the fact that the > > default MAC algorithm is HMAC-SHA1 which needs 160-bit key length. > > (Issue: do we need to support multiple MAC algorithms?) > > The message format proposal has two types: HMAC-MD5 and HMAC-SHA1. I guess these things should have their own types so that new algorithms can be used in the future more easily. When HMAC-MD5 is used, just using the first 128-bit of the 160-bit derived key as the HMAC-MD key should work. Another issue is how one of these algorithms is selected, pre-configuration or negotiation? If the latter is the case, we need to specify how the negotiation is performed in PANA. Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Mon Jun 23 10:40:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23056 for ; Mon, 23 Jun 2003 10:40:00 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NEbIEo014890; Mon, 23 Jun 2003 10:37:18 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 10:37:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: NEW [issue18] Termination-Cause AVP values? Date: Mon, 23 Jun 2003 17:37:16 +0300 Message-ID: Thread-Topic: [issue18] Termination-Cause AVP values? Thread-Index: AcM5kvA5qKKPE2BtROWt9jxJfQqa2AAAfahQ From: To: X-OriginalArrivalTime: 23 Jun 2003 14:37:16.0743 (UTC) FILETIME=[F1939570:01C33994] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : These are from Diameter spec (17): LOGOUT 1 (PaC -> PAA) The user initiated a disconnect (SERVICE_NOT_PROVIDED 2 (PAA -> PaC)) This value is used when the user disconnected=20 prior to the receipt of the authorization answer message. BAD_ANSWER 3 (PaC -> PAA) This value indicates that the authorization answer received by the access device was not processed successfully. ADMINISTRATIVE 4 (PAA -> Pac) The user was not granted access, or was=20 disconnected, due to administrative reasons,=20 such as the receipt of a Abort-Session-Request message. (LINK_BROKEN 5) The communication to the user was abruptly=20 disconnected. AUTH_EXPIRED 6 (PAA -> PaC) The user's access was terminated since its=20 authorized session time has expired. (USER_MOVED 7) (PaC -> PAA) The user is receiving services from another=20 access device. (See issue16). SESSION_TIMEOUT 8 (PAA -> PaC) The user's session has timed out, and service=20 has been terminated. ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 44 nosy: dforsber priority: Must Fix status: Text Proposed title: Termination-Cause AVP values? ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue18 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 10:40:40 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23093 for ; Mon, 23 Jun 2003 10:40:40 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NEcPIC023163; Mon, 23 Jun 2003 10:38:25 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 10:38:25 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: NEW [issue19] Result-Code AVP values? Date: Mon, 23 Jun 2003 17:38:23 +0300 Message-ID: Thread-Topic: [issue19] Result-Code AVP values? Thread-Index: AcM5lN8URTOnm5nYSVmff4Owr6eXqQAACQnw From: To: X-OriginalArrivalTime: 23 Jun 2003 14:38:23.0376 (UTC) FILETIME=[194AF900:01C33995] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <-VZEvD.A.spF.hDx9-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : Result-Code AVP is used in the PANA-Result-Request message. What Result-Code values PANA MUST support? Here are some values from Diameter spec (draft17): SUCCESS 2001 COMMAND_UNSUPPORTED 3001 UNABLE_TO_DELIVER 3002 REALM_NOT_SERVED 3003 TOO_BUSY 3004 INVALID_HDR_BITS 3008 INVALID_AVP_BITS 3009 AUTHENTICATION_REJECTED 4001 AVP_UNSUPPORTED 5001 UNKNOWN_SESSION_ID 5002 AUTHORIZATION_REJECTED 5003 INVALID_AVP_VALUE 5004 MISSING_AVP 5005 RESOURCES_EXCEEDED 5006 AVP_OCCURS_TOO_MANY_TIMES 5009 UNSUPPORTED_VERSION 5011 INVALID_AVP_LENGTH 5014 INVALID_MESSAGE_LENGTH 5015 ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 45 nosy: dforsber priority: Must Fix status: No Discussion title: Result-Code AVP values? ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue19 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 10:43:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23151 for ; Mon, 23 Jun 2003 10:43:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NEfPx0017801; Mon, 23 Jun 2003 10:41:25 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 10:41:25 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [issue10] Message naming, directions, and combination Date: Mon, 23 Jun 2003 17:37:37 +0300 Message-ID: Thread-Topic: [issue10] Message naming, directions, and combination Thread-Index: AcM5kM5S49PSCon2T92kY18BVC++YwABCeMg From: To: X-OriginalArrivalTime: 23 Jun 2003 14:37:38.0096 (UTC) FILETIME=[FE4DCB00:01C33994] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Closed this issue. Will create separate issues for Termination-Cause AVP and Result-Code AVP values. ---------- status: No Discussion -> Closed ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue10 ________________________________________________ From pana-request@research.telcordia.com Mon Jun 23 10:53:33 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23478 for ; Mon, 23 Jun 2003 10:53:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NEonM0004650; Mon, 23 Jun 2003 10:50:49 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 10:50:49 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: NEW [issue17] Error handling Date: Mon, 23 Jun 2003 17:50:46 +0300 Message-ID: Thread-Topic: [issue17] Error handling Thread-Index: AcM5jfTgTkrNBCabTHeC5zUkWxYjsQAAGPLwAAHRKIA= From: To: X-OriginalArrivalTime: 23 Jun 2003 14:50:46.0656 (UTC) FILETIME=[D4528000:01C33996] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable We could have (A) a separate PANA-Error message or (B) include E bit in = the PANA hdr with existing messages? If E bit is on, Result-Code AVP = includes error code. PAA SHOULD send error messages after PANA-Start-Request/Reponse message = exchange to prevent too easy DoS? Here are example error cases from Diameter spec (draft17) for the = Result-Code AVP: COMMAND_UNSUPPORTED 3001 UNABLE_TO_DELIVER 3002 REALM_NOT_SERVED 3003 TOO_BUSY 3004 INVALID_HDR_BITS 3008 INVALID_AVP_BITS 3009 AVP_UNSUPPORTED 5001 UNKNOWN_SESSION_ID 5002 INVALID_AVP_VALUE 5004 MISSING_AVP 5005 RESOURCES_EXCEEDED 5006 AVP_OCCURS_TOO_MANY_TIMES 5009 UNSUPPORTED_VERSION 5011 INVALID_AVP_LENGTH 5014 INVALID_MESSAGE_LENGTH 5015 - Dan > -----Original Message----- > From: ext [mailto:Dan.Forsberg@nokia.com] > Sent: 23 June, 2003 16:51 > To: pana@research.telcordia.com > Subject: NEW [issue17] Error handling >=20 >=20 > New submission from Dan Forsberg : >=20 > How can PaC or PAA inform each other about errors? >=20 >=20 > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 42 > nosy: dforsber > priority: Must Fix > status: No Discussion > title: Error handling > ________________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue17 > ________________________________________________ >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 11:22:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24247 for ; Mon, 23 Jun 2003 11:22:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NFJsuO018736; Mon, 23 Jun 2003 11:19:54 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 11:19:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Issue 3: PANA SA Date: Mon, 23 Jun 2003 18:19:47 +0300 Message-ID: Thread-Topic: Issue 3: PANA SA Thread-Index: AcM5kpt+iShBp1UrRUeT1YC073Mc2QABz+lA From: To: Cc: X-OriginalArrivalTime: 23 Jun 2003 15:19:47.0647 (UTC) FILETIME=[E208A4F0:01C3399A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Are there new protocols that nail down security algorithms? I guess it is not a good approach. Negotiation can be seen as a security threat too (downgrading attack), but it's important for backwards compatibility (in the future). - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 23 June, 2003 17:20 > To: Forsberg Dan (NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com > Subject: Re: Issue 3: PANA SA > > > On Mon, Jun 23, 2003 at 02:00:30PM +0300, > Dan.Forsberg@nokia.com wrote: > > > I also updated key derivation expression based on the > fact that the > > > default MAC algorithm is HMAC-SHA1 which needs 160-bit key length. > > > (Issue: do we need to support multiple MAC algorithms?) > > > > The message format proposal has two types: HMAC-MD5 and > HMAC-SHA1. I guess these things should have their own types > so that new algorithms can be used in the future more easily. > > When HMAC-MD5 is used, just using the first 128-bit of the 160-bit > derived key as the HMAC-MD key should work. > > Another issue is how one of these algorithms is selected, > pre-configuration or negotiation? If the latter is the case, we need > to specify how the negotiation is performed in PANA. > > Thanks, > Yoshihiro Ohba > > From pana-request@research.telcordia.com Mon Jun 23 11:28:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24777 for ; Mon, 23 Jun 2003 11:28:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NFQNbJ015194; Mon, 23 Jun 2003 11:26:23 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 11:26:23 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [issue9] Message format Date: Mon, 23 Jun 2003 18:26:19 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcM5m6KUaeqhKVW+TvyRQ4db3ddTeQAABr6A From: To: X-OriginalArrivalTime: 23 Jun 2003 15:26:20.0343 (UTC) FILETIME=[CC194C70:01C3399B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: New version (e)=AD. Changes: - PANA-Auth-Answer abbr to PAN (was PAA). - PANA-Result-Request MUST always have an EAP payload AVP. - Removed Result-Code AVP from PANA-Auth-Answer. - Removed EAP-Payload from PANA-Reauth-* - Removed Add/Remove-Device-Id for now (see issue16). - Added more text for the session id AVP. - Result-Code AVP values . - Termination-Cause AVP values . - PANA-Result-Request --> PANA-Bind-Request PANA-Result-Answer --> PANA-Bind-Answer - Editorial fixes. _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue9 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 11:32:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24978 for ; Mon, 23 Jun 2003 11:32:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NFTP5k010506; Mon, 23 Jun 2003 11:29:25 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 11:29:25 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: [issue9] Message format Date: Mon, 23 Jun 2003 18:29:22 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcM5m6KUaeqhKVW+TvyRQ4db3ddTeQAABr6AAAAP+BA= From: To: X-OriginalArrivalTime: 23 Jun 2003 15:29:22.0896 (UTC) FILETIME=[38E8AD00:01C3399C] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable We have removed the EAP-Payload AVP from the PANA-Reauth-* messages.=20 Should we keep it for the case of EAP notification in=20 PANA-Reauth-Request? - Dan > -----Original Message----- > From: ext [mailto:Dan.Forsberg@nokia.com] > Sent: 23 June, 2003 18:26 > To: pana@research.telcordia.com > Subject: [issue9] Message format >=20 >=20 > Dan Forsberg added the comment: >=20 > New version (e)=AD. > Changes: > - PANA-Auth-Answer abbr to PAN (was PAA). > - PANA-Result-Request MUST always have an EAP payload AVP. > - Removed Result-Code AVP from PANA-Auth-Answer. > - Removed EAP-Payload from PANA-Reauth-* > - Removed Add/Remove-Device-Id for now (see issue16). > - Added more text for the session id AVP. > - Result-Code AVP values . > - Termination-Cause AVP values . > - PANA-Result-Request --> PANA-Bind-Request > PANA-Result-Answer --> PANA-Bind-Answer > - Editorial fixes. >=20 > _______________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue9 > _______________________________________________ >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 11:50:33 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25809 for ; Mon, 23 Jun 2003 11:50:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NFlnAg023345; Mon, 23 Jun 2003 11:47:49 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 11:47:49 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: [issue3] PANA SA Date: Mon, 23 Jun 2003 18:47:46 +0300 Message-ID: Thread-Topic: [issue3] PANA SA Thread-Index: AcM5adVgHKQYHJh1Q42xErelSFsJnwAATIWgAAy5mPA= From: To: X-OriginalArrivalTime: 23 Jun 2003 15:47:47.0293 (UTC) FILETIME=[CB2E48D0:01C3399E] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi, I strongly suggest using compound key derivation from both MSKs=20 if two EAP rounds are used. This way both authentications are bound to the PANA Session. BR, - Dan > -----Original Message----- > From: ext [mailto:Dan.Forsberg@nokia.com] > Sent: 23 June, 2003 12:38 > To: pana@research.telcordia.com > Subject: FW: [issue3] PANA SA >=20 >=20 > Dan Forsberg added the comment: >=20 > I have formulated a text for issue 3. >=20 > Thanks, > Yoshihiro Ohba >=20 > _______________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue3 > _______________________________________________ >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 11:56:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26087 for ; Mon, 23 Jun 2003 11:56:06 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NFrpgj015384; Mon, 23 Jun 2003 11:53:51 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 11:53:51 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 08:53:48 -0700 To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Subject: Re: NEW [issue17] Error handling Message-ID: <20030623155348.GG26027@steelhead> Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 65 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jun 23, 2003 at 05:50:46PM +0300, Dan.Forsberg@nokia.com wrote: > We could have (A) a separate PANA-Error message or (B) include E bit in the PANA hdr with existing messages? If E bit is on, Result-Code AVP includes error code. The error messages should be separated from regular messages, and should be an optional feature when the errors occur before PANA messages are protected with using MAC AVPs, as there is a trade-off between helping diagnosis and helping DoS attackers, by sending such messages. If an error message is sent unprocted with a MAC AVP or with containing an invalid MAC AVP value, the receiver of the message MUST NOT change its state or send a message in response to it. Yoshihiro Ohba > > PAA SHOULD send error messages after PANA-Start-Request/Reponse message exchange to prevent too easy DoS? > > Here are example error cases from Diameter spec (draft17) for the Result-Code AVP: > > COMMAND_UNSUPPORTED 3001 > UNABLE_TO_DELIVER 3002 > REALM_NOT_SERVED 3003 > TOO_BUSY 3004 > INVALID_HDR_BITS 3008 > INVALID_AVP_BITS 3009 > AVP_UNSUPPORTED 5001 > UNKNOWN_SESSION_ID 5002 > INVALID_AVP_VALUE 5004 > MISSING_AVP 5005 > RESOURCES_EXCEEDED 5006 > AVP_OCCURS_TOO_MANY_TIMES 5009 > UNSUPPORTED_VERSION 5011 > INVALID_AVP_LENGTH 5014 > INVALID_MESSAGE_LENGTH 5015 > > - Dan > > > -----Original Message----- > > From: ext [mailto:Dan.Forsberg@nokia.com] > > Sent: 23 June, 2003 16:51 > > To: pana@research.telcordia.com > > Subject: NEW [issue17] Error handling > > > > > > New submission from Dan Forsberg : > > > > How can PaC or PAA inform each other about errors? > > > > > > ---------- > > category: Technical > > document: draft-ietf-pana-pana-xx.txt > > messages: 42 > > nosy: dforsber > > priority: Must Fix > > status: No Discussion > > title: Error handling > > ________________________________________________ > > PANA Issues > > http://danforsberg.info:8080/pana-issues/issue17 > > ________________________________________________ > > > > > > From pana-request@research.telcordia.com Mon Jun 23 12:22:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27339 for ; Mon, 23 Jun 2003 12:22:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NG4kDS019712; Mon, 23 Jun 2003 12:04:46 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 12:04:46 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [issue8] Refresh Interval Negotiation Date: Mon, 23 Jun 2003 19:00:58 +0300 Message-ID: Thread-Topic: [issue8] Refresh Interval Negotiation Thread-Index: AcM5oIdUKyoMAEIlTaaDnBCohhHURwAAA+mg From: To: X-OriginalArrivalTime: 23 Jun 2003 16:00:59.0076 (UTC) FILETIME=[A31EC840:01C339A0] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Changed status. Negotiation of the refresh interval needed. ---------- status: Text Proposed -> Clarifying Text Required _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue8 _______________________________________________ From pana-request@research.telcordia.com Mon Jun 23 12:39:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28033 for ; Mon, 23 Jun 2003 12:39:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NGM6gS023589; Mon, 23 Jun 2003 12:22:06 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 12:22:06 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 09:22:02 -0700 To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Subject: Re: [issue3] PANA SA Message-ID: <20030623162202.GI26027@steelhead> Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 40 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <3cdlr.A.NwF.tky9-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Dan, Could you elaborate on what is the security threat if compound key derivation from both MSKs is not used? Yoshihiro Ohba On Mon, Jun 23, 2003 at 06:47:46PM +0300, Dan.Forsberg@nokia.com wrote: > Hi, > > I strongly suggest using compound key derivation from both MSKs > if two EAP rounds are used. This way both authentications are bound > to the PANA Session. > > BR, > - Dan > > > -----Original Message----- > > From: ext [mailto:Dan.Forsberg@nokia.com] > > Sent: 23 June, 2003 12:38 > > To: pana@research.telcordia.com > > Subject: FW: [issue3] PANA SA > > > > > > Dan Forsberg added the comment: > > > > I have formulated a text for issue 3. > > > > Thanks, > > Yoshihiro Ohba > > > > _______________________________________________ > > PANA Issues > > http://danforsberg.info:8080/pana-issues/issue3 > > _______________________________________________ > > > > > > From pana-request@research.telcordia.com Mon Jun 23 13:12:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29359 for ; Mon, 23 Jun 2003 13:12:54 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NHAjng023803; Mon, 23 Jun 2003 13:10:45 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 13:10:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 10:10:43 -0700 To: Dan.Forsberg@nokia.com Cc: alper@docomolabs-usa.com, pana@research.telcordia.com Subject: Re: Security threat (was: RE: [issue9] Message format) Message-ID: <20030623171043.GL26027@steelhead> Mail-Followup-To: Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 158 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Dan, A couple of comments below... On Mon, Jun 23, 2003 at 02:44:28PM +0300, Dan.Forsberg@nokia.com wrote: > Alper, > > I had one week vacation and thus the answers are a bit > late. Here are my comments. > > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 11 June, 2003 22:04 > > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > > Subject: Re: [issue9] Message format > > > > > > >>> What if the MN wants to access the local network with link > > >> local or site local > > >>> addresses at the same time with a global CoA address? > > >> > > >> We have discussed this. Depending on the DI: > > >> > > >> - if MAC address: then there is no issue. PaC can configure any > > >> IP address on the specified MAC address. Access control is based on > > >> the MAC address. > > > > > > Where is this kind of scenario feasible? > > > > In scenarios described in sections 4.1 and 4.2 of the usage > > scenarios draft, > > plus 4.3 where link-layer ciphers are enabled at the end of PANA. > > Effectively, almost anywhere IPsec is not used for access control. > > What if the authenticated PaC itself becomes malicious? It can blindly > spoof other PaCs addresses. This is a security threat, even if the MAC > address is bound to accounting. I agree with Dan on this. > > > > > > > > > That would mean that PaC can freely spoof IP addresses. > > > > Exactly. But, this is a SEND problem, not PANA problem. > > This problem goes beyond SEND and even IPSec. SEND is for discovery > only, not for protecting data packets like IPSec. On the other > hand IPSec is used for protecting malicious users from stealing > other's connections on the access link, right? Or should we say > that IPSec is used for making sure that only "paying" customers > can send packets. Yes, SEND and IPsec solves different problems. One does not cover the other. > > The access network doesn't want the PaCs to be able to spoof > network nodes that are inside the access network (behind the > first AR). What the EP wants to do is to make sure that the > packet coming from PaCs has an IP address that belongs to the > correct subnet prefix (access link prefix). By default the > policy in the EP (in most cases) is to deny all IP addresses > if not authenticated AND authorized properly. > > The problem is authorization of data packets that pass through > the EP. IPSec takes care of authentication (SEND doesn't do > neither). > > With IPSec tunnel between PaC and PAA, the inner IP address > MUST be checked too! Otherwise authenticated and authorized > PaCs can spoof IP addresses. The inner address checking is a task of IPsec. In addition, since inner addresses can be carried in ID payload in IKE and Traffic Selector payload in IKEv2. PANA Device-Id AVPs do not need to carry inner addresses. Yoshihiro Ohba > > > > > > I don't think it's a > > > good idea. Filtering should be based on IP addresses as > > well. PANA is IP level > > > protocol.. > > > > > >> - if IP address: This is the case where IPsec is used. For > > this, PaC > > >> determines one of the IP addresses as DI, most probably a > > link-local > > >> address. The traffic is tunneled using this DI as the local > > >> end point. See > > >> PANA-Ipsec draft. Now, if the PaC wants to use other IP > > >> addresses, they > > >> will be used only within the tunnel, hence the access > > control does not > > >> care about them. > > > > > > If DI is IP address, IPSec is not always used (physically > > secure links for > > > example or links that provide L2 protection). Right? > > > > If we are not using IPsec,it does not make sense to use IP > > address as the > > DI, unless we are trying to solve SEND problems here. We should use > > lower-layer identifiers. > > See my comment above. > > > > > > > > >> > > >>> > > >>> What if the MN has multiple interfaces (WLAN, Bluetooth, > > >> Ethernet, 3G, etc.) > > >>> that all get a separate IP address from the same NAP > > >> through the same PAA? > > >>> It's better to have one PANA session but add/delete > > >> addresses/interfaces. > > >> > > >> The simple answer is: all physical interfaces should do PANA > > >> independently. > > >> Is there a problem with that? > > > > > > This is not a good approach. Just think about the re-auth > > message flood, > > > multiple session state information and even possibly > > multiple AAA backend > > > sessions on the core network. Not scalable. Consumes > > resources on the client > > > and on the network unnecessarily. > > > > > > Another point is that adding new interface to the existing > > session is faster > > > than doing the whole AA process from scratch. > > > > You are talking about room for possible optimizations, not problems. > > I suggest we open this as a new issue, and follow it up from > > there. Rather > > than continuously optimizing the basic design. I think such > > optimizations > > touch more than the PANA design, so we should do a more > > thorough analysis. > > Ok. I've created a new issue 16. > > - Dan > > > > > > > Alper > > > > > > From pana-request@research.telcordia.com Mon Jun 23 14:17:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02269 for ; Mon, 23 Jun 2003 14:17:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NIEYuG012729; Mon, 23 Jun 2003 14:14:34 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:14:34 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue9] Message format Date: Mon, 23 Jun 2003 11:14:03 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47F@TNEXVS02.tahoenetworks.com> Thread-Topic: [issue9] Message format Thread-Index: AcMx69KUH4L7nNQ9SHWuD1ayJsLx+AHttCaQ From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: , X-OriginalArrivalTime: 23 Jun 2003 18:14:04.0098 (UTC) FILETIME=[3A907220:01C339B3] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable catching up ... >=20 > On Fri, Jun 13, 2003 at 11:14:54AM -0700, Alper Yegin wrote: > > >> I thought your original message was suggesting using L2 and L3=20 > > >> ciphering at the same time to solve IP address ownership=20 > problem. I=20 > > >> don't see this problem as a motivation to use L2-L3 ciphering at=20 > > >> the same time, since the problem itself is outside the scope of=20 > > >> PANA. If we include L2-L3 ciphering for another reason=20 > (did we find=20 > > >> one?), and it solves this problem with no change to the protocol=20 > > >> design, then its fine. > > >=20 > > > No, I did not mean that the motivation of using L2 and L3=20 > ciphering=20 > > > at the same time was to solve IP address ownership problem. The=20 > > > motivation is to protect network layer traffic (except=20 > for neighbor=20 > > > discovery traffic which is solved by using SEND) from=20 > being spoofed=20 > > > by insider attackers who uses L2 ciphering. To protect network=20 > > > layer traffic, IPsec tunnel is used and thus=20 > bootstrapping IKE from=20 > > > PANA is needed. This is just an additive combination of=20 > > > bootstrapping L2 and L3 ciphering and thus I don't think=20 > we need any=20 > > > change to the current protocol design to achieve this. > >=20 > >=20 > > When L2 ciphering is already used in the network, what kind of=20 > > protection is gained by also enabling IPsec between the PaC and EP=20 > > (other than potentially solving IP address ownership issues)? >=20 > Insider attacker (meaning that he has L2 ciphering keys) can=20 > spoof other insider's higher-layer fields in data packets=20 > (though he cannot spoof L2 headers). I think SEND only=20 > protects ND messages, not data packets. For the same reason, Right. Ipsec will prevent someone spoofing at layer 3. But what does it buy for the attacker ? Here the attacker is the one who is also using L2 cipher. What is the motivation for the attacker to spoof the L3 fields ? He can potentially launch some attack with spoofed L3 fileds. What else ? -mohan > DHCP authentication might be useful=20 > even when L2 ciphering is used. >=20 > Yoshihiro Ohba >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 14:19:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02304 for ; Mon, 23 Jun 2003 14:19:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NIHQHC005143; Mon, 23 Jun 2003 14:17:26 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:17:26 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 11:18:35 -0700 Subject: Re: Issue 8 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <6G7cBB.A.LQB.1Q09-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, >>> - We need a grace period too: >>> Authorization-Lifetime + Auth-Grace-Period <= Session-Timeout >>> Here >>> Auth-Grace-Period < Authorization-Lifetime >>> Unit is seconds. Auth-Grace-Period is a configurable parameter >>> and delivered from PAA to PaC. >> >> I agree there might be a grace period, but I think this can be a local >> decision (via implementation, configuration). Does the >> protocol have to >> carry this information to the other end (PaC)? > > Grace period depends on the authorization and session lifetime. > Network decides both of these (at least the limits), so PaC > must be informed. Network does not have to inform the PaC about the grace period. It does not even have to have a grace period. It's just a courtesy to have one. Do you have examples of other similar protocols carrying grace period in addition to authorized lifetime to their clients? > > I guess we could have many authorization (refresh) periods in one > session lifetime. If PaC fails to reauthenticate (PANA refresh) in > the given authorization (refresh) period, the session is also torn > down. > >>> - PaC should propose something and PAA then decides the actual >>> refresh period and session lifetime (the network knows better >>> the upper and lower limits for re-auth etc.). >> >> Now that I'm thinking, maybe we should only pass the Session-lifetime >> between PAA and PaC, and not worry about Reauth-lifetime. PaC >> and PAA don't >> need to share the Reauth-lifetime, each can trigger reauth as >> often as they >> like/need. But for Session-lifetime, PaC should know it so that it can >> perform PANA authentication again before its session expires and PAA >> disables network access. > > Is it PaC's or PAA's responsibility to do reauth? Any can do. It's up to the entity. If PAA believes it needs to perform re-auth, it can do so. Same for PaC. The signaling can be initiated from any direction, and the other end has to respond when it receives a request. That's why I don't think PaC and PAA need to coordinate anything on this. > Protocol should be > clear about this. Is this not clear (this is in the pana-00 draft): The second type of re-authentication is based on a single protected message exchange without entering the authentication phase. PANA_reauth/PANA_reauth_ack messages are used for this purpose. If there is an established PANA SA, both PaC and PAA can send a PANA_reauth message to the communicating peer whenever it needs to make sure the availability of the PANA SA on the peer and expect the peer to return a PANA_reauth_ack message. Both PANA_reauth / PANA_reauth_ack messages MUST be protected with a MAC AVP. > Otherwise both PaC and PAA might try to do it at the > same time. Is this a problem? If PaC receives a PANA-reauth-request before it sends its own, it can reset its timer (or, optionally keep its own timer and stick to its schedule regarding sending PANA-reauth-requests). Even if two PANA-reauth-requests cross each other, this cannot be a problem either, as each peers would respond to them. > Not clear enough for a protocol spec. > > One way to go is to let PaC initiate the re-authentication after the > authorization lifetime has been exceeded and grace period starts. Grace > period is needed for the processing the refresh/reauth (only the network > knows how much time a refresh can take). > >> >> >>> PaC can optionally >>> propose a Authorization-Lifetime to PAA within a PANA-Auth-Request >>> message. >> >> I also thought about first PaC requesting a value and PAA >> granting one. But >> then looking at the message flows, the other direction seems >> to better fit >> the current design. Instead of one of the PANA-auth messages >> carrying this >> info from PaC to PAA, and the response coming back in >> PANA-success, I think >> doing it symmetrically in PANA-success/ack is better. PANA >> module on the PaC >> won't really know in which PANA-auth message this AVP should >> be included. > > Yes, this is a problem. If PaC makes the final decision, then > the network should inform both the lower and upper limits. We may > need more AVPs? In my proposed text, PAA already informs the PaC about the upper limit. > >> >>> PAA sends Authorization-Lifetime and Auth-Grace-Period >>> AVPs to PaC in PANA-Result-Request message. PAA can also send >>> Session-Timeout AVP to denote the total lifetime of the session. >> >> I don't think we need to pass the grace-period to the PaC. >> (well, if we do, >> it is no longer seen as grace period, but as part of granted period :) > > Grace period doesn't add to the session lifetime, but to the > authorization lifetime. > > authorization_lifetime + grace_period <= session_lifetime > >> >> >> How about this: >> >> - PAA sends (offered) session-lifetime in PANA-success >> message to the PaC. >> If PaC wants to lower the session-lifetime, it MAY include a lower >> session-lifetime in PANA-success-ack. > > We need the lower limit too. I guess this could be stated in the spec, > but the scenarios are different and the network may want to use different > limits, even dynamically (depending on the signaling load etc.). Why do we need the lower limits? Do other protocols do that? > >> >> - It's the responsibility of PaC to perform PANA before its >> current session >> expires. [note: here we are talking about full authentication >> where an EAP >> method is executed, not re-auth] > > Yep. We have two authentications: local refresh, and EAP re-auth. No, this is exactly what I'm trying to clarify. What you refer to as "local refresh" is done by using PANA-reauuth-req/ans. This should have nothing to do with Session-lifetime. PaC and PAA can do this as often as they need to. On the other hand, PANA-auth (that carries EAP) needs to be done before Session lifetime exprires. This is what I'mm talking about in here. > >> >> - Both PaC and PAA can initiate re-auth whenever they need to. > > This must be clarified in the spec. The proposal for issue8 doesn't > take care of this yet. Spec already has a text on this. Alper > > - Dan > >> >> Does this make sense? >> >>> >>> - PANA-Reauth-Request from PAA can optionally contain >>> Authorization-Lifetime AVP to denote the re-auth interval >>> (if network wants to change it)? >>> >>> >> >> >> Alper >> >>> Br, >>> - Dan >>> >>> >>>> -----Original Message----- >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>> Sent: 11 June, 2003 00:10 >>>> To: pana@research.telcordia.com >>>> Subject: Issue 8 >>>> >>>> >>>> >>>> http://danforsberg.info:8080/pana-issues/issue8 >>>> >>>> >>>> How about if we: >>>> >>>> - define a refresh (re-auth) lifetime AVP. >>>> - PAA MUST include this AVP in the PANA_success to provide >> the maximum >>>> allowed refresh lifetime for the PANA session. >>>> - PAA MAY include this AVP in the PANA_success_ack to lower >>>> the required >>>> PANA refresh lifetime. >>>> >>>> At the end of PANA_success round, both PAA and PaC knows >> the refresh >>>> frequency. >>>> >>>> PaC MAY send PANA_reauth before this period expires. PAA MUST send >>>> PANA-reauth if there was no PANA-reauth exchange for one >> full period. >>>> >>>> Comments? >>>> >>>> Alper >>>> >>>> >>> >>> >>> >> >> > > From pana-request@research.telcordia.com Mon Jun 23 14:38:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03380 for ; Mon, 23 Jun 2003 14:38:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NIZpTl014214; Mon, 23 Jun 2003 14:35:51 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:35:51 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 11:35:46 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030623183546.GB28306@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47F@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A47F@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 25 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jun 23, 2003 at 11:14:03AM -0700, Mohan Parthasarathy wrote: > > > When L2 ciphering is already used in the network, what kind of > > > protection is gained by also enabling IPsec between the PaC and EP > > > (other than potentially solving IP address ownership issues)? > > > > Insider attacker (meaning that he has L2 ciphering keys) can > > spoof other insider's higher-layer fields in data packets > > (though he cannot spoof L2 headers). I think SEND only > > protects ND messages, not data packets. For the same reason, > > Right. Ipsec will prevent someone spoofing at layer 3. But > what does it buy for the attacker ? Here the attacker is > the one who is also using L2 cipher. What is the motivation > for the attacker to spoof the L3 fields ? He can potentially > launch some attack with spoofed L3 fileds. What else ? He can also spoof L4 and higher-layer fields of a legitimate client's traffic in addition to L3 fields. Note that a legitimate client with using IPsec in the access network (or VPN or end-to-end ) can also spoof its own higher-layer traffic, but that is completely out of the scope of network access security and should be protected by using transport- and/or application-layer security. Yoshihiro Ohba From pana-request@research.telcordia.com Mon Jun 23 14:39:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03441 for ; Mon, 23 Jun 2003 14:39:27 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NIbIVL025779; Mon, 23 Jun 2003 14:37:18 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:37:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 11:38:28 -0700 Subject: Re: Security threat (was: RE: [issue9] Message format) From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, > What if the authenticated PaC itself becomes malicious? It can blindly > spoof other PaCs addresses. This is a security threat, even if the MAC > address is bound to accounting. I agreed :) I'm not disagreeing with the security threat here. I'm disagreeing with the assumption that this is a problem that *must* be solved by PANA. Let's first agree (or disagree :) on that. Note that this does not mean PANA *must not* solve it. PANA may solve it, or PANA may assist another protocol solve it, etc... But we need to thoroughly understand the problem, and its relation to existing/upcoming solution space. > >> >>> >>> That would mean that PaC can freely spoof IP addresses. >> >> Exactly. But, this is a SEND problem, not PANA problem. > > This problem goes beyond SEND and even IPSec. SEND is for discovery > only, not for protecting data packets like IPSec. I agree this is beyond SEND, according to SEND's current scope. But it is the closest to what SEND is aiming: proving ownership of IP address for address resolution. It's only reasonable to assume that the next step could be proving ownership of IP address for sending IP packets. > On the other > hand IPSec is used for protecting malicious users from stealing > other's connections on the access link, right? Or should we say > that IPSec is used for making sure that only "paying" customers > can send packets. > > The access network doesn't want the PaCs to be able to spoof > network nodes that are inside the access network (behind the > first AR). What the EP wants to do is to make sure that the > packet coming from PaCs has an IP address that belongs to the > correct subnet prefix (access link prefix). By default the > policy in the EP (in most cases) is to deny all IP addresses > if not authenticated AND authorized properly. > > The problem is authorization of data packets that pass through > the EP. IPSec takes care of authentication (SEND doesn't do > neither). > > With IPSec tunnel between PaC and PAA, the inner IP address > MUST be checked too! Otherwise authenticated and authorized > PaCs can spoof IP addresses. PANA deals with authorizing a Pac to send and receive packets. That's all. PANA does not deal with any other authorization. That does not mean that these are all the problems that needs to be solved to make an access network 100% secure. Alper From pana-request@research.telcordia.com Mon Jun 23 14:54:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04057 for ; Mon, 23 Jun 2003 14:54:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NIqCtb007083; Mon, 23 Jun 2003 14:52:12 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 14:52:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 11:53:20 -0700 Subject: Re: [issue9] Message format From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <5mb0IB.A.SuB.cx09-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable On 6/23/03 8:29 AM, "Dan.Forsberg@nokia.com" wrote= : > We have removed the EAP-Payload AVP from the PANA-Reauth-* messages. > Should we keep it for the case of EAP notification in > PANA-Reauth-Request? Can EAP notifications be sent after EAP-Success/Failure is delivered? If not, we would not have a reason to carry them in PANA-reauth-*. Alper >=20 > - Dan >=20 >> -----Original Message----- >> From: ext [mailto:Dan.Forsberg@nokia.com] >> Sent: 23 June, 2003 18:26 >> To: pana@research.telcordia.com >> Subject: [issue9] Message format >>=20 >>=20 >> Dan Forsberg added the comment: >>=20 >> New version (e)=AD. >> Changes: >> - PANA-Auth-Answer abbr to PAN (was PAA). >> - PANA-Result-Request MUST always have an EAP payload AVP. >> - Removed Result-Code AVP from PANA-Auth-Answer. >> - Removed EAP-Payload from PANA-Reauth-* >> - Removed Add/Remove-Device-Id for now (see issue16). >> - Added more text for the session id AVP. >> - Result-Code AVP values . >> - Termination-Cause AVP values . >> - PANA-Result-Request --> PANA-Bind-Request >> PANA-Result-Answer --> PANA-Bind-Answer >> - Editorial fixes. >>=20 >> _______________________________________________ >> PANA Issues >> http://danforsberg.info:8080/pana-issues/issue9 >> _______________________________________________ >>=20 >>=20 >=20 >=20 >=20 From pana-request@research.telcordia.com Mon Jun 23 15:44:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07448 for ; Mon, 23 Jun 2003 15:44:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NJenbm011302; Mon, 23 Jun 2003 15:40:49 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 15:40:49 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue9] Message format Date: Mon, 23 Jun 2003 12:40:18 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A480@TNEXVS02.tahoenetworks.com> Thread-Topic: [issue9] Message format Thread-Index: AcM5tldq6qPo60HFREKfRyqf0fP7AgAApI5g From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , , X-OriginalArrivalTime: 23 Jun 2003 19:40:19.0199 (UTC) FILETIME=[472A30F0:01C339BF] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > On Mon, Jun 23, 2003 at 11:14:03AM -0700, Mohan Parthasarathy wrote: > > > > When L2 ciphering is already used in the network, what kind of > > > > protection is gained by also enabling IPsec between the=20 > PaC and EP=20 > > > > (other than potentially solving IP address ownership issues)? > > >=20 > > > Insider attacker (meaning that he has L2 ciphering keys) can > > > spoof other insider's higher-layer fields in data packets=20 > > > (though he cannot spoof L2 headers). I think SEND only=20 > > > protects ND messages, not data packets. For the same reason, > >=20 > > Right. Ipsec will prevent someone spoofing at layer 3. But=20 > what does=20 > > it buy for the attacker ? Here the attacker is the one who is also=20 > > using L2 cipher. What is the motivation for the attacker to=20 > spoof the=20 > > L3 fields ? He can potentially launch some attack with spoofed L3=20 > > fileds. What else ? >=20 > He can also spoof L4 and higher-layer fields of a legitimate=20 > client's traffic in addition to L3 fields. Note that a=20 If the PaC needs to protect against that, why would it not use some other end-to-end mechanism rather than resorting to securing just the first hop with IPsec ? > legitimate client with using IPsec in the access network (or=20 > VPN or end-to-end ) can also spoof its own higher-layer=20 > traffic, but that is completely out of the scope of network=20 > access security and should be protected by using > transport- and/or application-layer security. >=20 > Yoshihiro Ohba >=20 mohan From pana-request@research.telcordia.com Mon Jun 23 16:57:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09725 for ; Mon, 23 Jun 2003 16:56:05 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NKpaXf010608; Mon, 23 Jun 2003 16:51:36 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 16:51:36 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 23 Jun 2003 13:51:26 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: [issue9] Message format Message-ID: <20030623205126.GA29567@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A480@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A480@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 47 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Jun 23, 2003 at 12:40:18PM -0700, Mohan Parthasarathy wrote: > > > > > > On Mon, Jun 23, 2003 at 11:14:03AM -0700, Mohan Parthasarathy wrote: > > > > > When L2 ciphering is already used in the network, what kind of > > > > > protection is gained by also enabling IPsec between the > > PaC and EP > > > > > (other than potentially solving IP address ownership issues)? > > > > > > > > Insider attacker (meaning that he has L2 ciphering keys) can > > > > spoof other insider's higher-layer fields in data packets > > > > (though he cannot spoof L2 headers). I think SEND only > > > > protects ND messages, not data packets. For the same reason, > > > > > > Right. Ipsec will prevent someone spoofing at layer 3. But > > what does > > > it buy for the attacker ? Here the attacker is the one who is also > > > using L2 cipher. What is the motivation for the attacker to > > spoof the > > > L3 fields ? He can potentially launch some attack with spoofed L3 > > > fileds. What else ? > > > > He can also spoof L4 and higher-layer fields of a legitimate > > client's traffic in addition to L3 fields. Note that a > > If the PaC needs to protect against that, why would it not > use some other end-to-end mechanism rather than resorting > to securing just the first hop with IPsec ? You are right. On the other hand, I just answered to your question on what fields an attacker on the first hop can spoof when there is no first hop IPsec. Yoshihiro Ohba > > > legitimate client with using IPsec in the access network (or > > VPN or end-to-end ) can also spoof its own higher-layer > > traffic, but that is completely out of the scope of network > > access security and should be protected by using > > transport- and/or application-layer security. > > > > Yoshihiro Ohba > > > mohan > From pana-request@research.telcordia.com Mon Jun 23 17:43:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11475 for ; Mon, 23 Jun 2003 17:43:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5NLVv2O028415; Mon, 23 Jun 2003 17:31:57 -0400 (EDT) Resent-Date: Mon, 23 Jun 2003 17:31:57 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue9] Message format Date: Mon, 23 Jun 2003 14:31:49 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A481@TNEXVS02.tahoenetworks.com> Thread-Topic: [issue9] Message format Thread-Index: AcM5yVId3pjujJXiQ1eKh5D5tFOY/AABQ1xQ From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , , X-OriginalArrivalTime: 23 Jun 2003 21:31:50.0183 (UTC) FILETIME=[DB4D5370:01C339CE] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > On Mon, Jun 23, 2003 at 12:40:18PM -0700, Mohan Parthasarathy wrote: > >=20 > > =20 > > >=20 > > > On Mon, Jun 23, 2003 at 11:14:03AM -0700, Mohan=20 > Parthasarathy wrote: > > > > > > When L2 ciphering is already used in the network,=20 > what kind of=20 > > > > > > protection is gained by also enabling IPsec between the > > > PaC and EP > > > > > > (other than potentially solving IP address=20 > ownership issues)? > > > > >=20 > > > > > Insider attacker (meaning that he has L2 ciphering keys) can=20 > > > > > spoof other insider's higher-layer fields in data packets=20 > > > > > (though he cannot spoof L2 headers). I think SEND=20 > only protects=20 > > > > > ND messages, not data packets. For the same reason, > > > >=20 > > > > Right. Ipsec will prevent someone spoofing at layer 3. But > > > what does > > > > it buy for the attacker ? Here the attacker is the one=20 > who is also > > > > using L2 cipher. What is the motivation for the attacker to=20 > > > spoof the > > > > L3 fields ? He can potentially launch some attack with=20 > spoofed L3 > > > > fileds. What else ? > > >=20 > > > He can also spoof L4 and higher-layer fields of a legitimate > > > client's traffic in addition to L3 fields. Note that a=20 > >=20 > > If the PaC needs to protect against that, why would it not use some=20 > > other end-to-end mechanism rather than resorting to=20 > securing just the=20 > > first hop with IPsec ? >=20 > You are right. On the other hand, I just answered to your=20 > question on what fields an attacker on the first hop can=20 > spoof when there is no first hop IPsec. Ok. The original argument (I may have mistaken) was about whether L2 and Ipsec will be used together. Even though there might be spoofing without Ipsec, the PaC/application needs other way to protect traffic end2end and hence using Ipsec just on the first hop when L2 ciphering is in use may not be that common. -mohan >=20 > Yoshihiro Ohba >=20 > >=20 > > > legitimate client with using IPsec in the access network (or > > > VPN or end-to-end ) can also spoof its own higher-layer=20 > > > traffic, but that is completely out of the scope of network=20 > > > access security and should be protected by using > > > transport- and/or application-layer security. > > >=20 > > > Yoshihiro Ohba > > >=20 > > mohan > >=20 >=20 From pana-request@research.telcordia.com Tue Jun 24 05:39:04 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08384 for ; Tue, 24 Jun 2003 05:37:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5O9W8Dq024083; Tue, 24 Jun 2003 05:32:08 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 05:32:08 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: Issue 8 Date: Tue, 24 Jun 2003 12:32:02 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcM5s7KeAwy0JQijRCO+nZukYOqoLQAbw2/g From: To: , X-OriginalArrivalTime: 24 Jun 2003 09:32:03.0653 (UTC) FILETIME=[78898F50:01C33A33] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi Alper, > >>> - We need a grace period too: > >>> Authorization-Lifetime + Auth-Grace-Period <=3D Session-Timeout > >>> Here > >>> Auth-Grace-Period < Authorization-Lifetime > >>> Unit is seconds. Auth-Grace-Period is a configurable parameter > >>> and delivered from PAA to PaC. > >>=20 > >> I agree there might be a grace period, but I think this=20 > can be a local > >> decision (via implementation, configuration). Does the > >> protocol have to > >> carry this information to the other end (PaC)? > >=20 > > Grace period depends on the authorization and session lifetime. > > Network decides both of these (at least the limits), so PaC > > must be informed. >=20 > Network does not have to inform the PaC about the grace=20 > period. It does not > even have to have a grace period. It's just a courtesy to=20 > have one. Do you > have examples of other similar protocols carrying grace=20 > period in addition > to authorized lifetime to their clients? Session-Lifetime, Auth-Grace-Period, and Authorization-Lifetime AVPs are = all used in the Diameter base protocol. The AAA home server decides the = lifetimes. Auth-Grace-Period is implicitly used in any case, because we have to = make a choice when to start re-authentication before the = session-lifetime ends. If we nail it down in the spec, it creates limits = for the session lifetime and refresh interval. That's ok for me. >=20 > >=20 > > I guess we could have many authorization (refresh) periods in one > > session lifetime. If PaC fails to reauthenticate (PANA refresh) in > > the given authorization (refresh) period, the session is also torn > > down. > >=20 > >>> - PaC should propose something and PAA then decides the actual > >>> refresh period and session lifetime (the network knows better > >>> the upper and lower limits for re-auth etc.). > >>=20 > >> Now that I'm thinking, maybe we should only pass the=20 > Session-lifetime > >> between PAA and PaC, and not worry about Reauth-lifetime. PaC > >> and PAA don't > >> need to share the Reauth-lifetime, each can trigger reauth as > >> often as they > >> like/need. But for Session-lifetime, PaC should know it so=20 > that it can > >> perform PANA authentication again before its session=20 > expires and PAA > >> disables network access. > >=20 > > Is it PaC's or PAA's responsibility to do reauth? >=20 > Any can do. It's up to the entity. If PAA believes it needs to perform > re-auth, it can do so. Same for PaC. The signaling can be=20 > initiated from any > direction, and the other end has to respond when it receives=20 > a request. > That's why I don't think PaC and PAA need to coordinate=20 > anything on this. When does PaC or PAA know when to do reauth if they don't negotiate it? = In MIPv6 for example the HA sends optionally a Binding Refresh Advice = for the MN (draft23, sec. 6.2.4). If we let PaC and PAA initiate refresh any time, the refresh message = becomes a legitimitate DoS attack (PaC or PAA floods refresh messages). = If we have a negotiated refresh period, PAA/PaC doesn't have to process = refresh messages all the time, but can discard them (defense).=20 Time based accounting benefits from negotiated refresh period.=20 With multihoming (see issue16) refresh messages can be used to refresh = different "bindings" in one session. Here negotiated interval is needed. >=20 > > Protocol should be > > clear about this. >=20 > Is this not clear (this is in the pana-00 draft): >=20 > The second type of re-authentication is based on a single protected > message exchange without entering the authentication phase. > PANA_reauth/PANA_reauth_ack messages are used for this purpose. If > there is an established PANA SA, both PaC and PAA can send a > PANA_reauth message to the communicating peer whenever it needs to > make sure the availability of the PANA SA on the peer and=20 > expect the > peer to return a PANA_reauth_ack message. Both PANA_reauth / > PANA_reauth_ack messages MUST be protected with a MAC AVP. >=20 > > Otherwise both PaC and PAA might try to do it at the > > same time.=20 >=20 > Is this a problem? If PaC receives a PANA-reauth-request=20 > before it sends > its own, it can reset its timer (or, optionally keep its own=20 > timer and stick > to its schedule regarding sending PANA-reauth-requests). Even if two > PANA-reauth-requests cross each other, this cannot be a=20 > problem either, as > each peers would respond to them. See comments above. >=20 > > Not clear enough for a protocol spec. > >=20 > > One way to go is to let PaC initiate the re-authentication after the > > authorization lifetime has been exceeded and grace period=20 > starts. Grace > > period is needed for the processing the refresh/reauth=20 > (only the network > > knows how much time a refresh can take). > >=20 > >>=20 > >>=20 > >>> PaC can optionally > >>> propose a Authorization-Lifetime to PAA within a PANA-Auth-Request > >>> message.=20 > >>=20 > >> I also thought about first PaC requesting a value and PAA > >> granting one. But > >> then looking at the message flows, the other direction seems > >> to better fit > >> the current design. Instead of one of the PANA-auth messages > >> carrying this > >> info from PaC to PAA, and the response coming back in > >> PANA-success, I think > >> doing it symmetrically in PANA-success/ack is better. PANA > >> module on the PaC > >> won't really know in which PANA-auth message this AVP should > >> be included. > >=20 > > Yes, this is a problem. If PaC makes the final decision, then > > the network should inform both the lower and upper limits. We may > > need more AVPs? >=20 > In my proposed text, PAA already informs the PaC about the=20 > upper limit. >=20 > >=20 > >>=20 > >>> PAA sends Authorization-Lifetime and Auth-Grace-Period > >>> AVPs to PaC in PANA-Result-Request message. PAA can also send > >>> Session-Timeout AVP to denote the total lifetime of the session. > >>=20 > >> I don't think we need to pass the grace-period to the PaC. > >> (well, if we do, > >> it is no longer seen as grace period, but as part of=20 > granted period :) > >=20 > > Grace period doesn't add to the session lifetime, but to the > > authorization lifetime. > >=20 > > authorization_lifetime + grace_period <=3D session_lifetime > >=20 > >>=20 > >>=20 > >> How about this: > >>=20 > >> - PAA sends (offered) session-lifetime in PANA-success > >> message to the PaC. > >> If PaC wants to lower the session-lifetime, it MAY include a lower > >> session-lifetime in PANA-success-ack. > >=20 > > We need the lower limit too. I guess this could be stated=20 > in the spec, > > but the scenarios are different and the network may want to=20 > use different > > limits, even dynamically (depending on the signaling load etc.). >=20 > Why do we need the lower limits? Do other protocols do that? MIPv6 draft uses "Binding Refresh Advice" (sec. 6.2.4) and also the HA = finally makes the decision about the BU lifetime. If I remember = correctly in MIPv4 the MN suggests a lifetime but the network makes = final decision. There is no need for lower limit "advice", because the = network decides. If we use seconds in the AVP the lower limit is 1s. The network may want = to make it higher to prevent signaling flood with many clients. If we = make the lower limit to 5s, that may be too high or too low. >=20 > >=20 > >>=20 > >> - It's the responsibility of PaC to perform PANA before its > >> current session > >> expires. [note: here we are talking about full authentication > >> where an EAP > >> method is executed, not re-auth] > >=20 > > Yep. We have two authentications: local refresh, and EAP re-auth. >=20 > No, this is exactly what I'm trying to clarify. What you=20 > refer to as "local > refresh" is done by using PANA-reauuth-req/ans. This should=20 > have nothing to > do with Session-lifetime. PaC and PAA can do this as often as=20 > they need to. That's right. But PaC and PAA need to co-ordinate the refresh period = (see comments above). >=20 > On the other hand, PANA-auth (that carries EAP) needs to be=20 > done before > Session lifetime exprires. This is what I'mm talking about in here. Yep, but the issue8 was all about refresh interval negotiation. Session = lifetime negotiation is a different issue. Anyway, it's good that it's = solved. >=20 > >=20 > >>=20 > >> - Both PaC and PAA can initiate re-auth whenever they need to. > >=20 > > This must be clarified in the spec. The proposal for issue8 doesn't > > take care of this yet. >=20 > Spec already has a text on this. With clarification I meant the negotiation. - Dan >=20 > Alper >=20 >=20 >=20 > >=20 > > - Dan > >=20 > >>=20 > >> Does this make sense? > >>=20 > >>>=20 > >>> - PANA-Reauth-Request from PAA can optionally contain > >>> Authorization-Lifetime AVP to denote the re-auth interval > >>> (if network wants to change it)? > >>>=20 > >>>=20 > >>=20 > >>=20 > >> Alper > >>=20 > >>> Br, > >>> - Dan > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >>>> Sent: 11 June, 2003 00:10 > >>>> To: pana@research.telcordia.com > >>>> Subject: Issue 8 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> http://danforsberg.info:8080/pana-issues/issue8 > >>>>=20 > >>>>=20 > >>>> How about if we: > >>>>=20 > >>>> - define a refresh (re-auth) lifetime AVP. > >>>> - PAA MUST include this AVP in the PANA_success to provide > >> the maximum > >>>> allowed refresh lifetime for the PANA session. > >>>> - PAA MAY include this AVP in the PANA_success_ack to lower > >>>> the required > >>>> PANA refresh lifetime. > >>>>=20 > >>>> At the end of PANA_success round, both PAA and PaC knows > >> the refresh > >>>> frequency.=20 > >>>>=20 > >>>> PaC MAY send PANA_reauth before this period expires. PAA=20 > MUST send > >>>> PANA-reauth if there was no PANA-reauth exchange for one > >> full period. > >>>>=20 > >>>> Comments? > >>>>=20 > >>>> Alper > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>>=20 > >>=20 > >>=20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Tue Jun 24 06:28:24 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09469 for ; Tue, 24 Jun 2003 06:28:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5OAQ92w003350; Tue, 24 Jun 2003 06:26:09 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 06:26:09 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: Security threat (was: RE: [issue9] Message format) Date: Tue, 24 Jun 2003 13:26:00 +0300 Message-ID: Thread-Topic: Security threat (was: RE: [issue9] Message format) Thread-Index: AcM5tngbJuLfsaAqTSOkOQoNWr6+PwAfS1rw From: To: , X-OriginalArrivalTime: 24 Jun 2003 10:26:01.0014 (UTC) FILETIME=[0227A560:01C33A3B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi Alper, PANA kind of bootstraps with the help of EAP the initial SA between the = client and the access network. This makes PANA a natural protocol to = (securely) carry the IP addresses to the access network. Additionally = the MAC address can be sent too. Why not to use two Device-Id AVPs, one = for MAC (if needed) and one for IP address?=20 - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 23 June, 2003 21:38 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: Security threat (was: RE: [issue9] Message format) >=20 >=20 > Hi Dan, >=20 > > What if the authenticated PaC itself becomes malicious? It=20 > can blindly > > spoof other PaCs addresses. This is a security threat, even=20 > if the MAC > > address is bound to accounting. >=20 > I agreed :) I'm not disagreeing with the security threat here. I'm > disagreeing with the assumption that this is a problem that=20 > *must* be solved > by PANA. Let's first agree (or disagree :) on that. Note that=20 > this does not > mean PANA *must not* solve it. PANA may solve it, or PANA may=20 > assist another > protocol solve it, etc... But we need to thoroughly=20 > understand the problem, > and its relation to existing/upcoming solution space. >=20 > >=20 > >>=20 > >>>=20 > >>> That would mean that PaC can freely spoof IP addresses. > >>=20 > >> Exactly. But, this is a SEND problem, not PANA problem. > >=20 > > This problem goes beyond SEND and even IPSec. SEND is for discovery > > only, not for protecting data packets like IPSec. >=20 > I agree this is beyond SEND, according to SEND's current=20 > scope. But it is > the closest to what SEND is aiming: proving ownership of IP=20 > address for > address resolution. It's only reasonable to assume that the=20 > next step could > be proving ownership of IP address for sending IP packets. >=20 > > On the other=20 > > hand IPSec is used for protecting malicious users from stealing > > other's connections on the access link, right? Or should we say > > that IPSec is used for making sure that only "paying" customers > > can send packets. > >=20 > > The access network doesn't want the PaCs to be able to spoof > > network nodes that are inside the access network (behind the > > first AR). What the EP wants to do is to make sure that the > > packet coming from PaCs has an IP address that belongs to the > > correct subnet prefix (access link prefix). By default the > > policy in the EP (in most cases) is to deny all IP addresses > > if not authenticated AND authorized properly. > >=20 > > The problem is authorization of data packets that pass through > > the EP. IPSec takes care of authentication (SEND doesn't do > > neither). > >=20 > > With IPSec tunnel between PaC and PAA, the inner IP address > > MUST be checked too! Otherwise authenticated and authorized > > PaCs can spoof IP addresses. >=20 > PANA deals with authorizing a Pac to send and receive=20 > packets. That's all. > PANA does not deal with any other authorization. >=20 > That does not mean that these are all the problems that needs=20 > to be solved > to make an access network 100% secure. >=20 >=20 > Alper >=20 >=20 From pana-request@research.telcordia.com Tue Jun 24 10:05:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16652 for ; Tue, 24 Jun 2003 10:04:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5ODxOiG010648; Tue, 24 Jun 2003 09:59:24 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 09:59:24 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: PANA protocol based on IKEv2? Date: Tue, 24 Jun 2003 16:55:33 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222A8@esebe023.ntc.nokia.com> Thread-Topic: PANA protocol based on IKEv2? Thread-Index: AcM6WEfeLAN7540OQ3SoD/PF1xl9og== From: To: X-OriginalArrivalTime: 24 Jun 2003 13:55:34.0153 (UTC) FILETIME=[48546790:01C33A58] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi, I was reading past PANA discussions, and I got this wild=20 idea... since much of the discussion seems to be related to=20 rather simple message formatting and other protocol issues, why not "borrow" these from an existing protocol for setting up SAs for other protocols, namely IKEv2? Let's see how this could be done: - We still need a PANA-specific discovery protocol (multicast or something), but it can be quite simple. - For the rest of the protocol, we can copy message structures from IKEv2. In the CREATE_CHILD_SA ("Phase 2") exchange we just replace the IPsec proposals with proposals for something=20 else (we're not setting up IPsec AH/ESP security association). We could define proposal types for e.g. - "bootstrap IKEv1 to enforcement point 10.1.2.3; shared secret keying material derived according to usual IKEv2 rules" - "bootstrap secure DHCP to DHCP server 10.1.2.3" - "bootstrap some L2 crypto, " - What we could borrow from IKEv2? - Message formatting=20 - Message protection (something not included in Diameter!) - EAP support (and cryptographic binding) - "Phase 2" proposal structures (IKEv2 has a nested syntax for=20 proposals, supporting AND/OR (e.g. (X and Y) or Z), attributes=20 for proposals, etc.) - How keys for other SAs are derived from IKEv2 SA - Cookies for DoS protection - Retransmissions - Error messages - Disconnect indication/session revocation - Periodic refresh messages - BTW, IKEv2 can also assign IP addresses to the client, but maybe this is not needed. (Note that this list includes much more than we could borrow from Diameter, and the main point is not message formatting) - What we would need to do (at least) - Define suitable proposal structures for whatever protocols we want to bootstrap using the PANA SA. - Probably define new Identification payload types for MAC-address type Device Identifiers. - Specify exactly how re-authentication and disconnect/revocation works (IPsec SAs are unidirectional, so they work a bit=20 differently) Ok, I said this was a wild idea :)=20 Any comments are most welcome! Best regards, Pasi From pana-request@research.telcordia.com Tue Jun 24 12:52:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23450 for ; Tue, 24 Jun 2003 12:52:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5OGkMGh026022; Tue, 24 Jun 2003 12:46:22 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 12:46:22 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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 protocol based on IKEv2? Date: Tue, 24 Jun 2003 19:42:33 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222AB@esebe023.ntc.nokia.com> Thread-Topic: PANA protocol based on IKEv2? Thread-Index: AcM6ajXHGSXp7vsfRqCa1ps1+dVlzwAAi5uw From: To: , X-OriginalArrivalTime: 24 Jun 2003 16:42:33.0622 (UTC) FILETIME=[9C660B60:01C33A6F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hi Hannes, Sorry, I wasn't aware that this idea had been already discussed. However, I don't 100% agree on the reasons given for rejecting a protocol based on IKEv2-like messages. Using IKEv2-like messages does not necessarily imply establishing=20 a server-to-client authenticated tunnel. I admit that IKEv2 is=20 usually used with such a tunnel, and that is problematic for PANA;=20 mostly for the reason that the tunnel requires certificates=20 for the server-to-client authentication (which sort of breaks=20 the extensibility idea in EAP). =20 But PANA could easily use IKEv2-like messages without requiring=20 this, so the server-to-client authentication would be based solely=20 on EAP keys (just omit the AUTH payload from the 2nd message from Responder, and all CERT/CERTREQ payloads). The man-in-the-middle=20 attack discovered by Kaisa Nyberg et al. is taken into account in IKEv2. I'm not saying that using IKEv2-like messages would be a major=20 security improvement (it would eliminate all passive eavesdropping=20 attacks, though). I think the more important issue would be getting=20 many of the other "small" details of the protocol (I'm referring to=20 all the discussions about message formatting, calculating MACs,=20 session-ids, cookies, retransmissions, error messages, key derivation,=20 etc.) Best regards, Pasi > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Tuesday, June 24, 2003 7:04 PM > To: Eronen Pasi (NRC/Helsinki); pana@research.telcordia.com > Subject: RE: PANA protocol based on IKEv2? >=20 >=20 > hi pasi,=20 >=20 > thanks for your observation. however, we discussed this issue=20 > some time ago > during the pana design team work at. please take a look at: > http://danforsberg.info/pipermail/pana-dt/ >=20 > furthermore, i briefly mentioned the two possible approaches=20 > at the last > ietf meeting - see slides at > http://people.nokia.net/~patil/IETF56/PANA/ > see slide 18 and slide 34 at > http://people.nokia.net/~patil/IETF56/PANA/PANA_Solution_Slide > s_7.pdf.=20 > the two-step approach thereby refers to the ikev2, pic and similar > approaches.=20 >=20 > since the pana protocol does not only focus on establishing=20 > ipsec sas and since we do not always want to establish a "tunnel"=20 > (i.e. server-to-client auth.) before executing eap we rejected=20 > this approach. =20 > btw, with the discovered man-in-the-middle attacks by kaisa=20 > nyberg and her collegues the justification for establishing a=20 > tunnel is rather weak in the meanwhile.=20 >=20 > regarding secure address configuration please take a look at:=20 > http://www.tschofenig.com/drafts/draft-tschofenig-pana-bootstr > ap-rfc3118-00. > txt >=20 > ciao > hannes From pana-request@research.telcordia.com Tue Jun 24 13:57:47 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27679 for ; Tue, 24 Jun 2003 13:57:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5OHtGee015956; Tue, 24 Jun 2003 13:55:16 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 13:55:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 24 Jun 2003 10:55:07 -0700 To: Pasi.Eronen@nokia.com Cc: hannes.tschofenig@siemens.com, pana@research.telcordia.com Subject: Re: PANA protocol based on IKEv2? Message-ID: <20030624175507.GD362@steelhead> Mail-Followup-To: Pasi.Eronen@nokia.com, hannes.tschofenig@siemens.com, pana@research.telcordia.com References: <052E0C61B69C3741AFA5FE88ACC775A61222AB@esebe023.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222AB@esebe023.ntc.nokia.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 108 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Pasi, I agree that using IKEv2-like messages does not necessarily imply establishing a server-to-client authenticated tunnel. However, establising a secure tunnel is needed anyway. As far as I understand, using IKEv2-like messaging has the following characteristics: Establising a secure tunnel needs Diffie-Hellman key exchange. Then EAP is carried through the tunnel. If lower-layer is secure (this is one PANA usage scenario), such D-H is obviously not necessary. On the other hand, if lower-layer is insecure (this is also a PANA usage scenario), then we need to deal with cryptographic binding to deal with man-in-the-middle attacks for the compound authentication method. IKEv2 solves this by using AUTH payload in IKE_AUTH exchange, where the AUTH payload is calculated by using a shared key derived from an EAP authentication method. But this implies that another D-H (or other public-key based) key exchange is needed to derived the shared key from the EAP authentication method (if the EAP authentication method does another level(s) of tunneling, it may need more D-H(s)). But if we follow the current PANA design, the number of D-Hs can be reduced by one compared to the IKEv2-based method and that's why we thought the current approach is simpler and better than IKEv2-like messaging though both approaches satisfy the PANA requirements. (I'd rather suggest considering to use IKEv2 as an EAP authentication method [draft-tschofenig-eap-ikev2-00.txt], which provides a robuster solution for "invalid-MIC" DoS attack than using TLS-bases EAP authentication methods, since IKEv2 silently discards messages that contain invalid MIC, instead of immediately ending the conversation.) Regards, Yoshihiro Ohba On Tue, Jun 24, 2003 at 07:42:33PM +0300, Pasi.Eronen@nokia.com wrote: > > Hi Hannes, > > Sorry, I wasn't aware that this idea had been already discussed. > However, I don't 100% agree on the reasons given for rejecting > a protocol based on IKEv2-like messages. > > Using IKEv2-like messages does not necessarily imply establishing > a server-to-client authenticated tunnel. I admit that IKEv2 is > usually used with such a tunnel, and that is problematic for PANA; > mostly for the reason that the tunnel requires certificates > for the server-to-client authentication (which sort of breaks > the extensibility idea in EAP). > > But PANA could easily use IKEv2-like messages without requiring > this, so the server-to-client authentication would be based solely > on EAP keys (just omit the AUTH payload from the 2nd message from > Responder, and all CERT/CERTREQ payloads). The man-in-the-middle > attack discovered by Kaisa Nyberg et al. is taken into account in IKEv2. > > I'm not saying that using IKEv2-like messages would be a major > security improvement (it would eliminate all passive eavesdropping > attacks, though). I think the more important issue would be getting > many of the other "small" details of the protocol (I'm referring to > all the discussions about message formatting, calculating MACs, > session-ids, cookies, retransmissions, error messages, key derivation, > etc.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Tuesday, June 24, 2003 7:04 PM > > To: Eronen Pasi (NRC/Helsinki); pana@research.telcordia.com > > Subject: RE: PANA protocol based on IKEv2? > > > > > > hi pasi, > > > > thanks for your observation. however, we discussed this issue > > some time ago > > during the pana design team work at. please take a look at: > > http://danforsberg.info/pipermail/pana-dt/ > > > > furthermore, i briefly mentioned the two possible approaches > > at the last > > ietf meeting - see slides at > > http://people.nokia.net/~patil/IETF56/PANA/ > > see slide 18 and slide 34 at > > http://people.nokia.net/~patil/IETF56/PANA/PANA_Solution_Slide > > s_7.pdf. > > the two-step approach thereby refers to the ikev2, pic and similar > > approaches. > > > > since the pana protocol does not only focus on establishing > > ipsec sas and since we do not always want to establish a "tunnel" > > (i.e. server-to-client auth.) before executing eap we rejected > > this approach. > > btw, with the discovered man-in-the-middle attacks by kaisa > > nyberg and her collegues the justification for establishing a > > tunnel is rather weak in the meanwhile. > > > > regarding secure address configuration please take a look at: > > http://www.tschofenig.com/drafts/draft-tschofenig-pana-bootstr > > ap-rfc3118-00. > > txt > > > > ciao > > hannes > > From pana-request@research.telcordia.com Tue Jun 24 23:20:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04704 for ; Tue, 24 Jun 2003 23:19:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5P2pGf2008215; Tue, 24 Jun 2003 22:51:16 -0400 (EDT) Resent-Date: Tue, 24 Jun 2003 22:51:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 24 Jun 2003 19:52:16 -0700 Subject: Re: Issue 8 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, >> Network does not have to inform the PaC about the grace >> period. It does not >> even have to have a grace period. It's just a courtesy to >> have one. Do you >> have examples of other similar protocols carrying grace >> period in addition >> to authorized lifetime to their clients? > > Session-Lifetime, Auth-Grace-Period, and Authorization-Lifetime AVPs are all > used in the Diameter base protocol. The AAA home server decides the lifetimes. Are they transmitted to the peer in 802.1X, PPP, or Mobile IPv4? That's my question. I'm trying to understand what should be carried in PANA. Your above example is about what gets carried in backend AAA protocol. >>> Is it PaC's or PAA's responsibility to do reauth? >> >> Any can do. It's up to the entity. If PAA believes it needs to perform >> re-auth, it can do so. Same for PaC. The signaling can be >> initiated from any >> direction, and the other end has to respond when it receives >> a request. >> That's why I don't think PaC and PAA need to coordinate >> anything on this. > > When does PaC or PAA know when to do reauth if they don't negotiate it? This is a local decision. Nothing that requires other peer's collaboration, right? > In > MIPv6 for example the HA sends optionally a Binding Refresh Advice for the MN > (draft23, sec. 6.2.4). > > If we let PaC and PAA initiate refresh any time, the refresh message becomes a > legitimitate DoS attack (PaC or PAA floods refresh messages). If we have a > negotiated refresh period, PAA/PaC doesn't have to process refresh messages > all the time, but can discard them (defense). If the PaC wants to launch a DoS attack, it does not need re-auth messages. It can send authenticated data packets or PANA-auth messages. Same level of DoS can be achieved that way. So, including a reauth timer negotiation to make re-authentication happen on a schedule does not help prevent such DoS threats. > > Time based accounting benefits from negotiated refresh period. > It's really up to PAA. If PAA wants to enable this, it can send frequent enough reauths to detect PaC's departure. No need to negotiate. > With multihoming (see issue16) refresh messages can be used to refresh > different "bindings" in one session. Here negotiated interval is needed. > ... >>>> - PAA sends (offered) session-lifetime in PANA-success >>>> message to the PaC. >>>> If PaC wants to lower the session-lifetime, it MAY include a lower >>>> session-lifetime in PANA-success-ack. >>> >>> We need the lower limit too. I guess this could be stated >> in the spec, >>> but the scenarios are different and the network may want to >> use different >>> limits, even dynamically (depending on the signaling load etc.). >> >> Why do we need the lower limits? Do other protocols do that? > > MIPv6 draft uses "Binding Refresh Advice" (sec. 6.2.4) and also the HA finally > makes the decision about the BU lifetime. If I remember correctly in MIPv4 the > MN suggests a lifetime but the network makes final decision. There is no need > for lower limit "advice", because the network decides. > > If we use seconds in the AVP the lower limit is 1s. The network may want to > make it higher to prevent signaling flood with many clients. If we make the > lower limit to 5s, that may be too high or too low. As I have said, limiting this does not prevent DoS. There are other ways to achive the same DoS. I presume you don't have an example of protocols that set lower limits (or, did I miss it?) > >> >>> >>>> >>>> - It's the responsibility of PaC to perform PANA before its >>>> current session >>>> expires. [note: here we are talking about full authentication >>>> where an EAP >>>> method is executed, not re-auth] >>> >>> Yep. We have two authentications: local refresh, and EAP re-auth. >> >> No, this is exactly what I'm trying to clarify. What you >> refer to as "local >> refresh" is done by using PANA-reauuth-req/ans. This should >> have nothing to >> do with Session-lifetime. PaC and PAA can do this as often as >> they need to. > > That's right. But PaC and PAA need to co-ordinate the refresh period (see > comments above). > >> >> On the other hand, PANA-auth (that carries EAP) needs to be >> done before >> Session lifetime exprires. This is what I'mm talking about in here. > > Yep, but the issue8 was all about refresh interval negotiation. Session > lifetime negotiation is a different issue. Anyway, it's good that it's solved. OK, at least you don't have objection to the way session lifetime is handled. Now we are only talking about reauth timers. I don't see why PaC and PAA needs to coordinate when they send their re-auth requests (as I explained above). PaC and PAA might have different reasons to send this request. For example, PaC might use this to test if it is still connected to the same PAA (and not to a malicious PAA). PAA might use this to detect if PaC has departed the network (before session lifetime expires). Both sides sending the requests independent of each other does not cause problems. As for using this coordination for preventing DoS, I don't think this buys you much either. Since I don't see its utility, for the sake of keeping the protocol simple, I vote for not having this negotiation facility built into the protocol. But, I clearly see the need to add more text into the draft explaining what reauth is (and what it is not). And some guidelines on what it can be used for. Alper From pana-request@research.telcordia.com Wed Jun 25 03:29:24 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03928 for ; Wed, 25 Jun 2003 03:29:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5P7Ouf3022848; Wed, 25 Jun 2003 03:24:56 -0400 (EDT) Resent-Date: Wed, 25 Jun 2003 03:24:56 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: Issue 8 Date: Wed, 25 Jun 2003 10:21:05 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcM6xJ6N3raFO9s1R6+TtSP2ILN+/QAIJYZQ From: To: , X-OriginalArrivalTime: 25 Jun 2003 07:21:05.0906 (UTC) FILETIME=[575E4520:01C33AEA] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, Couple of comments once more. I agree that the DoS attack=20 scenario is not too important. We have here two issues:=20 grace period information and refresh period negotiation. > >> Network does not have to inform the PaC about the grace > >> period. It does not > >> even have to have a grace period. It's just a courtesy to > >> have one. Do you > >> have examples of other similar protocols carrying grace > >> period in addition > >> to authorized lifetime to their clients? > >=20 > > Session-Lifetime, Auth-Grace-Period, and=20 > Authorization-Lifetime AVPs are all > > used in the Diameter base protocol. The AAA home server=20 > decides the lifetimes. >=20 > Are they transmitted to the peer in 802.1X, PPP, or Mobile=20 > IPv4? That's my > question. I'm trying to understand what should be carried in=20 > PANA. Your > above example is about what gets carried in backend AAA protocol. EAP goes through the AAA backend, which uses grace period.=20 If PANA now thinks that for example one second is enough=20 to start re-auth before session timeout, it in practice may=20 not be enough (network lag, packet loss, clock difference).=20 Since AAA backend uses grace period and assumes that re-auth=20 is received in that period, it tears down the session when=20 timeout occurs. =20 > >>> Is it PaC's or PAA's responsibility to do reauth? > >>=20 > >> Any can do. It's up to the entity. If PAA believes it=20 > needs to perform > >> re-auth, it can do so. Same for PaC. The signaling can be > >> initiated from any > >> direction, and the other end has to respond when it receives > >> a request. > >> That's why I don't think PaC and PAA need to coordinate > >> anything on this. > >=20 > > When does PaC or PAA know when to do reauth if they don't=20 > negotiate it? >=20 > This is a local decision. Nothing that requires other peer's=20 > collaboration, > right?=20 Collaboration is needed, see below. =20 > > In=20 > > MIPv6 for example the HA sends optionally a Binding Refresh=20 > Advice for the MN > > (draft23, sec. 6.2.4). We could take similar approach in PANA. Refresh period negotiation=20 can be optional. > > Time based accounting benefits from negotiated refresh period. > >=20 >=20 > It's really up to PAA. If PAA wants to enable this, it can=20 > send frequent > enough reauths to detect PaC's departure. No need to negotiate. The link between PaC and PAA may go down or/and packets may get=20 lost. If there is no negotiation about the refresh period, but=20 PAA is doing perioidic re-auths, the states in PaC and PAA may=20 become different. PaC thinks that the session is still alive, but=20 the PAA has torn it down, because there was no answer from PaC to=20 the re-auth request. Don't you think this is serious enough? > > With multihoming (see issue16) refresh messages can be used=20 > to refresh > > different "bindings" in one session. Here negotiated=20 > interval is needed. > >=20 >=20 > ... The same logic here than above. >=20 > >>>> - PAA sends (offered) session-lifetime in PANA-success > >>>> message to the PaC. > >>>> If PaC wants to lower the session-lifetime, it MAY=20 > include a lower > >>>> session-lifetime in PANA-success-ack. > >>>=20 > >>> We need the lower limit too. I guess this could be stated > >> in the spec, > >>> but the scenarios are different and the network may want to > >> use different > >>> limits, even dynamically (depending on the signaling load etc.). > >>=20 > >> Why do we need the lower limits? Do other protocols do that? > >=20 > > MIPv6 draft uses "Binding Refresh Advice" (sec. 6.2.4) and=20 > also the HA finally > > makes the decision about the BU lifetime. If I remember=20 > correctly in MIPv4 the > > MN suggests a lifetime but the network makes final=20 > decision. There is no need > > for lower limit "advice", because the network decides. > >=20 > > If we use seconds in the AVP the lower limit is 1s. The=20 > network may want to > > make it higher to prevent signaling flood with many=20 > clients. If we make the > > lower limit to 5s, that may be too high or too low. >=20 > As I have said, limiting this does not prevent DoS. There are=20 > other ways to > achive the same DoS. I presume you don't have an example of=20 > protocols that > set lower limits (or, did I miss it?) Nothing comes to my mind now, because the network usually makes=20 the final decision. Do you have examples of relevant protocols=20 that let the client make the final decision for lifetime or refresh=20 period (without letting the other end know about it)? >=20 > >=20 > >>=20 > >>>=20 > >>>>=20 > >>>> - It's the responsibility of PaC to perform PANA before its > >>>> current session > >>>> expires. [note: here we are talking about full authentication > >>>> where an EAP > >>>> method is executed, not re-auth] > >>>=20 > >>> Yep. We have two authentications: local refresh, and EAP re-auth. > >>=20 > >> No, this is exactly what I'm trying to clarify. What you > >> refer to as "local > >> refresh" is done by using PANA-reauuth-req/ans. This should > >> have nothing to > >> do with Session-lifetime. PaC and PAA can do this as often as > >> they need to. > >=20 > > That's right. But PaC and PAA need to co-ordinate the=20 > refresh period (see > > comments above). > >=20 > >>=20 > >> On the other hand, PANA-auth (that carries EAP) needs to be > >> done before > >> Session lifetime exprires. This is what I'mm talking about in here. > >=20 > > Yep, but the issue8 was all about refresh interval=20 > negotiation. Session > > lifetime negotiation is a different issue. Anyway, it's=20 > good that it's solved. >=20 > OK, at least you don't have objection to the way session lifetime is > handled.=20 Yep. But some kind of co-operation is needed here when AAA backend=20 Session-Timeout is used (see explanation above). Grace-period is there=20 already, which makes it a natural choice to use (optional AVP perhaps)? PAA could decrease the Session-Timeout value with the amount of grace=20 period and PaC could start re-auth (full) after Session-Timeout? In this case PaC doesn't know how long the session will still remaain valid,=20 because it doesn't know the grace period. >=20 > Now we are only talking about reauth timers. I don't see why=20 > PaC and PAA > needs to coordinate when they send their re-auth requests (as=20 > I explained > above). PaC and PAA might have different reasons to send this=20 > request. For > example, PaC might use this to test if it is still connected=20 > to the same PAA > (and not to a malicious PAA). PAA might use this to detect if PaC has > departed the network (before session lifetime expires). Both=20 > sides sending > the requests independent of each other does not cause=20 > problems. As for using > this coordination for preventing DoS, I don't think this buys you much > either.=20 The problem is that state in PaC and PAA may loose synchronization.=20 See the scenario above. > Since I don't see its utility, for the sake of keeping the=20 > protocol simple, > I vote for not having this negotiation facility built into=20 > the protocol. We need somehow to handle the problem. - Dan > But, I clearly see the need to add more text into the draft=20 > explaining what > reauth is (and what it is not). And some guidelines on what=20 > it can be used > for.=20 >=20 > Alper >=20 From pana-request@research.telcordia.com Thu Jun 26 03:28:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11016 for ; Thu, 26 Jun 2003 03:26:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5Q7M4qk006931; Thu, 26 Jun 2003 03:22:04 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 03:22:04 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 26 Jun 2003 00:23:02 -0700 Subject: Re: Issue 8 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, >>>> Network does not have to inform the PaC about the grace >>>> period. It does not >>>> even have to have a grace period. It's just a courtesy to >>>> have one. Do you >>>> have examples of other similar protocols carrying grace >>>> period in addition >>>> to authorized lifetime to their clients? >>> >>> Session-Lifetime, Auth-Grace-Period, and >> Authorization-Lifetime AVPs are all >>> used in the Diameter base protocol. The AAA home server >> decides the lifetimes. >> >> Are they transmitted to the peer in 802.1X, PPP, or Mobile >> IPv4? That's my >> question. I'm trying to understand what should be carried in >> PANA. Your >> above example is about what gets carried in backend AAA protocol. > > EAP goes through the AAA backend, which uses grace period. > If PANA now thinks that for example one second is enough > to start re-auth before session timeout, it in practice may > not be enough (network lag, packet loss, clock difference). > Since AAA backend uses grace period and assumes that re-auth > is received in that period, it tears down the session when > timeout occurs. This doesn't really answer my question. As far as I know, these protocols would transmit (at most) one timer to the client (peer, MN, etc), that's the granted session lifetime. ... >> It's really up to PAA. If PAA wants to enable this, it can >> send frequent >> enough reauths to detect PaC's departure. No need to negotiate. > > The link between PaC and PAA may go down or/and packets may get > lost. If there is no negotiation about the refresh period, but > PAA is doing perioidic re-auths, the states in PaC and PAA may > become different. PaC thinks that the session is still alive, but > the PAA has torn it down, because there was no answer from PaC to > the re-auth request. Don't you think this is serious enough? If there is such a condition where PaC cannot respond to re-auth (connectivity problem), this condition will of course result in PaC getting kicked out of the network. The PaC knowing when it will be asked to reauth is not going to help. So, again, I don't see the need to negotiate the reauth timers. What we really need to do is to put lots of warnings in the spec saying that false alarms might cause disconnection of live clients. This is what we discussed earlier regarding keep-alives. If PAA is going to use reauth message as a keep-alive mechanism, it must be very careful. ... >> As I have said, limiting this does not prevent DoS. There are >> other ways to >> achive the same DoS. I presume you don't have an example of >> protocols that >> set lower limits (or, did I miss it?) > > Nothing comes to my mind now, because the network usually makes > the final decision. Do you have examples of relevant protocols > that let the client make the final decision for lifetime or refresh > period (without letting the other end know about it)? Lets not confuse when reauths are sent with PANA session lifetime. Latter is handled the way you describe. PAA rules. We are talking about when reauth can be sent, which can be left to PAA and PaC. [for clarification: PANA session lifetime is granted by the PAA (or, AAA backend). PaC must to perform full EAP exchange (PANA-auth) before current PANA session lifetime expires. Within this lifetime, PaC and PAA may initiate PANA-reauth whenever they wish to.] IMO, Re-auth is not the same as the full authentication. It does not have to have all the features of full authentication. It enables the peers to perform a quick test without having to do full authentication. We should not even assume it will always be used periodically. For example, it can be engaged when the peer has a suspicion (hints needed here) that the other end is gone/compromised/etc.... >> OK, at least you don't have objection to the way session lifetime is >> handled. > > Yep. But some kind of co-operation is needed here when AAA backend > Session-Timeout is used (see explanation above). Grace-period is there > already, which makes it a natural choice to use (optional AVP perhaps)? > > PAA could decrease the Session-Timeout value with the amount of grace > period and PaC could start re-auth (full) after Session-Timeout? In this > case PaC doesn't know how long the session will still remaain valid, > because it doesn't know the grace period. I don't quite understand how you use the grace period. To me, it should be used like this: - PAA and PaC agrees on the session lifetime. PaC must initiate full authentication before this session lifetime expires. - PAA might grant a grace period. Grace period is the extension of the sesion lifetime during which PaC is allowed to get authenticated. So, on the PAA side, the effective allowed lifetime is session_lifetime+grace_period. But, on the PaC, it is session_lifetime and PaC think it has to do PANA before this period expires. So, the grace period delivered by AAA must be for the consumption of PAA(or NAS, or AP). Is that not the case? Alper From pana-request@research.telcordia.com Thu Jun 26 04:11:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11730 for ; Thu, 26 Jun 2003 04:11:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5Q88qe5016668; Thu, 26 Jun 2003 04:08:52 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 04:08:52 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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: Issue 8 Date: Thu, 26 Jun 2003 11:08:47 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcM7s51LmrqaQmUXSBKzgQIIG8LwDQAAM5aw From: To: , X-OriginalArrivalTime: 26 Jun 2003 08:08:48.0189 (UTC) FILETIME=[2BD5BED0:01C33BBA] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <91enED.A.GEE.Toq--@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, > >>>> Network does not have to inform the PaC about the grace > >>>> period. It does not > >>>> even have to have a grace period. It's just a courtesy to > >>>> have one. Do you > >>>> have examples of other similar protocols carrying grace > >>>> period in addition > >>>> to authorized lifetime to their clients? > >>>=20 > >>> Session-Lifetime, Auth-Grace-Period, and > >> Authorization-Lifetime AVPs are all > >>> used in the Diameter base protocol. The AAA home server > >> decides the lifetimes. > >>=20 > >> Are they transmitted to the peer in 802.1X, PPP, or Mobile > >> IPv4? That's my > >> question. I'm trying to understand what should be carried in > >> PANA. Your > >> above example is about what gets carried in backend AAA protocol. > >=20 > > EAP goes through the AAA backend, which uses grace period. > > If PANA now thinks that for example one second is enough > > to start re-auth before session timeout, it in practice may > > not be enough (network lag, packet loss, clock difference). > > Since AAA backend uses grace period and assumes that re-auth > > is received in that period, it tears down the session when > > timeout occurs. >=20 > This doesn't really answer my question. As far as I know,=20 > these protocols > would transmit (at most) one timer to the client (peer, MN,=20 > etc), that's the > granted session lifetime. See my comments about grace period below. >=20 > >> It's really up to PAA. If PAA wants to enable this, it can > >> send frequent > >> enough reauths to detect PaC's departure. No need to negotiate. > >=20 > > The link between PaC and PAA may go down or/and packets may get > > lost. If there is no negotiation about the refresh period, but > > PAA is doing perioidic re-auths, the states in PaC and PAA may > > become different. PaC thinks that the session is still alive, but > > the PAA has torn it down, because there was no answer from PaC to > > the re-auth request. Don't you think this is serious enough? >=20 > If there is such a condition where PaC cannot respond to re-auth > (connectivity problem), this condition will of course result=20 > in PaC getting > kicked out of the network. The PaC knowing when it will be=20 > asked to reauth > is not going to help. So, again, I don't see the need to negotiate the > reauth timers. PaC is kicked out by the network, but PaC may not know about it! Even=20 if the L2 looses link at some points (L2 triggers) which causes packet=20 loss from PAA to PaC (re-auth) it doesn't mean that PaC thinks it has=20 been kicked off, because it doesn't know about the refresh period.=20 This is a flaw in the design and we need to resolve it. >=20 > What we really need to do is to put lots of warnings in the=20 > spec saying that > false alarms might cause disconnection of live clients. This=20 > is what we > discussed earlier regarding keep-alives. If PAA is going to use reauth > message as a keep-alive mechanism, it must be very careful. We have to think about PaC's viewpoint too. Anyway, even how many=20 warnings we add to the spec, the scenario doesn't work. >=20 > >> As I have said, limiting this does not prevent DoS. There are > >> other ways to > >> achive the same DoS. I presume you don't have an example of > >> protocols that > >> set lower limits (or, did I miss it?) > >=20 > > Nothing comes to my mind now, because the network usually makes > > the final decision. Do you have examples of relevant protocols > > that let the client make the final decision for lifetime or refresh > > period (without letting the other end know about it)? >=20 > Lets not confuse when reauths are sent with PANA session=20 > lifetime. Latter is > handled the way you describe. PAA rules. We are talking about=20 > when reauth > can be sent, which can be left to PAA and PaC. >=20 > [for clarification: PANA session lifetime is granted by the=20 > PAA (or, AAA > backend). PaC must to perform full EAP exchange (PANA-auth)=20 > before current > PANA session lifetime expires. Within this lifetime, PaC and PAA may > initiate PANA-reauth whenever they wish to.] >=20 > IMO, Re-auth is not the same as the full authentication. It=20 > does not have to > have all the features of full authentication. It enables the peers to > perform a quick test without having to do full=20 > authentication. We should not > even assume it will always be used periodically. For example,=20 > it can be > engaged when the peer has a suspicion (hints needed here)=20 > that the other end > is gone/compromised/etc.... The advantage of re-auth is that full AAA backend involved auth is=20 not needed. If IPSec is in use, re-auth may not be necessary at=20 all. Refresh interval negotiation is needed if refreshes are used. >=20 > >> OK, at least you don't have objection to the way session=20 > lifetime is > >> handled.=20 > >=20 > > Yep. But some kind of co-operation is needed here when AAA backend > > Session-Timeout is used (see explanation above).=20 > Grace-period is there > > already, which makes it a natural choice to use (optional=20 > AVP perhaps)? > >=20 > > PAA could decrease the Session-Timeout value with the=20 > amount of grace > > period and PaC could start re-auth (full) after=20 > Session-Timeout? In this > > case PaC doesn't know how long the session will still remaain valid, > > because it doesn't know the grace period. >=20 > I don't quite understand how you use the grace period. To me,=20 > it should be > used like this: > - PAA and PaC agrees on the session lifetime. PaC must initiate full > authentication before this session lifetime expires. Ok. The term is Session-Timeout in Diameter spec. It may be more=20 descriptive about the nature of the timer.=20 > - PAA might grant a grace period. Grace period is the extension of the > sesion lifetime during which PaC is allowed to get=20 > authenticated. So, on the > PAA side, the effective allowed lifetime is=20 > session_lifetime+grace_period. > But, on the PaC, it is session_lifetime and PaC think it has=20 > to do PANA > before this period expires. The formula once again is (based on the Diameter spec.) authorization_lifetime + grace_period <=3D session_timeout If PAA sends Session-Timeout for PaC, we may get into trouble.=20 But if PAA sends (Session-Timeout - Grace-Period) for PaC, we=20 are more safe. I still think that sending both Session-Timeout=20 and Auth-Grace-Period AVPs is a better solution. Grace period doesn't add anything to the session lifetime. I guess=20 it's a hint from the network for the client to start (full) re-auth *early* enough (implemenations need timners anyway). >=20 > So, the grace period delivered by AAA must be for the=20 > consumption of PAA(or > NAS, or AP). Is that not the case? I guess I don't understand the question. There is no PaCs or=20 MNs in AAA, but AAA clients that are not mobile (NAS, AP, PAA). Summa summarum. I propose that PAA sends Session-Timeout and=20 Auth-Grace-Period AVPs for PaC. For the refresh interval issue,=20 I propose that if refreshes are used PAA informs PaC about the limits of possible refresh intervals (upper and lower). AVP used for this could be for example Refresh-Interval-Limits and the=20 data would contain two 16 bit unsigned integer values for lower=20 and upper limits in seconds. Any comments? Br, - Dan > Alper >=20 >=20 From pana-request@research.telcordia.com Thu Jun 26 12:32:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07692 for ; Thu, 26 Jun 2003 12:31:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5QGO00w007098; Thu, 26 Jun 2003 12:24:00 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 12:24:00 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 26 Jun 2003 09:23:48 -0700 To: Dan.Forsberg@nokia.com Cc: alper@docomolabs-usa.com, pana@research.telcordia.com Subject: Re: Issue 8 Message-ID: <20030626162307.GA10086@steelhead> Mail-Followup-To: Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 236 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Dan, Please see my comments in line. On Thu, Jun 26, 2003 at 11:08:47AM +0300, Dan.Forsberg@nokia.com wrote: > Alper, > > > >>>> Network does not have to inform the PaC about the grace > > >>>> period. It does not > > >>>> even have to have a grace period. It's just a courtesy to > > >>>> have one. Do you > > >>>> have examples of other similar protocols carrying grace > > >>>> period in addition > > >>>> to authorized lifetime to their clients? > > >>> > > >>> Session-Lifetime, Auth-Grace-Period, and > > >> Authorization-Lifetime AVPs are all > > >>> used in the Diameter base protocol. The AAA home server > > >> decides the lifetimes. > > >> > > >> Are they transmitted to the peer in 802.1X, PPP, or Mobile > > >> IPv4? That's my > > >> question. I'm trying to understand what should be carried in > > >> PANA. Your > > >> above example is about what gets carried in backend AAA protocol. > > > > > > EAP goes through the AAA backend, which uses grace period. > > > If PANA now thinks that for example one second is enough > > > to start re-auth before session timeout, it in practice may > > > not be enough (network lag, packet loss, clock difference). > > > Since AAA backend uses grace period and assumes that re-auth > > > is received in that period, it tears down the session when > > > timeout occurs. > > > > This doesn't really answer my question. As far as I know, > > these protocols > > would transmit (at most) one timer to the client (peer, MN, > > etc), that's the > > granted session lifetime. > > See my comments about grace period below. > > > > > >> It's really up to PAA. If PAA wants to enable this, it can > > >> send frequent > > >> enough reauths to detect PaC's departure. No need to negotiate. > > > > > > The link between PaC and PAA may go down or/and packets may get > > > lost. If there is no negotiation about the refresh period, but > > > PAA is doing perioidic re-auths, the states in PaC and PAA may > > > become different. PaC thinks that the session is still alive, but > > > the PAA has torn it down, because there was no answer from PaC to > > > the re-auth request. Don't you think this is serious enough? > > > > If there is such a condition where PaC cannot respond to re-auth > > (connectivity problem), this condition will of course result > > in PaC getting > > kicked out of the network. The PaC knowing when it will be > > asked to reauth > > is not going to help. So, again, I don't see the need to negotiate the > > reauth timers. > > PaC is kicked out by the network, but PaC may not know about it! Even > if the L2 looses link at some points (L2 triggers) which causes packet > loss from PAA to PaC (re-auth) it doesn't mean that PaC thinks it has > been kicked off, because it doesn't know about the refresh period. > > This is a flaw in the design and we need to resolve it. I cannot find a requirement in the PANA requirements draft on PaC and PAA to be synchronized on interval for performing refresh or peer-unreachability detection. So I don't think it a design flaw. If we take a look at other protocol, for example IKEv2, it supports peer-unreachability detection but the initiator and responder does not exchange any interval on it (and I don't find a problem in such a design). > > > > > What we really need to do is to put lots of warnings in the > > spec saying that > > false alarms might cause disconnection of live clients. This > > is what we > > discussed earlier regarding keep-alives. If PAA is going to use reauth > > message as a keep-alive mechanism, it must be very careful. > > We have to think about PaC's viewpoint too. Anyway, even how many > warnings we add to the spec, the scenario doesn't work. > > > > > >> As I have said, limiting this does not prevent DoS. There are > > >> other ways to > > >> achive the same DoS. I presume you don't have an example of > > >> protocols that > > >> set lower limits (or, did I miss it?) > > > > > > Nothing comes to my mind now, because the network usually makes > > > the final decision. Do you have examples of relevant protocols > > > that let the client make the final decision for lifetime or refresh > > > period (without letting the other end know about it)? > > > > Lets not confuse when reauths are sent with PANA session > > lifetime. Latter is > > handled the way you describe. PAA rules. We are talking about > > when reauth > > can be sent, which can be left to PAA and PaC. > > > > [for clarification: PANA session lifetime is granted by the > > PAA (or, AAA > > backend). PaC must to perform full EAP exchange (PANA-auth) > > before current > > PANA session lifetime expires. Within this lifetime, PaC and PAA may > > initiate PANA-reauth whenever they wish to.] > > > > IMO, Re-auth is not the same as the full authentication. It > > does not have to > > have all the features of full authentication. It enables the peers to > > perform a quick test without having to do full > > authentication. We should not > > even assume it will always be used periodically. For example, > > it can be > > engaged when the peer has a suspicion (hints needed here) > > that the other end > > is gone/compromised/etc.... > > The advantage of re-auth is that full AAA backend involved auth is > not needed. If IPSec is in use, re-auth may not be necessary at > all. Refresh interval negotiation is needed if refreshes are used. > > > > > >> OK, at least you don't have objection to the way session > > lifetime is > > >> handled. > > > > > > Yep. But some kind of co-operation is needed here when AAA backend > > > Session-Timeout is used (see explanation above). > > Grace-period is there > > > already, which makes it a natural choice to use (optional > > AVP perhaps)? > > > > > > PAA could decrease the Session-Timeout value with the > > amount of grace > > > period and PaC could start re-auth (full) after > > Session-Timeout? In this > > > case PaC doesn't know how long the session will still remaain valid, > > > because it doesn't know the grace period. > > > > I don't quite understand how you use the grace period. To me, > > it should be > > used like this: > > - PAA and PaC agrees on the session lifetime. PaC must initiate full > > authentication before this session lifetime expires. > > Ok. The term is Session-Timeout in Diameter spec. It may be more > descriptive about the nature of the timer. > > > - PAA might grant a grace period. Grace period is the extension of the > > sesion lifetime during which PaC is allowed to get > > authenticated. So, on the > > PAA side, the effective allowed lifetime is > > session_lifetime+grace_period. > > But, on the PaC, it is session_lifetime and PaC think it has > > to do PANA > > before this period expires. > > The formula once again is (based on the Diameter spec.) > > authorization_lifetime + grace_period <= session_timeout > > If PAA sends Session-Timeout for PaC, we may get into trouble. > But if PAA sends (Session-Timeout - Grace-Period) for PaC, we > are more safe. I still think that sending both Session-Timeout > and Auth-Grace-Period AVPs is a better solution. > > Grace period doesn't add anything to the session lifetime. I guess > it's a hint from the network for the client to start (full) re-auth > *early* enough (implemenations need timners anyway). > > > > > So, the grace period delivered by AAA must be for the > > consumption of PAA(or > > NAS, or AP). Is that not the case? > > I guess I don't understand the question. There is no PaCs or > MNs in AAA, but AAA clients that are not mobile (NAS, AP, PAA). > > Summa summarum. I propose that PAA sends Session-Timeout and > Auth-Grace-Period AVPs for PaC. For the refresh interval issue, > I propose that if refreshes are used PAA informs PaC about the > limits of possible refresh intervals (upper and lower). AVP used > for this could be for example Refresh-Interval-Limits and the > data would contain two 16 bit unsigned integer values for lower > and upper limits in seconds. I think it might be better to study more about other protocols. For example, IEEE 802.1X does not carry an authorization-timeout interval or a grace period. This is because re-authentication due to expiring authorization lifetime is always initiated by the IEEE 802.1X authenticator who knows (through RADIUS/Diameter attributes) when the authorization lifetime expires and what the grace period is. In addition, IEEE 802.1X supplicant can also initiate re-authentication anytime by just initializing its state. IKEv2 is similar to IEEE 802.1X in state management policy, i.e., no interval is negotiated for peer-unreachablity detection or even for SA lifetime. The initiator and responder independently performs peer-unreachablity detection and re-negotiation of SAs whenever needed. In the case of Mobile IP or Mobile IPv6, registration or binding lifetime is negotiated. This is because registration or binding update is always initiated by the mobile node (except for MIPv6 Binding Refresh Request sent by a correspondent node but the purpose seems to be a bit different). On the other hand, a grace period is not negotiated because (I think) the time to complete registration or binding update is predictable. In my opinion, we can design PANA without carrying Session-Timeout or Auth-Grace-Period AVPs, as IEEE 802.1X and IKEv2 are designed so. Yoshihiro Ohba > > Any comments? > > Br, > - Dan > > > > Alper > > > > > > From pana-request@research.telcordia.com Thu Jun 26 16:22:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19867 for ; Thu, 26 Jun 2003 16:21:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5QKHg9e017784; Thu, 26 Jun 2003 16:17:42 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 16:17:42 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 26 Jun 2003 13:18:41 -0700 Subject: Re: Issue 8 From: Alper Yegin To: Yoshihiro Ohba , CC: Message-ID: In-Reply-To: <20030626162307.GA10086@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshi, > In my opinion, we can design PANA without carrying Session-Timeout or > Auth-Grace-Period AVPs, as IEEE 802.1X and IKEv2 are designed so. No objection to not carrying Auth-Grace-Period. But, is giving the responsibility of re-doing PANA to PAA better than distributing it to each PaC? Are there advantages of doing that? [I understand 802.1X and IKE do one way, Mobile IP does other way, but each may have its own reasons...] Alper From pana-request@research.telcordia.com Thu Jun 26 18:38:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25650 for ; Thu, 26 Jun 2003 18:37:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5QMXgG7025164; Thu, 26 Jun 2003 18:33:42 -0400 (EDT) Resent-Date: Thu, 26 Jun 2003 18:33:42 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 26 Jun 2003 15:33:39 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: Issue 8 Message-ID: <20030626223339.GD10086@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <20030626162307.GA10086@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 25 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Jun 26, 2003 at 01:18:41PM -0700, Alper Yegin wrote: > Yoshi, > > > In my opinion, we can design PANA without carrying Session-Timeout or > > Auth-Grace-Period AVPs, as IEEE 802.1X and IKEv2 are designed so. > > No objection to not carrying Auth-Grace-Period. But, is giving the > responsibility of re-doing PANA to PAA better than distributing it to each > PaC? Are there advantages of doing that? [I understand 802.1X and IKE do one > way, Mobile IP does other way, but each may have its own reasons...] One obvious advantage for not carrying any time-related parameter is simplicity. In the case of Mobile IP, the lifetime needs to be carried in signaling message, because the mobile always initiate registration, and such a design seems to be valid for a mobility management protocol, because the home agent basically cannot know by itself when or where a handoff (which will need a binding update) occurs on the mobile. > > Alper > > Yoshihiro Ohba From pana-request@research.telcordia.com Mon Jun 30 11:11:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29996 for ; Mon, 30 Jun 2003 11:10:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h5UEbebY018598; Mon, 30 Jun 2003 10:37:40 -0400 (EDT) Resent-Date: Mon, 30 Jun 2003 10:37:40 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F004B28.5030509@alcatel.fr> Date: Mon, 30 Jun 2003 16:37:28 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: PAA-EP protocol requirements (cont'd) X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/30/2003 16:37:27, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/30/2003 16:37:32, Serialize complete at 06/30/2003 16:37:32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <1h0lND.A.diE.0sEA_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi all, on behalf of the chairs, I come back on the PAA-EP protocol requirements with a short write-up summarizing the requirements which reached consensus until now, at least on the mailing list: 4. PAA-EP Protocol Requirements...................................7 4.1 Push model.................................................7 4.2 Pull model.................................................7 4.3 One-to-many PAA-EP relation................................8 4.4 Inactive peer detection....................................8 4.5 Stateful approach..........................................8 4.6 Recovery...................................................8 4.7 General Security Requirements..............................8 4.8 Accounting/Feedback from the EPs...........................9 4.9 Re-use of an existing protocol.............................9 it also discusses the assumptions and raises some issues about the EP provisioning within the PANA context. the very goal is to identify PANA-specific requirements for this interface in order for the PANA wg to choose the best way to proceed among the available alternatives. the current version is available here (not yet on the IETF repository): http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt please read the draft and provide comments. thanks, yacine