[Pana] RE: Proposed changes for algorithm negotiation

["Alper Yegin" <alper.yegin at yegin.org>]

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


>    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