Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Jari Arkko <jari.arkko@piuha.net> Mon, 18 December 2006 05:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwBWa-0001bI-5T; Mon, 18 Dec 2006 00:58:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwBWY-0001az-Sm for pana@ietf.org; Mon, 18 Dec 2006 00:58:54 -0500
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwBWY-0006dq-5s for pana@ietf.org; Mon, 18 Dec 2006 00:58:54 -0500
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 75388898A6; Mon, 18 Dec 2006 07:58:50 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0F0AA89895; Mon, 18 Dec 2006 07:58:50 +0200 (EET)
Message-ID: <45862E1C.4010900@piuha.net>
Date: Mon, 18 Dec 2006 07:58:52 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.8 (X11/20061117)
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
Subject: Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
References: <0MKoyl-1Gw5Le1Twh-0005Ir@mrelay.perfora.net>
In-Reply-To: <0MKoyl-1Gw5Le1Twh-0005Ir@mrelay.perfora.net>
Content-Type: text/plain; charset="ISO-8859-1"
X-Virus-Scanned: ClamAV using ClamSMTP
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Cc: 'MORAND Lionel RD-CORE-ISS' <lionel.morand@orange-ftgroup.com>, pana@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
Errors-To: pana-bounces@ietf.org
This works for me too. --Jari Alper Yegin kirjoitti: > I think it is best if we didn't get into "L2 point of view security," etc. > I'd like to suggest this re-write instead: > > > In most of the networks, the DHCP exchange that delivers the options prior > to network access authentication is neither integrity protected nor origin > authenticated. Therefore, the options defined in this document MUST NOT be > used to perform any negotiation on the use of PANA between the PaC and a > PAA. For instance, using the presence (or absence) of these DHCP options as > an indication of network mandating PANA authentication (or not) is such a > negotiation. This negotiation would allow bidding down attacks by making the > clients choose to use a lower-grade security mechanism (or even no security > at all). > > Alper > > > >> -----Original Message----- >> From: MORAND Lionel RD-CORE-ISS [mailto:lionel.morand@orange-ftgroup.com] >> Sent: Friday, December 15, 2006 7:53 PM >> To: Jari Arkko >> Cc: Alper Yegin; pana@ietf.org >> Subject: RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt >> >> Hi Jari, >> >> I was assuming that the warning ("MUST NOT") in the introduction was >> enough. >> Anyway, if deemed necessary, I would propose to add the following text in >> the security considerations section: >> >> "PANA is mainly designed for acces networks without underlying >> > security. > >> In such environment, the DHCP exchange that delivers the options is not >> secured from a L2 point of view. Therefore, the options defined in this >> document MUST NOT be used to perform any negotiation on the use of PANA >> between the PaC and a PAA. For instance, presence (or absence) of these >> DHCP options might indicate that the use of PANA would be required (or >> not). However, this would allow bidding down attacks by making the >> clients choose to use a lower-grade security mechanisms (or even no >> security at all)." >> >> Any comment/suggestion will be very welcome! >> >> Lionel >> >> >> >>> -----Message d'origine----- >>> De : Jari Arkko [mailto:jari.arkko@piuha.net] >>> Envoyé : mercredi 13 décembre 2006 11:24 >>> À : MORAND Lionel RD-CORE-ISS >>> Cc : Alper Yegin; pana@ietf.org >>> Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt >>> >>> All of these changes look good, but didn't we also agree to >>> place some text in the Security Considerations section on the >>> bad things that might happen if you did use this for negotiation? >>> >>> --Jari >>> >>> MORAND Lionel RD-CORE-ISS kirjoitti: >>> >>>> Hi Jari, Alper >>>> >>>> According to the presentation made during the last IETF >>>> >>> meeting, here are the proposed changes to include in the next >>> version of the PANA-DHCP document. >>> >>>> Please consider the proposed modifications to make sure >>>> >>> that all the remaining issues are covered. >>> >>>> I will submit a new version of the draft (v05) based on >>>> >>> your feedack. >>> >>>> BR, >>>> >>>> Lionel >>>> >>>> ****************************************************************** >>>> >>>> #1- in the introduction (section 1), at the end of the 3rd >>>> >>> paragraph, revise the text to remove "many" >>> >>>> From: >>>> >>>> "This document specifies DHCPv4 [RFC2131] and DHCPv6 >>>> >>> [RFC3315] options >>> >>>> that allow PANA client (PaC) to discover PANA >>>> >>> Authentication Agents >>> >>>> (PAA). This is one of the many methods for locating PAAs." >>>> >>>> To: >>>> >>>> "This document specifies DHCPv4 [RFC2131] and DHCPv6 >>>> >>> [RFC3315] options >>> >>>> that allow PANA client (PaC) to discover PANA >>>> >>> Authentication Agents >>> >>>> (PAA). This is one of the methods for locating PAAs." >>>> >>>> #2- in the introduction (section 1), extend the existing >>>> >>> section with the following text: >>> >>>> "The DHCP options defined in this document are used only as a PAA >>>> discovery mechanism. These DHCP options MUST NOT be used >>>> >>> to perform >>> >>>> any negotiation on the use of PANA between the PaC and a PAA." >>>> >>>> #3- At the end of the section 4 (DHCPv4 option), revise the >>>> >>> text to clarify the use of the DHCP options: >>> >>>> From: >>>> >>>> "A DHCPv4 client requests the PAA DHCPv4 Option in a >>>> >>> Parameter Request >>> >>>> List as described in [RFC2131] and [RFC2132]. >>>> >>>> The DHCPv4 client MUST try the records in the order >>>> >>> listed in the PAA >>> >>>> DHCPv4 option." >>>> >>>> To: >>>> >>>> "A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a >>>> Parameter Request List as described in [RFC2131] and [RFC2132]. >>>> >>>> If configured with a (list of) PAA address(es), a DHCPv4 >>>> >>> server SHOULD >>> >>>> send a client with the PAA DHCPv4 option, even if this >>>> >>> option is not >>> >>>> explicitly requested by the client. >>>> >>>> A PaC (DHCPv4 client) receiving the PAA DHCPv4 option >>>> >>> SHOULD use the >>> >>>> (list of) IP address(es) to locate PAA. >>>> >>>> The PaC (DHCPv4 client) MUST try the records in the >>>> >>> order listed in >>> >>>> the PAA DHCPv4 option received from the DHCPv4 server." >>>> >>>> #4- At the end of the section 5 (DHCPv6 option), revise the >>>> >>> text to clarify the client/server behavior: >>> >>>> From: >>>> >>>> "A DHCPv6 client requests the PAA DHCPv6 option in an >>>> >>> Options Request >>> >>>> Option (ORO) as described in the DHCPv6 specification [RFC3315]. >>>> >>>> The DHCPv6 client MUST try the records in the order >>>> >>> listed in the PAA >>> >>>> DHCPv6 option." >>>> >>>> To: >>>> >>>> "A PaC (DHCPv6 client) SHOULD request the PAA DHCPv6 option in an >>>> Options Request Option (ORO) as described in the DHCPv6 >>>> >>> specification >>> >>>> [RFC3315]. >>>> >>>> If configured with a (list of) PAA address(es), a DHCPv6 >>>> >>> server SHOULD >>> >>>> send a client with the PAA DHCPv6 option, even if this >>>> >>> option is not >>> >>>> explicitly requested by the client. >>>> >>>> A PaC (DHCPv6 client) receiving the PAA DHCPv6 option >>>> >>> SHOULD use the >>> >>>> (list of) IP address(es) to locate PAA. >>>> >>>> The PaC (DHCPv6 client) MUST try the records in the >>>> >>> order listed in the >>> >>>> PAA DHCPv6 option." >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : Jari Arkko [mailto:jari.arkko@piuha.net] Envoyé : mardi 31 >>>>> octobre 2006 12:22 À : Alper Yegin; MORAND Lionel RD-CORE-ISS Cc : >>>>> pana@ietf.org Objet : Re: [Pana] AD review of >>>>> draft-ietf-dhc-paa-option-04.txt >>>>> >>>>> I am fine with the approach that the option is merely for >>>>> >>> PAA address >>> >>>>> discovery, not affecting whether PANA is on or not. >>>>> But I would like that to be explicitly stated in the document. It >>>>> would also be useful to have a warning that there are >>>>> >>> issues if you >>> >>>>> attempt to do otherwise. >>>>> >>>>> Changes needed to state are likely fairly small. >>>>> If you submit the draft it probably appears when the IETF >>>>> >>> starts and >>> >>>>> I can move the draft along after that. >>>>> >>>>> >>>>>> "A PaC SHOULD request the PAA DHCPv4 Option in a >>>>>> >>> Parameter Request >>> >>>>>> List as described in [RFC2131] and [RFC2132]. >>>>>> If configured with a (list of) PAA address(es), a DHCPv4 >>>>>> >>>>>> >>>>> server SHOULD >>>>> >>>>> >>>>>> send a client with the PAA DHCPv4 option, even if this >>>>>> >>>>>> >>>>> option is not >>>>> >>>>> >>>>>> explicitly requested by the client." >>>>>> >>>>>> >>>>> This is a start. It defines what the nodes do, but I would >>>>> >>> also like >>> >>>>> to see >>>>> >>>>> 1) What the PaC does when it receives the option >>>>> 2) Explanation that the option is not used for turning >>>>> >>> PANA on/off, >>> >>>>> along with the warning >>>>> >>>>> --Jari >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana
- [Pana] AD review of draft-ietf-dhc-paa-option-04.… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS