Subject: Re: [Pana] EAP keying issues and PANA

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jan 2004 15:28:11 -0800

Hello Hannes,

Thank you for this analysis! This is a very useful material for having this
discussion...

Please see my inlined comments below.

> 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

The PANA SA is needed to provide the keys for the so-called phase 2.
While we have this SA, we thought we can also use it for securing the
subsequent PANA exchanges. Though, it is not a requirement that PANA, as a
EAP lower layer, needs this kind of protection.

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

802.1X does not either. It's the 4-way handshake of 802.11i that creates
this SA.

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

I didn't understand why we have "PANA phase 2". Normally PANA should not
"leak into" phase 2. Phase 2 is for IKE (or, in the case of 802.1X-based
systems, 4-way handshake)

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

We don't really deal with "sockets" context in the PANA design. Instead, I
think we can refer to the "device IDs" in here.

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

PANA SA is bound to a PANA session.

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

When the PANA session expires, if the peers are interested in continuing the
"access", another run of EAP is executed inside PANA. This should create a
new EAP SA, hence a new PANA SA.

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

In theory, one might choose to enable L2 ciphering after a successful PANA
authentication. For example, using the newly generated keys with WPA-PSK.
I'm not aware of anyone looking at the details yet though. So, this is
another possibility in addition to enabling IPsec-based access control.

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

So, is this what you are saying:

EAP SA -> PANA SA -> PANA-IKE-SA -> IPsec-SA

Do we need PANA-IKE-SA, or can we skip it?

> 
>   - 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)?

I think this is beyond the scope of PANA design. If PANA provides a shared
secret to PaC and EP for generation of an IPsec SA for access control, then
its job is done. If someone proposes a design for generating multiple IPsec
SAs from a single shared secret for QoS/etc reasons, then they can do so
independent of where the shared secret came from.

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

I'm not sure if there is anything specific to PANA in here. These sound like
general "how to send a UDP packet to peer" issues.

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

I presume you are referring to the fast resume features in "EAP methods"?
>From PANA perspective, whether it is fast resume or not, it will just look
like "running EAP".

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

UDP itself is unreliable, but we have the ack mechanism for the Bind
messages.

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

Can you please elaborate, what kind of differences are you referring to.

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

I didn't understand this one. What exactly are you referring to as "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.

Thanks.

Alper

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jan 2004 15:28:11 -0800

Hello Hannes,

like "running EAP".

Thanks.

Alper

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 24 Jan 2004 17:20:29 +0100

hi alper, 

sorry for the delay. please see my comments inline:

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Dienstag, 13. Jänner 2004 00:28
> To: Tschofenig Hannes
> Cc: [email-masked]
> Subject: Re: [Pana] EAP keying issues and PANA
> 
> 
> Hello Hannes,
> 
> Thank you for this analysis! This is a very useful material 
> for having this discussion...
> 
> > 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
> > 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
> > authentication procedure. The PAA might implement some EAP 
> methods or
> in
> > leaves the choice to network architects which EAP methods 
> to mandate.
> This
> > 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
> > step is referred as phase 1b. If the EAP server and the 
> Authenticator
> are
> The PANA SA is needed to provide the keys for the so-called 
> phase 2. While we have this SA, we thought we can also use it 
> for securing the subsequent PANA exchanges. Though, it is not 
> a requirement that PANA, as a EAP lower layer, needs this 
> kind of protection.

that is true. for some scenarios this pana sa is not needed while for others
it is. 
pana can operate in many different environments. 

> 802.1X does not either. It's the 4-way handshake of 802.11i 
> that creates this SA.

true. the ieee folks have separated these issues into two documents. they,
however, belong together. 

> > PANA makes a more fine-grain separation in phase 2. Parts 
> of phase 2a
> are
> >     |     Discovery (phase 0)       |                       
>         |
> >     |                               |                       
>         |
> >     |                               |       AAA-Key 
> transport       |
> >     |  PANA Phase 2                 |                       
>         |
> >     |                               |                       
>         |
> >     | (optional)                    |                       
>         |
> >     |                               |                       
>         |
> I didn't understand why we have "PANA phase 2". Normally PANA 
> should not "leak into" phase 2. Phase 2 is for IKE (or, in 
> the case of 802.1X-based systems, 4-way handshake)

well, the usage of the EAP derived keys for the pana sa provides key
confirmation once you use the keys for protection of the signaling messages.
hence it is better to use the pana derived keys for the ipsec sa compared to
the pure eap method derived key. 

> > separated from the Enforcement Point (EP). In this case IKE 
> would not
> run
> > - 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
> > This ensure that both, the PaC and the PAA, successfully 
> executed EAP
> and,
> > [EAP-KEYING]. Due to the nature of EAP there are some 
> restrictions on
> the
> > state which is subject to special optimizations such as 
> "fast resume".
> A
> > The subsequent paragraph is an attempt to map the text in 
> [EAP-KEYING]
> to
> > PANA.
> > 
> We don't really deal with "sockets" context in the PANA 
> design. Instead, I think we can refer to the "device IDs" in here.
> 

the term device id is an abstract term. you certainly have to consider a
source and a destination "device id" (ip address, mac address)

> > Lifetime AVP transmitted to the PaC is an indication for 
> the PaC about
> the
> > The identities used for the PaC and the PAA are less 
> clearly described
> in
> > The identity of the NAS (in the IEEE context) or PAA (in 
> PANA) has to
> be
> > attributes. Although these attributes are kept very 
> flexible it needs
> to be
> > FOR DISCUSSION: Should the PANA SA be bound to a specific 
> PaC <-> PAA?
> This
> > group in general) is an issue here or even in general 
> (e.g., a virtual
> NAS).
> 

we need to be more specific. see the key naming issues. 

> 
> > 
> > FOR DISCUSSION: Should a new key be derived after the 
> lifetime of the
> PANA
> When the PANA session expires, if the peers are interested in 
> continuing the "access", another run of EAP is executed 
> inside PANA. This should create a new EAP SA, hence a new PANA SA.

does this lead to a new session identifier?

> In theory, one might choose to enable L2 ciphering after a 
> successful PANA authentication. For example, using the newly 
> generated keys with WPA-PSK. I'm not aware of anyone looking 
> at the details yet though. So, this is another possibility in 
> addition to enabling IPsec-based access control.

true. 

> Do we need PANA-IKE-SA, or can we skip it?

particuly of interest is the relationship between these sas. is it always
one-to-one or one-to-many? and this again depends how we "name" the security
associations and when we change these identifiers. 

> > SA, IKE-SA/ISAKMP-SA and the PANA-IKE-SA does not remain 
> active after
> the
> > Should it be possible to create more than one IPsec SA 
> between the PaC
> and
> I think this is beyond the scope of PANA design. If PANA 
> provides a shared secret to PaC and EP for generation of an 
> IPsec SA for access control, then its job is done. If someone 
> proposes a design for generating multiple IPsec SAs from a 
> single shared secret for QoS/etc reasons, then they can do so 

ok. 

> > applying protection to signaling messages or to data 
> traffic itself. A
> new
> > destination IP address. The applicable policy then points 
> to the IPsec
> SA
> > function rather than information to select a security 
> association. The
> PANA
> > signaling message based on the session identifier. The PaC 
> is able to 
> > select the PANA SA of an incoming signaling message
> also
> > send the message. The socket is selected either based on a 
> reply which
> is
> I'm not sure if there is anything specific to PANA in here. 
> These sound like general "how to send a UDP packet to peer" issues.

i think there is. you might want to take a look at my previous comments. 
> I presume you are referring to the fast resume features in 
> "EAP methods"? From PANA perspective, whether it is fast 
> resume or not, it will just look like "running EAP".

in some sense you are right. i am, however, not sure whether an eap method
fast resume aims to provide new session keys. 

> 
> > 
> > If two PANA SAs (with overlapping lifetime) exist in 
> parallel then you
> need
> > 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.
> > dealt-with in IKE/IKEv2 itself. PANA, however, needs to 
> make sure that
> both
> UDP itself is unreliable, but we have the ack mechanism for 
> the Bind messages.
> 
> > not be possible to create a protocol sequence whereby the 
> PaC and the
> PAA

before we had this discussion mohans ipsec document used the session
identifier in a different fashion. he said that he will change it. 

> > TBD: What mechanisms are available in IKE to indicate 
> different keys?
> Take a
> > in [EAP-KEYING] which are also relevant for PANA, such as 
> AAA and EAP
> method
> > requirements.
> > 
> I didn't understand this one. What exactly are you referring 
> to as "separate protocols?"

in pana (if you use ipsec sas) then you can delete an ipsec sa without any
impact for pana. 

> > Once the EAP exchange is successfully finished PANA 
> signaling messages
> can
> > This requirement is highly tight to the IEEE environment 
> where a link
> layer
> > the protocol must only run between these two entities and 
> not between
> other
> > parties.
> > 
> > separated and hence it is required to transfer derived keys 
> to the EP.
> The
> > 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.
> > 
> > In case of PANA the PANA protocol itself does not establish 
> the IPsec
> SAs
> > directly.
> > 
> > - TSK freshness
> > 
> > [EAP-KEYING]      B. Aboba, D. Simon, J. Arkko and H. 
> Levkowetz: "EAP
> Key
> > [PANA-IPsec]    M. Parthasarathy: "PANA enabling IPsec based Access
> Control ",

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 24 Jan 2004 17:20:29 +0100

hi alper, 

> |<----------------------------->|
> >     |                               |       AAA-Key 
> transport       |
> >     |                               |      (optional; phase 
> 1b)     |

true. 

ok. 

ciao
hannes

---

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Jan 2004 16:37:01 -0800

> does this lead to a new session identifier?

I think I should have said "before the PANA session expires", and in that
case I'd answer your question as "the same session identifier is preserved".
It's like extending the lifetime of the ongoing session. If the session
expires on the PAA, I think we can consider it's gone and a new session
identifier will be allocated.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 26 Jan 2004 16:37:01 -0800

Alper