RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt

["MORAND Lionel RD-CORE-ISS" <lionel.morand at orange-ftgroup.com>]

Thanks for your feedback!
I will submit the new draft version today.

Lionel

> -----Message d'origine-----
> De : Jari Arkko [mailto:jari.arkko at piuha.net] 
> Envoyé : lundi 18 décembre 2006 06:59
> À : Alper Yegin
> Cc : MORAND Lionel RD-CORE-ISS; pana at 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 at orange-ftgroup.com]
> >> Sent: Friday, December 15, 2006 7:53 PM
> >> To: Jari Arkko
> >> Cc: Alper Yegin; pana at 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 at piuha.net] Envoyé : 
> mercredi 13 
> >>> décembre 2006 11:24 À : MORAND Lionel RD-CORE-ISS Cc : 
> Alper Yegin; 
> >>> pana at 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 at piuha.net] Envoyé : mardi 31 
> >>>>> octobre 2006 12:22 À : Alper Yegin; MORAND Lionel 
> RD-CORE-ISS Cc :
> >>>>> pana at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/pana