Re: [Pana] RE: Proposed changes for algorithm negotiation

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

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