[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A proposal
You've raised a good point about the use of weaker alternative prf
functions in conjunction with my proposal. But the remaining analysis
is either incorrect or misdirected.
All of the other "attacks" or potential weaknesses that you describe are
either directly applicable to IKEv2 or SLA, or do not exist with any of these
proposals, and they certainly do *not* result from my proposal to merely
include optional added key material in KEYMAT.
Furthermore, the one valid point directed at my proposal is *only* valid
when one implements prf with a function that is significantly weaker
than HMAC, which is currently the only specifically described
instantiation in the IKEv2 draft.
If the intent is indeed for IKEv2 to permit use of prf's based on reversible
functions, such as the cipher-based functions you describe, then
something else (like the alternative that you describe) would clearly be
needed to fix the problem, and it may be a good idea in any case.
If the intent is to not permit cipher-based prf's, and perhaps in any case,
it may be a good idea to clarify the required properties of "prf" in the draft.
While many of your comments appear to unfairly criticise the proposal,
I do note that you gracously ignored the extraneous third argument to prf,
a typographical error on my part.
I also note that you have not disputed the main point I was trying to make,
that the act of *properly* blending key material into the KEYMAT
computation does not weaken the security of IKEv2 [+SLA, ...],
all else being equal.
I elaborate on these concerns in the response below.
>On Thu, 2 Jan 2003, David Jablon wrote:
>> Here's what seems to me to be an obviously simple and secure extension.
At 08:40 AM 1/6/03 +0200, Hugo Krawczyk wrote:
>Not so simple (due to the need to import a key from the underlying
>authentication method to the tunneling protocol).
For the record, my proposal, as a refinement of SLA or similar proposals,
does not introduce any new *need* to import a key from an underlying
authentication method. It simply provides a mechanism to make use
of a suitable imported key when desired and available.
>> 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
>> 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)
>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
I see no such "obvious weakness" in resolving the problem via a proper
KEYMAT derivation, either from a security or DoS perspective. In a
general case, one may legitimately argue that explicitly authenticating a
secondary key or credential in the tunnel is not the same as another
hypothetical compound tunneled authentication method that binds the
keys together and then explicitly authenticates the result. That's a fine
academic point, on which I generally agree.
But every authentication protocol that can provide keying material either
provides (or could provide) explicit authentication of that material, or the
legacy credential from which it has been derived. And the intent to
encompass tunneled protocols "as is" implies that explicit authentication
is typically included. In this case, when explicit authentication is included,
and the tunnel is broken, SK_d is compromised by the MITM and direct
binding to SK_d becomes irrelevant.
If, on the other hand, in your use of "compound authentication" you refer
to dual private key based authentication, that hardly seems a reasonable
criticism of how my proposal improves upon or diminishes the prior
IKEv2 + SLA (or similar) proposal. In my proposal, derived keys are still
just as authenticated (or not) by the IKEv2 server authentication steps as
they would be without the added keying material.
To be absolutely clear, I think it's best to compare apples-to-apples.
Consider two cases of using server-only authentication to tunnel a
second authentication method based on legacy client credentials.
Presume that the tunnelled method exports key material.
Case (1) discards this material, while case (2) blends it, properly, into the
computation of KEYMAT. Case (2) should be at least as secure as (1).
>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.
My proposal was made based on prf using HMAC -- the only explicitly
specified prf. Your concern is based on prf being instantiated using a
formerly unspecified method that might be possble in a future extension
to the draft, where HMAC is replaced with a weaker construction.
I don't dispute the legitimacy of your concern, but it is limited to such cases.
>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.
>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.
For the record, the disclosure of SK_d is not the result of my proposal.
It is the result of MITM attack due to failed server-only authentication,
a presumed pre-existing issue with SLA.
>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.
The proper addition of added_key_material into the computation of
KEYMAT does not cause the disclosure of an otherwise undisclosable
KEYMAT. But, you raise an excellent point about proper constructions,
especially since different implementations of "prf" (as specified)
may have very different properties:
>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. ...
I agree that XOR is a better way to bind the keying material, especially
when there is a concern that alternate constructions for prf are allowed,
such as the weaker cipher-based constructions that you describe (below).
I had presumed the use of the specified HMAC, or something at least as
strong, due to its extensive analysis and broad acceptance as a key
>... 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. ...
It's not clear to me what you mean by that statement. Any added key
material will surely be derived in some way from the credentials used
in the underlying protocol. Insuring the security and proper use of the
exported/imported key is clearly the dual responsibility of both
protocols, as I noted in an earlier post.
>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).
Again, that sketch of a DoS issue, however (in)significant, seems to
be based on a false presumption that there is no explicit authentication
within the "tunnel".
>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).
The known-key attack that you've sketched is only relevant for the
case where HMAC is replaced with an alternative weaker construction,
such as AES-nnn.
As the only prf explicity specified in IKEv2 is HMAC, I had presumed that
any suitable key derivation function would have comparable properties.
If the draft is intended to permit the use of weaker prf constructions,
including those that are based on reversible functions, perhaps it should
more clearly specify the required (or non-required) properties of a suitable
To be clear on this point: In light of your comments, the IKEv2 draft
seems well-defined, given the generally accepted definition of a
pseudo-random function. However something stronger than a simple
cipher-based prf may be desired, and in any case, it can't hurt to add
a reference to more clearly define the intent of "prf" to prevent others
from making false assumptions.
>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)
What I think you're thinking of doesn't work against HMAC. But I see no
real point in exploring a non-disclosed "attack as above" that might have
been mounted against some other non-specified proposal.
>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 proposed
I believe I have shown that, for other than the "prf" issue, the concerns
that you've raised are either not a concern at all, not a concern with my
proposal, or are best directed elsewhere.