A proposal

[David Jablon <[e-mail]>]

Here's what seems to me to be an obviously simple and secure extension.
I'll be glad to hear feedback of where it fits on other people's conceptual
scale from "trivial" to "destroys valuable security properties".

Proposal

 From my reading of www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-03.txt,
optional added key material from supplementary authentication
methods could be bound to the IKEv2 server-only authenticated key
using:

        KEYMAT = prf+(SK_d, [added_key_material] | Ni | Nr, g^ir)

This would extend and replace the existing specification of:

        KEYMAT = prf+(SK_d, Ni | Nr, g^ir)

This fits with IKEv2 with minimal change, and it should not disturb
any security analysis of the current IKEv2 specification.
It is identical to the way that added key material from a secondary
DH exchange is incorporated.

The peers' mutual decision to incorporate added_key_material would
result from the same process by which they agree to use any
optional supplementary authentication method.

Note: This presumes that the design of the method that provides
the added_key_material endorses the concept of exporting it
for session encryption or other such general purposes, especially
from the perspective of protecting any supplementary credentials.
Such analysis is outside the scope of the IKEv2 draft itself,
but should be provided in the definition of the supplementary
authentication method and/or framework.

Rationale

Here's a rationale for proposing this for IKEv2 and either a
suitably-extended SLA or any similar proposal for integrating
client authentication based on legacy credentials.

In a server-only authenticated model, it is far from obvious that a
client user will always do what is necessary to insure that the
client machine first authenticates the identity of the server in
all deployed scenarios.  One can categorize these scenarios, and
create all kinds of hypotheses, but it should be apparent that the
server-only authenticated key model is not as robust as a properly
combined server + client authenticated key model.  At worst, the
server-only authentication model may be prone to mis-use and
a variety of so-called server-spoofing attacks.

The idea of binding key material from separate acts of client and
server authentication is to make key disclosure require the failure
of both client and server authentication, rather than a failure of just
either one independently.  This principle is at least as appropriate
when using legacy credentials as it is when using private keys in
the standard dual-signature model.

A wire protocol specification can only go so far in constraining the
actions of client and server devices, let alone the actions of
the people who use them.  A robust extensible protocol merely
enables these devices to do whatever they can to eliminate
opportunities for user error.  Having IKEv2 able to use added
keying material from legacy credentials gives an implementor
more ability to safeguard the protocol against server-authentication
failures.

While it is true that most protocols, clients, and servers today
that handle legacy credentials provide no added key material,
regardless of the relative proportions of today's installed base,
it would be a shame for a new general framework to unnecessarily
limit itself to supporting only the least robust of available methods.

-- David


At 08:15 AM 12/23/02 -0800, Paul Hoffman / VPNC wrote:
>The same argument goes for IKEv2's authentication. Are you saying that we should change the key derivation for IKEv2 itself to include material from those authentication methods? If so, please suggest text so the cryptographers can analyze it.
>
>The current IKEv2 draft has:
>
>       SKEYSEED = prf(Ni | Nr, g^ir)
>       {SK_d, SK_ai, SK_ar, SK_ei, SK_er}
>                 = prf+ (SKEYSEED, Ni | Nr | CKY-I | CKY-R)
>
>What is your proposal for improving this in a provably secure way?