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
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.
