RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
"MORAND Lionel RD-CORE-ISS" <lionel.morand@orange-ftgroup.com> Mon, 18 December 2006 08:51 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwEDE-0000XS-QQ; Mon, 18 Dec 2006 03:51:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwEDD-0000XI-LA for pana@ietf.org; Mon, 18 Dec 2006 03:51:07 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwEDC-0005wx-W9 for pana@ietf.org; Mon, 18 Dec 2006 03:51:07 -0500
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 09:50:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
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] AD review of draft-ietf-dhc-paa-option-04.txt
Date: Mon, 18 Dec 2006 09:50:55 +0100
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260427664B@FTRDMEL2.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Thread-Index: AcciaZgY3O/522xFTwOKmdIw3UrwjQAF+xGA
From: MORAND Lionel RD-CORE-ISS <lionel.morand@orange-ftgroup.com>
To: Jari Arkko <jari.arkko@piuha.net>, Alper Yegin <alper.yegin@yegin.org>
X-OriginalArrivalTime: 18 Dec 2006 08:50:56.0268 (UTC) FILETIME=[A1B83CC0:01C72281]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Cc: 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
Thanks for your feedback! I will submit the new draft version today. Lionel > -----Message d'origine----- > De : Jari Arkko [mailto:jari.arkko@piuha.net] > Envoyé : lundi 18 décembre 2006 06:59 > À : Alper Yegin > Cc : MORAND Lionel RD-CORE-ISS; pana@ietf.org > Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt > > 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