Subject: [eap] Re: keying framework architectural considerations

From: [email-masked] (Bernard Aboba)
Date: Wed, 23 Jul 2003 08:48:57 -0700 (PDT)

Lauri --

Thank you very much for your message.  My coments and
questions are prefaced by [BA] below.

--------------------------------------------------------------------
(.. 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 SAs should be specified in more detail.

[BA] At present EAP does not negotiate an EAP SA lifetime; in AAA we have
discussed including a lifetime in the Group Keying AVP. The secure
association protocol may or may not negotiate a lifetime. And of course
any of the parties (EAP peer, Authenticator and AAA server) may discard SA
state at any time.

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.

[BA] EAP SAs are the focus of the Keying Framework document, but secure
association (Phase 2) SAs are also discussed. There are also the SAs
created for protection of the AAA protocol.

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.

[BA] Actually I think that the EAP SA semantics are inherited from the
method. The "secure association" protocol only influence the Phase 2
semantics. For example, some methods (e.g. EAP-TLS) can support fast resume and
therefore the EAP SA is presumed to remain beyond the completion of the
authentication. In other methods this might not be the case.

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

[BA] The AAA server isn't a party to the secure association (Phase 2)
protocol, although I suppose it could send some attributes. So I'm not
sure how much leeway the server really has.

The AAA system can send a Key-Lifetime AVP along with the key.
However, this is only advisory even if the authenticator echoes it,
indicating acceptance.  And as you say, this can't be communicated across
EAP so that the EAP peer does not know what the lifetime is.  The result
is that the EAP peer can't make any assumptions about whether the EAP SA
still exists when a future Phase 2 conversation takes place.

Given this, the Key-Lifetime AVP enables the AAA server to influence
but not control key caching.

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

[BA] The way I think of this is that the Phase 2 SA depends on the EAP SA,
but does not modify the semantics of the EAP SA.  This raises the issue of
whether a Phase 2 SA terminates when the Phase 1 SA is deleted.  I don't
necessary think there is a link there;  an AP can continue to use
transient session keys after it has deleted the PMK, but it won't be able
to rerun the 4-way handshake at a later time on that PMK.

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.

[BA] Not sure there is a link here. If the EAP SA is invalidated, it seems
like it is still possible for the Phase 2 SAs to remain valid. It's weird,
though.

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

[BA] Yes, I think there needs to be a binding here.  The AAA server may
send "key context" AVPs along with the key itself.  This can include the
key name, lifetime, etc. These specify properties of the AAA-Key, which is
used in establishing the Phase 2 SA.  If there is any inheritance of Phase
2 from Phase 1, then the inherited "context" needs to be understood.  In
particular, if Phase 2 SA lifetimes can't extend beyond the life of the
Phase 1 SA, then this has to be taken into account.

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