Subject: [Pana] Unique identifier per session

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 17 Dec 2003 21:02:09 -0800

Hello,

PANA session ID uniquely identifies a session. But, it also does not change
across a reauthentication.
The PANA-IPsec draft needs something unique to identify the pre-shared keys
within a sub-session.
Two possibilities.

1) During re-authentication, change the session ID also in reauth-answer.
2) Invent another ID that changes with every reauth and hence uniquely
identifies the keys derived
    during a reauth.

Any other possibilities ?

-mohan

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Dec 2003 07:03:21 -0800

> identifies the keys derived

I think it does not make sense to change the PANA Session-ID 
across (re-)authentications just for this purpose.

How about using <PANA Session-Id> | <N> as the IKE pre-shared key
identifier, where N is the number of EAP-based re-authentications
occured for the Session-ID?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Dec 2003 07:03:21 -0800

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 18 Dec 2003 15:00:28 -0800

> occured for the Session-ID?
 Can N go out of sync between the PAA and PaC ?
I am assuming that "N" is implicitly and independently arrived by PaC and
PAA.

1) PAA sends a reauth request
2) PaC sends a reauth answer and increments N by 1. This message is lost.
3) PAA retransmits reauth request
4) PaC sends a reauth answer and increments N by 1. This message is
successful.
5) PAA increments N by 1.

As you can see, N is out of sync. Is the above possible ? From what i can
understand
about retransmissions (section 4.1.4 of PANA protocol), the above looks
possible.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 18 Dec 2003 15:00:28 -0800

-mohan

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 27 Dec 2003 16:45:31 +0100

hi all,

an interesting issue with a relationship to the EAP keying work was raised.
i have tried (in this first shot) to write a short text on the EAP keying
issues as they appear in PANA.

this text also includes some discussion parts where further input is
required (denoted as FOR DISCUSSION).

ciao
hannes

-------------

Protocol Communication Overview
-------------------------------------------

This section discusses EAP keying issues and is therefore strongly aligned
with Section 1.3 of [EAP-Keying]. There the entire EAP communication is
separated into three steps. Note that the first step is actually not part of
EAP itself.

- Discovery phase (phase 0)
- EAP authentication, key derivation and transport (phase 1)
- Unicast security association establishment (phase 2)

The discovery phase in PANA has the goal to find the PAA in the visited
network. This step is very hard to secure in a roaming environment. In many
cases an additional security protection at this step would add denial of
service vulnerabilities. However, to prevent very basic denial of service
attacks, whereby an adversary floods the PAA with bogus requests, a cookie
exchange is used. In PANA no capability discovery takes place at phase 0.

Phase 1 is subdivided into two phases: Phase 1a and phase 1b. In phase 1a
the PAA starts sending the initial EAP packet and thereby initiates the
authentication procedure. The PAA might implement some EAP methods or in
many cases not even a single one - it acts as a passthrough device which
interacts with a backend authentication server.

EAP methods might provide key derivation and mutual authentication. PANA
leaves the choice to network architects which EAP methods to mandate. This
is necessary to fullfil the requirements of the larger number of deployment
scenarios. In case of wireless networks without physical or link layer
security the suggestions of [EAP-KEYING] with regard to EAP methods should
be followed. Methods which provide session key establishment and mutual
authentication are mandated.

Since the key derivation takes place between the EAP peer and the EAP server
it is (in many cases) necessary to transport the keying material from the
EAP server to the Authenticator (which corresponds to the PAA in PANA). This
step is referred as phase 1b. If the EAP server and the Authenticator are
co-located then this step is replaced by an API call.

Since PANA signaling messages need protection a PANA SA needs to be
established between the PaC and the PAA whereby new keying material needs to
be derived from the key provided by the EAP method. This step is a slight
deviation from IEEE 802.1X since PANA does not automatically create security
associations for data traffic protection.
With the help of EAP session keys are in place and PANA needs to create,
delete and update the parameters of the PANA SA.

PANA makes a more fine-grain separation in phase 2. Parts of phase 2a are
accomplished within PANA and some parts are delegated towards IKE if IPsec
SA establishment is desired (see [PANA-IPsec]). Phase 2b does not exist in
PANA. We will address the differences in more details in this section.

Figure 1 shows the communication overview. The figure is taken from
[EAP-Keying] and modified accordingly. The "Unicast Secure association
(phase 2a)" is replaced by the abstract term PANA Phase 2 to avoid a
terminology confusion.

   EAP peer/PaC               Authenticator/PAA           Auth. Server
   ------------               -----------------           ------------
      |<----------------------------->|                               |
      |     Discovery (phase 0)       |                               |
      |<----------------------------->|<----------------------------->|
      |   EAP auth (phase 1a)         |  AAA pass-through (optional)  |
      |                               |                               |
      |                               |<----------------------------->|
      |                               |       AAA-Key transport       |
      |                               |      (optional; phase 1b)     |
      |<----------------------------->|                               |
      |  PANA Phase 2                 |                               |
      |                               |                               |
      |<----------------------------->|                               |
      | IKE/IPsec SA establishment    |                               |
      | (optional)                    |                               |
      |                               |                               |

                            Figure 1: Communication Overview

Figure 1 ignores the fact that the Authenticator/PAA can physically be
separated from the Enforcement Point (EP). In this case IKE would not run
between the PaC and the PAA.

Phase 2 is executed after a successful EAP exchange in phase 1 (including
the transport of keying material to the Authenticator).

This phase accomplishes the following tasks (compared with the list
described in Section 1.3 of [EAP-KEYING]):

- Since PANA does not negotiate parameters during the discovery phase it is
not possible to confirm them. No cipher suite negotiation takes place in
PANA.

- PANA securely provides an exchange of parameters and usage modes as part
of the PANA-Bind-Request message (such as Device-Id, Lifetime,
Protection-Cap AVPs).

- PANA does not derive further session keys for protection of data traffic.
If an IPsec has to be established then IKE or IKEv2 is used.

- Mutual key confirmation (PAA to PaC with the help of the PANA-Bind-Request
and PaC to PAA with the help of the PANA-Bind-Answer message) is provided.
This ensure that both, the PaC and the PAA, successfully executed EAP and,
in the case of the PAA, were able to create the necessary keys and parameter
for the PANA SA.

- The PANA SA is active immediately after the PANA SA is established (i.e.,
after the EAP method was successfully executed and session keys are
available).

- PANA also offers a mechanism for terminating access and to delete the
established state with the help of the PANA-Termination-Request and
PANA-Termination-Answer message. Without sending such a message the PAA and
the PaC delete their established state after lifetime expiration.

Security Associations
--------------------------

Several different security associations are created as part of the PANA
exchange. We will describe of them in some level of detail whereby some PANA
specific aspects might lead to discussions.

- EAP SA

First, there is the EAP SA which is described in Section 3.1 of
[EAP-KEYING]. Due to the nature of EAP there are some restrictions on the
EAP SA such as the missing lifetime negotiation, no SA delete operation etc.
Some EAP methods provide enhanced functionality by establishing additional
state which is subject to special optimizations such as "fast resume". A
detailed discussion of these issues is beyond the scope of PANA.

- AAA-Key SA / PANA SA

The AAA-Key SA described in Section 3.2 of [EAP-KEYING] seems to be the
counterpart of the PANA SA. This security association exists between the PaC
and the PAA. The following parameters constitute this AAA-Key SA:

      - the EAP peer name
      - the NAS/authenticator name
      - the AAA-Key
      - the AAA-Key maximum lifetime (if known)
      - the AAA attributes sent in the Access-Accept

The subsequent paragraph is an attempt to map the text in [EAP-KEYING] to
PANA.

For the PANA-SA at the PAA would have the following parameters:
     - AAA attributes (obtained via the Access-Accept)
     - Lifetime (optional?)
     - Key of the PANA SA (derived from the AAA-Key)
     - Socket-Pair information (Src/Dst IP address, Src/Port, UDP protocol)
     - Session ID
The PANA-SA at the PaC contains similar attributes except for the AAA
attributes since they are invisible to the PaC.

The lifetime of the PANA SA is determined by a number of parameters. The
Lifetime AVP transmitted to the PaC is an indication for the PaC about the
time duration granted for network access (and therefore also for the
lifetime of the security association).

The identities used for the PaC and the PAA are less clearly described in
PANA (and also in the EAP context). Some of these issues will be discussed
again in the context of "key naming".

The identity of the NAS (in the IEEE context) or PAA (in PANA) has to be
mapped to attributes in the AAA infrastructure. Hence, within RADIUS the NAS
is identified by the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address
attributes. Although these attributes are kept very flexible it needs to be
ensured that they match to the PANA context.

---

FOR DISCUSSION: Should the PANA SA be bound to a specific PaC <-> PAA? This
is particularly of interest for mobility. It needs to be evaluated whether
the discussion in the EAP keying design team (or within the EAP working
group in general) is an issue here or even in general (e.g., a virtual NAS).

FOR DISCUSSION: Should a new key be derived after the lifetime of the PANA
SA expires (as part of a re-authentication procedure)? This should then
require that the Lifetime AVP is mandatory in order for the PaC to perform
the same computation/protocol action. What protocol interaction is required
for rekeying? It should be noted that the expiration of the PANA SA lifetime
is not necessarily the same as a regular SA expiration. The lifetime refers
more likely to the authorization decision or some other security policy
based aspects of reauthentication interval. A clarification would be
necessary and helpful.

---

- Unicast Secure Association SA / IPsec SA

In [EAP-KEYING] a "unicast secure association SA" seems to be a link layer
specific security association which is used to protect the data traffic
itself. In the PANA context the equivalent would be an IPsec SA. Since PANA
IPsec uses IKE or IKEv2, it would be necessary to consider also the state
established with these protocols.

The content of the "unicast secure association SA" is described as

      - the peer port identifier (Calling-Station-Id)
      - the NAS port identifier (Called-Station-Id)
      - the unicast Transient Session Keys (TSKs)
      - the unicast secure association peer nonce
      - the unicast secure association authenticator nonce
      - the negotiated unicast capabilities and unicast ciphersuite.

For PANA IPsec usage three SAs are of relevance:
- PANA-IKE-SA
- IKE-SA/ISAKMP SA
- IPsec SA

Each of these SAs have different attributes and a different lifetime.

The content of the IPsec SA and the IKE-SA/ISAKMP SA is described in the
relevant IPsec working group documents and will not be repeated here.

The PANA-IKE-SA, which is the state information used as input to the IKE /
IKEv2 exchange, is of interest here. The following information is necessary:

    - the PANA-SA derived key (which is indirectly used as a pre-shared
secret for IKE/IKEv2)
    - the identities of the PaC (IP address) and EP (also IP address) (both
IP addresses are
       made available to both entities during the PANA protocol execution).
    - the Session ID

---

FOR DISCUSSION: A key derived from the PANA SA key should be used as input
to the key derivation function for the IKE preshared secret key and not the
MSK. Mutual key confirmation is provided for the PANA SA key.

---

>From authorization point of view it is necessary to ensure that the IPsec
SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain active after the
PANA context is removed since otherwise network resources could be consumed
without authorization. Since the PaC is able to send a terminate message at
any time there is a need for a good API between the PAA/EP and the IKE/IPsec
daemon.

---

FOR DISCUSSION:
Should a newly derived key for the PANA SA lead to a new key for the
PANA-IKE SA?  My preference is NO. The PaC should, however, be able to
create a new IPsec SA at any time during the lifetime of a PANA SA.
Should the PAA be able to force the PaC to create a new IPsec SA?
Should it be possible to create more than one IPsec SA between the PaC and
the EP at the same time (for example to support different quality of service
classes)?

---

"Key Naming"
------------------

This section discusses aspects of selecting a security associations before
applying protection to signaling messages or to data traffic itself. A new
term ("key naming") was invented to describe this selection of a security
association as part of the work done in the EAP working group.

To avoid confusion with new terms, a possible definition is included here:

Key Naming: "Parameters used to index (= to select, or to point to) a
security association in order to protection the corresponding cryptographic
computation. The computation might be applied for inbound and for outbound
traffic."

As a well-known example, IPsec is used to describe the meaning of key
naming. Not that inbound and outbound processing is different.  For inbound
processing an IPsec SA is selected using the destination IP address, SPI and
protocol type (ESP, AH).
For outbound processing the IPsec SA is selected based on the installed
policies which highly differ from environment to environment. A typical
policy might protect all traffic between a source IP address and a given
destination IP address. The applicable policy then points to the IPsec SA
that has to be applied. In some cases even more than one IPsec SA might be
applied.

>From this example it can easily be seen that key naming has to consider
inbound and outbound processing separately for most protocols.

Section 3.5 of [EAP-KEYING] describes the following key names:

"EAP SA name:
 The EAP security association is uniquely named with <EAP peer name, EAP
server name, EAP Method Type, EAP peer nonce, EAP server nonce>."

Please note that the EAP SA is created as a result of a full EAP protocol
run between the EAP peer and EAP server. It is for further study why an EAP
SA needs to be named.

"AAA-Key Name:
The AAA-Key is named by the concatenation of the EAP SA name, "AAA-Key" and
the authenticator name."

For PANA the key naming of the EAP SA is not of interest here. The
definition of the AAA-Key name sounds like an input for a key derivation
function rather than information to select a security association. The PANA
SA name which should be equivalent to the AAA-Key name is selected as
follows:

Inbound processing:
The PAA is able to select the PANA security association of an incoming
signaling message based on the session identifier.
The PaC is able to select the PANA SA of an incoming signaling message also
based on the session identifier included in the header of the PANA signaling
message.

Note that in both cases it would be possible to use the socket pair for the
same purpose.

Outbound processing:
For outbound processing at the PAA the socket is used to determine where to
send the message. The socket is selected either based on a reply which is
pending or based on information from the AAA infrastructure. State must be
stored to bind a message arriving from the PaC (e.g., an EAP payload in the
PANA-Auth-Answer message) and the EAP message send to the EAP server via the
AAA infrastructure.

TBD: What information elements are used here exactly to provide these
multiplexing capabilities?

For outbound processing at the PaC we have to consider a case where the PaC
is equipped with multiple interfaces and hence has to select the correct
one. At the end a socket is used to select which interface to send the
messages but to deal with IP address changes at the interfaces the Session
Identifier is used to as an intermediate pointer. Furthermore, policies
determine at which interface a message needs to be send in general (e.g.,
reauthentication or an incoming request from the PAA which requires a
response).

-----

FOR DISCUSSION: If the PaC has to run a new re-authentication step then a
new EAP SA is created. As a consequence a new key for the PANA SA is
created. This is at least true for a full EAP protocol run (but it might not
be true for a "fast resume" since the desired properties have not been
described yet).

If two PANA SAs (with overlapping lifetime) exist in parallel then you need
a way to identify which SA to select. Two mechanisms are possible:
- A key version number as in Kerberos which is increased and allows to
select the refer to the latest version of the key. For the purpose of key
naming both values, the session identifier and the key version number, would
be required.
- A new identifier (e.g., SPI) such as in IPsec which itself has no ordering
property. Additionally the lifetime of the security association is required
to determine the most recent one.

Based on this, the following procedure is necessary to see whether
- Is this a problem in PANA itself?
- Is this a problem for PANA-IPsec handling?
- If so, then which approach should be chosen in PANA:
   a) key version number
   b) modification of the identifier (the session identifier in our case);
This could mean that a new session identifier is created once a new key is
available.

-----

For other protocols (such as IKE) rekeying turned out to be complex with a
number of failure cases. For IPsec SAs rekeying considerations are
dealt-with in IKE/IKEv2 itself. PANA, however, needs to make sure that both
views of the world are consistent based on the unreliable channel provided
with UDP (and the various error cases of the different protocols). It should
not be possible to create a protocol sequence whereby the PaC and the PAA
established different state.

Please note that the usage of the session identifier in the PANA protocol is
different from the one in PANA-IPsec handling. The session identifier
shipped to the EP mainly helps to associate the established PANA session
(and therefore the EAP authentication and authorization) to the accounting
mechanisms at the EP.

TBD: What mechanisms are available in IKE to indicate different keys? Take a
look at the PANA IPsec draft. IKE itself does not address different versions
of the pre-shared secret. The API used by IKE/IKEv2 must be able to provide
this functionality.

EAP Keying requirements
-------------------------------

Section 4.2.3 of [EAP-KEYING] lists a few requirements which have to be met
by the protocols using EAP. We will briefly list the requirements and
mention whether we believe that the individual requirement is met. Beyond
the requirements listed below a number of other requirements are discussed
in [EAP-KEYING] which are also relevant for PANA, such as AAA and EAP method
requirements.

- Mutual proof of possession

PANA provides mutual proof of possession (i.e., mutual key confirmation) of
a key derived from the AAA-Key (or more precisely from the MSK which is
transported to the PAA via the AAA infrastructure).

- Key Naming

Every protocol provides mechanisms to select the security associations. PANA
should be/is no different here. A previous section discusses some of the
issues which need to be addressed with regard to key naming and different
versions of the key.

- Creation and Deletion

This requirement mainly addresses the creation and deletion of phase 2
security associations. [EAP-KEYING] tightly binds the successful execution
of phase 2 with security associations for securing the data traffic. This
is, however, not the case in PANA since these are separate protocols. Some
questions have been raised in this context in previous sections. Deletion of
the IPsec SAs MUST be accomplished indirectly with a PANA termination
message.

- Integrity and Replay Protection

Once the EAP exchange is successfully finished PANA signaling messages can
be integrity and replay protected.

- Direct operation

This requirement is highly tight to the IEEE environment where a link layer
security associations are established. Hence the requirement is made that
the protocol must only run between these two entities and not between other
parties.

For PANA this is, however, not the case since the EP might be physically
separated and hence it is required to transfer derived keys to the EP. The
transfer is controlled by the PAA and hence it is not possible by an
unauthorized entity to query the PAA for keys.
Furthermore, the IPsec SA and the IKE-SA/ISAKMP SA is not available to the
PAA itself.

- Derivation of transient session keys

In case of PANA the PANA protocol itself does not establish the IPsec SAs
directly.

- TSK freshness

As mentioned in the previous section PANA itself does not derive unicast
(and multicast) transient session keys. IPsec is responsible for this
purpose and provides these capabilities. IPsec SAs can be reestablished
independently of a PANA protocol.

- Bi-directional operation

This requirement addresses the establishment of uni-directional security
associations for protection of data traffic. Again, this requirement is not
directly applicable to PANA. IKE/IKEv2, however, establishes two separate
uni-lateral security associations.

- Secure capabilities negotiation

PANA does not negotiate capabilities during phase 0. However, some form of
limited capability negotiation takes place secured with the PANA exchange.
Cipher suites are not negotiated in PANA.

References
-------------

[EAP-KEYING]  	B. Aboba, D. Simon, J. Arkko and H. Levkowetz: "EAP Key
Management Framework", <draft-ietf-eap-keying-00.txt>, (work in progress),
October, 2003.

[PANA-IPsec]	M. Parthasarathy: “PANA enabling IPsec based Access Control “,
<draft-ietf-pana-ipsec-00.txt>, (work in progress), October 2003.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 27 Dec 2003 16:45:31 +0100

hi all,

ciao
hannes

-------------

Security Associations

- EAP SA

- AAA-Key SA / PANA SA

      - the EAP peer name

---

---

---

---

---

FOR DISCUSSION:

---

"Key Naming"
------------------

"EAP SA name:

"AAA-Key Name:

Inbound processing:

Outbound processing:

-----

-----

EAP Keying requirements

- Key Naming

- Creation and Deletion

- Direct operation

- TSK freshness

References
-------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Dec 2003 23:24:22 -0800

Hi Mohan,

> 5) PAA increments N by 1.

Which type of "reauth" do you mean?  I am assuming that the IKE
pre-shared key is updated when an EAP-based re-authentication occurs.
When the other type of reauthentication based on
PANA-Reauth-Request/Answer exchange occurs, I don't think the IKE
pre-shared key needs to be updated because there is no change in the
EAP Master Session Key in this case.  For EAP-based re-authentication,
synchronization on EAP Master Session Key derivation can be made
because PANA-Bind-Request that carries an EAP-Success message is
acknowledged with PANA-Bind-Answer message.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 29 Dec 2003 23:24:22 -0800

Hi Mohan,

Yoshihiro Ohba

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 30 Dec 2003 12:47:59 +0100

hi yoshi, 
hi mohan, 

i tried to raise the same question with my text: is it necessary to update
the ike preshared secret with every re-authentication protocol run? 

we have multiple re-authentication procedures here: 

- PANA re-authentication
- EAP full re-authentication (full run between the eap peer and the eap
server)
- EAP 'fast resume'
- EAP run between the eap peer and the local aaa server (based on cached
keys) (in some cases you could draw a relationship between 'fast resume'
here. 

at the discussion in the eap keying design team i was not able to figure out
whether a fast resume actually produces new session keys. 

i would argue to update the PANA SA if an EAP run produces new keys. we have
to discuss how we can handle rekeying (i.e., where multiple PANA SAs are
concurrently active) within PANA at least.

hence, i would strongly argue against executing a new IKE exchange wheneven
you do one of these re-authentication steps. that would certainly hit
performance and is not necessary and even the entrophy argument does not
hold here since you can always create new IPsec SAs based on a quick mode
exchange. 

a few comments on the ability to have multiple IKE pre-shared secrets
currently for IKE protocol runs: 

ike does not support this type of scenario easily. as stated in [ipsec-pana]
in aggressive mode you could use the ID_KEY_ID with the (session id ||
version number) as a key name. this would ensure that you always select the
most recent key and in case of failures it would be possible to fallback to
the previous sa. however, this does not work with ike main mode (pre-shared
secret authentication) since the ID payload is sent after authentication
(with message 5). this already caused problems in road warrior cases. 

from this point of view it would be good to use aggressive mode only (also
from the number of messages). however, the availability of aggressive mode
in existing implementations is not widespread. 

ciao
hannes

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Dienstag, 30. Dezember 2003 08:24
> To: Mohan Parthasarathy
> Cc: Yoshihiro Ohba; [email-masked]
> Subject: Re: [Pana] Unique identifier per session
> 
> 
> Hi Mohan,
> 
> > > > PANA session ID uniquely identifies a session. But, it also does
> not
> > change
> > > > The PANA-IPsec draft needs something unique to identify the
> pre-shared
> > keys
> > > > within a sub-session.
> > > > Two possibilities.
> > > >
> > > I think it does not make sense to change the PANA 
> Session-ID across 
> > > (re-)authentications just for this purpose.
> > >
> > I am assuming that "N" is implicitly and independently 
> arrived by PaC
> and
> > PAA.
> > 
> Which type of "reauth" do you mean?  I am assuming that the 
> IKE pre-shared key is updated when an EAP-based 
> re-authentication occurs. When the other type of 
> reauthentication based on PANA-Reauth-Request/Answer exchange 
> occurs, I don't think the IKE pre-shared key needs to be 
> updated because there is no change in the EAP Master Session 
> Key in this case.  For EAP-based re-authentication, 
> synchronization on EAP Master Session Key derivation can be 
> made because PANA-Bind-Request that carries an EAP-Success 
> message is acknowledged with PANA-Bind-Answer message.
> 
> Yoshihiro Ohba
> 
> 
> 
> > 
> > As you can see, N is out of sync. Is the above possible ? 
> From what i
> can
> > understand

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 30 Dec 2003 12:47:59 +0100

hi yoshi, 
hi mohan, 

- PANA re-authentication

ciao
hannes

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 30 Dec 2003 11:06:46 -0800

pre-shared
> EAP Master Session Key in this case.

Okay.

>  For EAP-based re-authentication,
I am still not clear i guess. When does the PaC increment "N" ? Assume that
PaC increments "N" as soon as it sends the PANA-Bind-Answer message.
Now, if this message is lost. PANA-Bind-Request will be retransmitted by the
PAA. PaC will send the PANA-Bind-Answer message and this time it should
not increment "N" because it is not a new  EAP re-authentication. So,
PaC increments "N" by 1 only for the first PANA-Bind-Answer message sent
as a result of EAP reauthentication. This extra state seems a bit tricky to
me.
And this also assumes that PANA-Bind-Request message will not be used
for anything else in the future.  Is that a safe assumption ?

Carrying extra information in the PANA-Bind-Request information seems less
error prone to me. Perhaps i am missing something ...

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 30 Dec 2003 11:06:46 -0800

pre-shared

Okay.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Dec 2003 00:37:05 -0800

> as a result of EAP reauthentication. This extra state seems a bit tricky to

OK, now I understand your point.  Constructing a key name by using
implicit information might be tricky as you mentioned above.

> error prone to me. Perhaps i am missing something ...

I agree.  Carrying extra information is robuster and I think this also
covers the scenario where EAP-based re-authentication may not always
generate a new MSK (as mentioned by Hannes.)

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 31 Dec 2003 00:37:05 -0800

Yoshihiro Ohba