Subject: [eap] keying framework architectural considerations

From: [email-masked] (Lauri Tarkkala)
Date: Mon, 21 Jul 2003 21:15:11 +0300

(.. this is as a follow-up to a discussion at IETF7 about the
DHCP+PANA+EAP and key mgmt framework presentation...)

I am not submitting this as an issue, as I do not wish to propose
a single concrete solution at this point. At IETF57 Bernard Aboba presented
the keying framework draft, and after a brief discussion it was
agreed that lifetimes of SA's should be specified in more detail.
A view different from the one used in the keying framework document,
however was the "DHCP + EAP + PANA" architecture which was presented,
here two different SA protocols were used, as opposed to one in
the keying framework.

Currently the division into "Phase 0", "Phase 1" and "Phase 2"
and "EAP SA" and "SA protocol" is IMHO ok. The way I think
about it is that (although it is not currently explicitly specified) that
based on current uses of EAP the EAP SA semantics are inherited
from the SA protocol. If the AAA system wishes to impose
some additional semantics, this must be done via the SA protocol
(communicating these across EAP is not possible).

This is in contrast to at least some SA management protocols, where
generally what in the keying framework draft terminology would be "Phase 2"
SA semantics are inherited from "Phase 1" SA. On the other hand, if
an EAP SA inherits it's semantics (e.g. domain of validity, and what
not) from the "SA protocol", there will be an interesting situation
when more than one "SA protocol" is attached to the "EAP SA".

A possible solution is to require that all protocols present
a single set of semantics for EAP SA mgmt to the EAP instance.
In essence this is like having a thin abstraction layer
between EAP and the "SA protocol"-bundle (I couldn't resist ;),
in the case that they are not equivalent.

At least the following properties are required, IMHO:

1) SA validity is propagated from an SA protocol SA instance to all
   other dependent SA protocol SAs and the EAP SA instance.

  -> If a SA protocol thinks that an EAP SA is invalid, then ALL
     SA protocol SAs attached to that EAP SA must immediately be
     invalidated.

2) Each SA protocol must be able to perform the 
   SA protocol SA -> EAP SA association.

3) The EAP instance must be able to perform the "EAP SA" -> "All SA
   protocols" map.

These are pretty obvious, but these require a somewhat integrated
architecture, and then I am not sure whether a
"n * SA protocols + 1 * EAP SA" will benefit so much from the modularity
they might be trying to achieve. The system is especially fragile
int the "EAP SA" -> "SA protocol" and "SA protocol" -> "EAP SA"
maps, if there is a possibility that these associations may
become conflicting, then all bets are pretty much off regarding
any possibility of recovering synch.

Because the SA protocols are dependent upon EAP to generate an SA,
the only SA "management" feature that is valid to use in this
scenario is a "dead-peer detection" style feature in the "SA protocol".

As such, I would impose an additional demand on the keying framework,
particularly key naming.

- All EAP SA's have a unique identity. Call EAP SA's which have the
  same domain and are associated with the same credentials and
  identities as "similar".

- The SA protocol -> EAP SA association can be performed to the extent
  that the correct credentials and correct identities can be determined,
  even if the EAP SA is unavailable.

- There must exist a partial ordering of EAP SAs such that there
  always exists an unambiguous bottom (or top ;) element.
  This EAP SA should determine the "SA protocol SA" to use in
  sending packets, in cases where several candidate SA protocol SAs
  exist. If the choice of SA protocol would be ambiguous, then
  a similar ordering must be used to determine the correct one.
  These orderings must be globally defined.

This hopefully could take care of the signaling "SA protocol SA" ->
"EAP SA" -> "SA protocol SAs". 

If any modularity is required across architectures, the only shared
attribute for SA protocol SA's should be their dependence
on the same EAP SA instance. Especially if the SA protocols are 
different.

Does the WG have any ideas regarding this ? Is this sufficient ?

Lauri

-- 
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/

---

From: [email-masked] (Alper Yegin)
Date: Tue, 22 Jul 2003 20:08:10 -0700

Hello Lauri,

I need to understand couple of things in your message before I can fully
digest it. Please see below...

> here two different SA protocols were used, as opposed to one in

Both DHCP SA and PANA SA are generated from EAP SA. Does the keying
framework document limit the EAP child SA to exactly one?

> when more than one "SA protocol" is attached to the "EAP SA".

Can you give an example to SA protocol in here? My example would be: 802.11i
4-way handshake is the "SA protocol" that turns EAP SA into L2-cipher SA. I
don't see what EAP SA should inherent from the 4-way handshake protocol.

>  other dependent SA protocol SAs and the EAP SA instance.

Based on my example above, I don't understand why L2-cipher SA (is this your
"SA protocol SA"?) should alter EAP SA.

> scenario is a "dead-peer detection" style feature in the "SA protocol".

EAP lower-layer can help here. For example, PANA termination message can
clean-up EAP SA.

> Does the WG have any ideas regarding this ? Is this sufficient ?

Alper