Subject: [Pana] NEW: [issue100] PSR and PSA sequence number clarification

From: [email-masked]
Date: Fri, 2 Jul 2004 09:09:47 +0300

New submission from Dan Forsberg <[email-masked]>:

> >- When a PaC sends a PANA-Start-Answer message in response to a valid
> >PANA-Start-Request message without a Cookie AVP, the answer message
> >can be lost.  The PANA-Start-Request would be retransmitted.  To deal
> >with the case, it might be better for the PaC to return a duplicate
> >PANA-Start-Answer message after the PaC has been sent the first
> >PANA-Start-Answer message until the PaC receives a valid
> >PANA-Auth-Request message.
> >  
> >
> In this case, I guess PANA-Start-Request would be retransmitted by
> updating transmission sequence number , and PANA-Start-Request by
> udpating transmission and received sequence numbers). That is:
> 
> PaC PAA
> 
> PSR(x,0)
> <---------------------
> PSA(y,x)
> ---------X--------->
> PSR(x+1,0)
> <-------------------
> PSA(y+1,x+1)
> ------------------->
> 
> Am I wrong?

With incrementing the transmission sequence numbers in PSR and PSA
before the two entities complete initial sequence number negotiation,
it is possible to fail to share the same pair of initial sequence
numbers between PaC and PAA.  So sequence numbers should not be
incremented in PSR and PSA.  I think section 4.1.4 should be more
specific on this.

Yoshihiro Ohba

----------
category: Editorial
document: draft-ietf-pana-pana-xx.txt
messages: 337
nosy: dforsber
priority: Should Fix
status: Pending
title: PSR and PSA sequence number clarification
___________________________________________________
PANA Issues <[email-masked]>
<http://danforsberg.info:8080/pana-issues/issue100>
___________________________________________________
_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 05 Jul 2004 13:02:31 -0400

Here is a proposed text.

In section 4.1.4,

change:

"
   The two sequence number fields have the same length of 32 bits and
   appear in PANA header.  tseq starts from initial sequence number
   (ISN) and is monotonically increased by 1. The serial number
   arithmetic defined in [RFC1982] is used for sequence number
   operation. The ISNs are exchanged between PaC and PAA during the
   discovery and initial handshake phase (see Section 4.2). The rules
   that govern the sequence numbers in other phases are described as
   follows.
"

to:

"
   The two sequence number fields have the same length of 32 bits and
   appear in PANA header.  The transmission sequence number starts
   from initial sequence number (ISN) and is monotonically increased
   by 1. The serial number arithmetic defined in [RFC1982] is used for
   sequence number operation. The ISNs are exchanged between PaC and
   PAA during the discovery and initial handshake phase (see Section
   4.2).  The transmission sequence number is never incremented in the
   messages exchanged during discovery and initial handshake phase.
   The rules that govern the sequence numbers in other phases are
   described as follows.
"

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jul 2004 15:24:19 -0700

I'm trying to see if we can solve this problem without creating
exceptions to the sequencing scheme.....

As I understand, relying on the ISNs has an issue when PaC and PAA
retransmit the messages and any one of the last x sequences (n through
n-x+1) might have been accepted by the PAA as the ISN. Right?

Can we solve this problem by carrying Nonce values in PSR and PSA, and
using them with the PANA_MAC_KEY computation instead of ISNs?

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Yoshihiro Ohba
> Sent: Monday, July 05, 2004 10:03 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pana] NEW: [issue100] PSR and PSA sequence number
> clarification
> 
> Here is a proposed text.
> 
> In section 4.1.4,
> 
> change:
> 
> "

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 19:05:37 -0400

Using Nonce values (which can be more than 32-bits) for PANA_MAC_KEY
computation instead of using ISNs (32-bit random values) provides
better randomness and probably a good thing.  This makes tseq in PSR
and PSA incrementable as other PANA messages (except for PDI).

This works for me.  Perhaps the minimum and the maximum lengthes for a
Nonce value might need to be defined.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 13:28:13 -0400

> using them with the PANA_MAC_KEY computation instead of ISNs?

This is proposed text.

-----------------------------------------------
[1] Change the following text in section 4.1.4:

"

"
   The two sequence number fields have the same length of 32 bits and
   appear in PANA header.  tseq starts from initial sequence number
   (ISN) and is monotonically increased by 1.  This rule applies to
   all PANA messages but PANA-PAA-Discover.  The serial number
   arithmetic defined in [RFC1982] is used for sequence number
   operation.  The ISNs are exchanged between PaC and PAA during the
   discovery and initial handshake phase (see Section 4.2).  The rules
   that govern the sequence numbers in other phases are described as
   follows.
"

[2]  In section 4.1.5, change:

"
      *  PANA SA attributes:

         +  AAA-Key

         +  AAA-Key Identifier

         +  PANA_MAC_Key
"

to:

"
      *  PANA SA attributes:

         +  Nonce generated by PaC (PaC_nonce)

         +  Nonce generated by PAA (PAA_nonce)

         +  AAA-Key

         +  AAA-Key Identifier

         +  PANA_MAC_KEY
"

[3] Change the following algorithm in section 4.1.5:

"
      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)
"

to:

"
      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID)
"

[4]  Add the following text in section 4.2:

"
A Nonce AVP MUST be included in PANA-Start-Request and
PANA-Start-Answer messages.
"

(Note: Nonce AVP could be an optional AVP if a PANA SA is not
established, but I think it is simpler and securer to just make it
mandate.)

[5]  Change the following text in section 4.9:

"
   Upon changing its point of attachment, a PaC that wants to quickly
   resume its ongoing PANA session without running EAP MAY send its
   unexpired PANA session identifier in its PANA-Start-Answer message.
   Along with the Session-Id AVP, MAC and Nonce AVPs MUST be included in
   this message.  Nonce AVP carries a randomly chosen value (PaC_Nonce),
   and MAC AVP is computed by using the PANA_MAC_Key shared between the
   PaC and its previous PAA that has an unexpired PANA session with the
   PaC.  This action signals PaC's desire to perform the mobility
   optimization.  In the absence of Session-Id AVP in this message, PANA
   session takes its usual course (i.e., EAP-based authentication is
   performed).
"

"
   Upon changing its point of attachment, a PaC that wants to quickly
   resume its ongoing PANA session without running EAP MAY send its
   unexpired PANA session identifier in its PANA-Start-Answer message.
   Along with the Session-Id AVP, a MAC AVP MUST be included in this
   message.  The MAC AVP is computed by using the PANA_MAC_KEY shared
   between the PaC and its previous PAA that has an unexpired PANA
   session with the PaC.  This action signals PaC's desire to perform
   the mobility optimization.  In the absence of Session-Id AVP in
   this message, PANA session takes its usual course (i.e., EAP-based
   authentication is performed).
"

[6]  Change the following text in section 4.9:

"
   The current PAA and PaC compute the new AAA-Key by using the nonce
   values and the AAA-Key-int.  PAA_Nonce is the randomly chosen value
   that MUST be carried in a Nonce AVP in the PANA-Bind-Request message.

      AAA-Key-new = The first N bits of
                    HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)

"

to:

"
   The current PAA and PaC compute the new AAA-Key by using the nonce
   values and the AAA-Key-int.  

      AAA-Key-new = The first N bits of
                    HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)
"

[7] In section 6.4.3, add Nonce AVP to PANA-Start-Request
as a mandatory AVP.

[8] In sections 6.4.4, change Nonce AVP of PANA-Start-Answer from
optional AVP to mandatory AVP.

[9] In section 6.4.7, remove Nonce AVP from PANA-Bind-Request.

[10] In section 6.6., update AVP occurence table to be consistent with
changes [7], [8] and [9].

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 16 Jul 2004 11:14:14 -0700

Did you keep ISN_* in the PANA session attributes? We don't seem to need
them anymore, so we can remove them.

> PANA-Start-Answer messages.

I agree.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jul 2004 14:47:18 -0400

> them anymore, so we can remove them.

OK, I will remove them.

Yoshihiro Ohba