Re: A proposal

[Hugo Krawczyk <[e-mail]>]

On Thu, 2 Jan 2003, David Jablon wrote:


> Here's what seems to me to be an obviously simple and secure extension.

Not so simple (due to the need to import a key from the underlying
authentication method to the tunneling protocol).
And definitely not obviously secure.

See below.

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

An obvious weakness of resolving the mitm problem via the key derivation
(rather than by adding an explicit "compund authentication") is that you end
the key exchange protocol without an explicit authentication that binds the
two protocols. But this by itself can be considered as a DoS issue and not a
security bug.

However, your specific proposal introduces weaknesses beyond the DoS
scenario. It is open to "known-key attacks" by the Man-in-the-mittle
attacking the tunneled authentication.

A known key attack is one in which the disclosure of one of the keys
(e.g the authentication key) compromises another key (e.g the encryption
key). Resistance to known key attacks is an important requirement of a
well-designed key exchange protocol, and in particular of any good key
derivation technique associated to the key exchange protocol.

This is just another example of the extreme care one needs to exercise
when designing or proposing changes to cryptographic protocols in general
and to the subtle ikev2-related protocols in particular. 
I agree that on the face of it your proposal SEEMS to follow the same
logic of ikev2 key derivation, but this is actually wrong.

It can be shown (and I sketch this below for those interested in the
details) that an attacker that knows SK_d (which is the case of the mitm
attacker against which your proposal tries to protect) can mount known-key
attacks even WITHOUT knowing the "added-key-material" coming from the
underlying authentication method. 
This is NOT possible in the regular ikev2 scenario where only the legitimate
parties to the exchange know SK_d.

The specific attacks that I can see are not the most practical, yet they
are sufficient to show that one cannot claim (or prove) the compound key
derivation that you propose to be secure in a mathematical sense.

A secure suggestion is to do a second prf+, similar to the one defined 
in ikev2, keyd with key "added-key-material", and then XOR the results of the
two prf+ computations. This however ASSUMES that the key "added-key-material"
was NOT used in any way (not even  to key other cryptographic algorithms) in
the underlying authentication protocol.
And, of course, this still leaves the DoS issue mentioned above due to the
lack of explicit authentication binding during the protocol.

Hugo

PS: for those interested to see how a known-key attack could work against the
above proposal, this can be exemplified as follows. It is a bit involved,
somewhat artificial and it requires patience to be understood, I will only
sketch the idea. Imagine a case in which the keys derived (KEYMAT) in
sla/ikev2 are later used by the responder (server)  to send confidential
information to the iniitator (client), without the latter sending information
back.  This information could be a confidential real-time stream of data or
whatever. In this case, the initiator will never complete its explicit
authentication in the protocol since it will never show to the responder that
it knows KEYMAT. In particular if this client is the mitm against which we
want to protect, this attacker will never have to show that it knows the keys
derived in KEYMAT. So far this may be considered only as a DoS attack on the
server (which is sending information to a fake client, but one that supposedly
cannot decrypt the information).

However, this is not the end of the story. Imagine that the attacker
records all this information and eventually learns the authentication keys
used in the session. (This can be the case if a month later the
authentication key shows up in some logs from that session; note that it
may make sense to log, even wthout secrecy, authentication keys from
expired sessions). Now our mitm attacker can also learn the encryption
keys! How? If we imagine that the prf is a block cipher (eg AES-128 or
 AES-256) then if you look at the prf+ derivation in ikev2 you'll see
that the attacker THAT KNOWS SK_d can compute all keys derived via prf+
if it happens to know the output of a single prf+ stage (Ti), and
 provided that the input to each prf+ stage is no longer than the cipher
block. (All of this is possible with 128-bit blocks and even more
plaussible with 256-bit blocks when no g^ir is involved, in particular 
when running phase 1).

Moreover, it is only the fortitous definition in ikev2 that specifies 
that encryption keys are derived from the first octets of the output of prf+,
and authentication keys from the last octets, that prevents an even easier
attack. Indeed, had the definition been the other way (first derive the the
authentication key, then the encryption key ) an attack as above could have
been mounted with ANY prf (not just block ciphers as described above)
including HMAC.

NONE OF THESE ATTACKS or weaknesses ARE APPLICABLE to (or be blamed on)
IKEv2. They are possible because of the way the key from the underlying
authentication protocol, added_key_material, is involved in the propsed
key derivation.

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