Re: [Pana] RE: Proposed changes for algorithm negotiation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pana] RE: Proposed changes for algorithm negotiation
This would also work for me.
Jari
Alper Yegin kirjoitti:
> That makes sense to me.
>
> Alper
>
>
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
>> Sent: Tuesday, July 10, 2007 4:21 PM
>> To: Alper Yegin
>> Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; 'Jari Arkko'; 'Sam Hartman';
>> pana at ietf.org
>> Subject: Re: [Pana] RE: Proposed changes for algorithm negotiation
>>
>> On Mon, Jul 09, 2007 at 02:47:38AM +0300, Alper Yegin wrote:
>>
>>> Yoshi,
>>>
>>>
>>>> 5.4. Message Authentication
>>>>
>>>> A PANA message can contain an AUTH AVP for cryptographically
>>>> protecting the message.
>>>>
>>>> When an AUTH AVP is included in the last PANA-Auth-Request and
>>>> PANA-Auth-Answer messages with 'C' (Complete) bit set in the
>>>> authentication and authorization phase, the value field of
>>>> the AUTH AVP is calculated by using the PANA_AUTH_KEY in the
>>>> following way:
>>>>
>>>> AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU,
>>>> I_PAR, I_PAN)
>>>>
>>>> When an AUTH AVP is included in any other PANA message, the value
>>>> field of the AUTH AVP is calculated in the following way:
>>>>
>>>> AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)
>>>>
>>> Not sure which one is better: Having single formula in the spec (good
>>>
>> for a
>>
>>> simpler spec), or not having to repeat the same AVPs at a later message
>>> (good for reducing payload). I'm slightly leaning towards the
>>>
>> former.....
>>
>> If that is the case, how about having I_PAR/I_PAN in the PANA_AUTH_KEY
>> derivation algorithm, and keeping the currently defined AUTH AVP
>> calculation algorithm in pana-pana-17 as it is? I mean:
>>
>> PANA_AUTH_KEY = prf+(MSK, I_PAR|I_PAN|PaC_nonce|PAA_nonce|Key_ID)
>>
>> (SessionID is included in I_PAR and I_PAN.)
>>
>> Yoshihiro Ohba
>>
>>
>>>
>>>> In the above AUTH AVP calculation algorithms, PANA_PDU represents
>>>> the PANA message including the PANA header, with the AUTH AVP value
>>>> field first initialized to 0. I_PAR is the initial
>>>> PANA-Auth-Request message with 'S' (Start) bit set. I_PAN is the
>>>> initial PANA-Auth-Answer message with 'S' (Start) bit set.
>>>>
>>> So that people don't mistakenly take the whole IP packet as the PANA
>>> message, let's say "I_PAR is the initial PANA-Auth-Request message (the
>>>
>> PANA
>>
>>> header and the following PANA AVPs) with 'S' (Start) bit set."
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>> PANA_AUTH_HASH represents the integrity algorithm negotiated during
>>>> the initial PANA-Auth-Request and PANA-Auth-Answer message
>>>> exchange.
>>>> "
>>>>
>>>> [8] Change PAR format in Section 7.2 as follows:
>>>>
>>>> PANA-Auth-Request ::= < PANA-Header: 2, REQ[,STA][,COM] >
>>>> [ EAP-Payload ]
>>>> [ Nonce ]
>>>> * [ PRF-Algorithm ]
>>>> * [ Integrity-Algorithm ]
>>>> [ Result-Code ]
>>>> [ Session-Lifetime ]
>>>> [ Key-Id ]
>>>> * [ AVP ]
>>>> 0*1 < AUTH >
>>>>
>>>> [9] Change PAR format in Section 7.3 as follows:
>>>>
>>>> PANA-Auth-Answer ::= < PANA-Header: 2 [,STA][,COM] >
>>>> [ Nonce ]
>>>> [ EAP-Payload ]
>>>> [ PRF-Algorithm ]
>>>> [ Integrity-Algorithm ]
>>>> [ Key-Id ]
>>>> * [ AVP ]
>>>> 0*1 < AUTH >
>>>>
>>>> [10] Change AVP occurrence table as follows:
>>>>
>>>> The table uses the following symbols:
>>>>
>>>> 0 The AVP MUST NOT be present in the message.
>>>>
>>>> 0-1 Zero or one instance of the AVP MAY be present in the
>>>>
>> message.
>>
>>>> It is considered an error if there are more than one instance
>>>> of the AVP.
>>>>
>>>> 1 One instance of the AVP MUST be present in the message.
>>>>
>>>> 0+ Zero or more instance of the AVP MAY be present in the
>>>>
>> message.
>>
>>>>
>>>> +---------------------------+
>>>> | Message Type |
>>>> +---+---+---+---+---+---+---+
>>>> Attribute Name |PCI|PAR|PAN|PTR|PTA|PNR|PNA|
>>>> ----------------------+---+---+---+---+---+---+---+
>>>> PRF-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
>>>> Integrity-Algorithm | 0 |0+ |0-1| 0 | 0 | 0 | 0 |
>>>> AUTH | 0 |0-1|0-1|0-1|0-1|0-1|0-1|
>>>> EAP-Payload | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
>>>> Key-Id | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
>>>> Nonce | 0 |0-1|0-1| 0 | 0 | 0 | 0 |
>>>> Result-Code | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
>>>> Session-Lifetime | 0 |0-1| 0 | 0 | 0 | 0 | 0 |
>>>> Termination-Cause | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
>>>> ----------------------+---+---+---+---+---+---+---+
>>>>
>>>> Figure 4: AVP Occurrence Table
>>>>
>>>> [11] Remove Section 8.1 (Algorithm AVP) and add the following sections
>>>> instead:
>>>>
>>>> "
>>>> 8.X. Integrity-Algorithm AVP
>>>>
>>>> The PRF-Algorithm AVP (AVP Code X) is used for conveying the the
>>>> integrity algorithm to compute an AUTH AVP. The AVP data is of
>>>> type Unsigned32.
>>>>
>>>> The AVP data contains an IKEv2 Transform ID of Transform Type 3
>>>> [RFC4306] for the integrity algorithm.
>>>>
>>>> All PANA implementations MUST support AUTH_HMAC_SHA1_160 (7)
>>>> [RFC4595].
>>>> "
>>>>
>>>> "
>>>> 8.Y. PRF-Algorithm AVP
>>>>
>>>> The PRF-Algorithm AVP (AVP Code Y) is used for conveying the
>>>> pseudo-random function to derive PANA_AUTH_KEY. The AVP data is of
>>>> type Unsigned32.
>>>>
>>>> The AVP data contains an IKEv2 Transform ID of Transform Type 2
>>>> [RFC4306].
>>>>
>>>> All PANA implementations MUST support PRF_HMAC_SHA1 (2) [RFC2104].
>>>> "
>>>>
>>>> (Note: Unsigned32 is used here instead of Unsigned16 because RFC3588
>>>> does not define Unsigned16 datatype.)
>>>>
>>>> [12] Change Section 8.2:
>>>>
>>>> "
>>>> 8.2. AUTH AVP
>>>>
>>>> The AUTH AVP (AVP Code 2) is used to integrity protect PANA
>>>>
>> messages.
>>
>>>> The AVP data payload contains the Message Authentication Code
>>>>
>> encoded
>>
>>>> in network byte order. The AVP length varies depending on the
>>>> integrity algorithm specified in an Algorithm AVP. The AVP data is
>>>> of type OctetString.
>>>> "
>>>>
>>>> to:
>>>>
>>>> "
>>>> 8.2. AUTH AVP
>>>>
>>>> The AUTH AVP (AVP Code 2) is used to integrity protect PANA
>>>> messages. The AVP data payload contains the Message Authentication
>>>> Code encoded in network byte order. The AVP length varies
>>>> depending on the integrity algorithm negotiated in the initial
>>>> PANA-Auth-Request and PANA-Auth-Answer exchange with 'S' bit set
>>>> using Integrity-Algorithm AVP. The AVP data is of type
>>>> OctetString.
>>>> "
>>>>
>>>> [13] Change the following paragraph of Section 10.3.1:
>>>>
>>>> "
>>>> AVP Code 0 is not used. This document defines the AVP Codes 1-8.
>>>> See Section 8.1 through Section 8.8 for the assignment of the
>>>> namespace in this specification.
>>>> "
>>>>
>>>> to:
>>>>
>>>> "
>>>> AVP Code 0 is not used. This document defines the AVP Codes 1-9.
>>>> See Section 8.1 through Section 8.9 for the assignment of the
>>>> namespace in this specification.
>>>> "
>>>>
>>>> [14] Remove the following paragraph from Section 11.2:
>>>>
>>>> "
>>>> In networks where lower-layers are not secured prior to running
>>>>
>> PANA,
>>
>>>> the capability discovery enabled through inclusion of an Algorithm
>>>> AVP in the initial PANA-Auth-Request message is susceptible to
>>>> spoofing leading to DoS attacks. Therefore, usage of this AVP
>>>>
>> during
>>
>>>> the initial message exchange in such insecure networks is NOT
>>>> RECOMMENDED. The same AVP is delivered with integrity protection
>>>>
>> via
>>
>>>> the last PANA-Auth-Request message upon successful authentication.
>>>> "
>>>>
>>> _______________________________________________
>>> Pana mailing list
>>> Pana at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pana
>>>
>>>
>
>
>
>
_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
