Subject: [eap] Issue 70: Which PRF

From: [email-masked] (Bernard Aboba)
Date: Thu, 23 Jan 2003 04:23:22 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 23, 2003
Document: draft-puthenkulam-eap-binding-01.txt
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

I am not clear whether a requirement for a solution is that it
work with every tunnel encapsulation of EAP. Currently the
draft does say that this is a requirement. I would like to
see the draft discuss the feasibility of a general solution
within the Solution Requirements section.

There are some sticky issues that would arise in attempting to
achieve a general solution. One is that the PRFs vary between
encapsulations. A TLS encapsulation (EAP TTLS, PEAP, POTLS)
will use the TLS PRF; an ISAKMP encapsulation (PIC, IKE) will
use the IKE PRF, etc.

That means that any means of calculating a compound MAC or compound
key that depends on a PRF cannot be completely general, because
the question will arise: which PRF?

The question is whether it can be made "general enough".
One way to do this would be to choose the IKE PRF as the generic one.
However, as I understand the architectural model for a "solution",
it involves having the EAP method export its MSK, and having this
"mixed" (probably via a PRF) with the keying material derived
by the tunnel encapsulation.

Within this model, tunnel encapsulation is effectively "receiving"
an exported EAP MSK, and mixing this internally with its own tunnel
key, so that there is no requirement that the tunnel key
(e.g. TLS master secret) be exported, which in many cases is not
possible or desirable.

Choosing the IKE PRF as the universal compound MAC/compound binding
PRF would imply that this PRF would have to be universally available
to any tunnel encapsulation. I am not clear whether this is a realistic
assumption or not.

If this assumption cannot be made, or if there are other significant
encapsulations with their own PRFs, then a generic EAP solution to
the problem is not possible -- although a framework for a solution
could be put together that could be customized for each usage.

Requested change:

Discuss the issue of "generic" vs. "encapsulation specific" solutions
in the document, as well as the impact of PRF choice. Also talk
about the architectural assumptions regarding key export and import.