Subject: Issue 3: PANA SA

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Jun 2003 17:42:45 -0700

This is the initial text for resolution of Issue 3: PANA SA.  So far,
I have not seen a requirement for confidentiality provisioning at PANA
layer and such provisioning is not included in the initial text.

Comments are appreciated.

Yoshihiro Ohba

----------
Detailed description on PANA Security Association (PANA SA)

o When it is created?

A PANA SA is created as an attribute of a PANA session when EAP
authentication succeeds with a creation of a Master Session Key (MSK)
[RFC2284bis].  A PANA SA is not created when the EAP authentication
fails or does not use an EAP authentication method that creates a MSK.
When a new MSK is derived as a result of EAP-based re-authentication,
any key derived from the old MSK MUST be updated to a new one that is
derived from the new MSK.

o When it is removed?

The created PANA SA is deleted when the corresponding PANA session is
deleted.  The lifetime of the PANA SA is the same as the lifetime of
the PANA session for simplicity.

o What information is included in it?

PANA SA attributes as well as PANA session attributes are listed
below:

PANA Session attributes
  - Session-Id
  - Device-Id of PaC
  - Device-Id of PAA
  - Initial tseq of PaC (ISN_pac)
  - Initial tseq of PAA (ISN_paa)
  - Last transmitted tseq value
  - Last received rseq value
  - Last transmitted message payload 
  - Retransmission interval
  - Session lifetime
  - Protection-Capability
  - PANA SA attributes
      + MSK
      + PANA_MAC_Key

o How the PANA_MAC_Key is derived?

PANA_MAC_KEY = 
   the first 128 bits of HMAC_SHA1(MSK, ISN_pac | ISN_paa | SessionID)

The length of MSK MUST be 128-bit or longer.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Jun 2003 03:09:56 -0700

I've added some text to deal with a corner case where two EAP
authentications are used and each produces its own MSK, resulting in
two MSKs.  In this case, binding the PANA SA to one of those MSK might
be sufficient.

I also updated key derivation expression based on the fact that the
default MAC algorithm is HMAC-SHA1 which needs 160-bit key length.
(Issue: do we need to support multiple MAC algorithms?)

Yoshihiro Ohba

-----

o When it is created?

A PANA SA is created as an attribute of a PANA session when EAP
authentication succeeds with a creation of a Master Session Key (MSK)
[RFC2284bis].  A PANA SA is not created when the PANA authentication
fails or no MSK is produced by any EAP authentication method. In the
case where two EAP authentications are performed in a sequence in a
single PANA authentication, it is possible that two MSKs are derived.
If this happens, the PANA SA MUST be bound to the MSK derived from the
first EAP authentication.  When a new MSK is derived as a result of
EAP-based re-authentication, any key derived from the old MSK MUST be
updated to a new one that is derived from the new MSK.

o When it is removed?

PANA Session attributes
  - Session-Id
  - Device-Id of PaC
  - Device-Id of PAA

PANA_MAC_KEY = HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID)

The length of MSK MUST be 160-bit or longer.