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

[Jari Arkko <jari.arkko at piuha.net>]

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