Re: A proposal

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

David, I do not think this whole issue is too important or that
people really care, and I am glad that you agree that the xor-based
solution would be an appropriate way to mix the additional key into
the key derivation. Yet I do not really like having the "compound
authentication" to happen (implicitly) at the level of key derivation.

As for your specific responses to the technical objections in my previous
message, let me make some clarification that may help 
dispeling some misunderstandings.

The main point in your response is that the weaknesses I point out are
possible only if one assumes "weaker" prfs than allowed by IKE (v2).
That's wrong. Indeed, I illustrated my attack using a block-cipher based
prf. There is NO cryptographic reason to assume that those are bad prf's,
actually they may turn out to be better than HMAC-SHA1. These prf's are
allowed (and should be allowed) by IKE as IKE remains secure with them.

Moreover, my use of cipher-based prf's in the attack was needed because of
the fortuitous choice made in ikev2 to derive encryption keys before
authentication keys in the KEYMAT derivation. If this specification would
have been made the other way around (first authentication keys, then
encryption keys -- which is btw the ordering to derive the SKa and SKe
keys from SKEYSEED) then your proposal would fail with ANY prf (including
HMAC).

Another objection that I see in your note is:

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

You are absolutely right that your propsal does not disclose SK_d. Yet,
it does not protect the SK_d derivation either. Thus the whole point of
such a propsal is to avoid the MitM from impersonating the user even in
case it obtained SK_d (something that is NOT avoided by introducing
further keying material in the keymat derivation). 
Your proposal does succeed to some extent against full user impersonation
but fails to known-key attacks.

Finally, in response to some of your comments regarding mutual
authentication, let me point out that the attack I described works even if
each of the tunnel and the underlying "legacy" authentication provide
strong mutual authentication. The problem is not with the individual
methods but with its composition.

In all, I do not believe that there was anything unfair about my comments.
Certainly there was no such intention on my part.

Hugo


>

On Mon, 13 Jan 2003, David Jablon wrote:

> Hugo,
> 
> 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.
> 
> -- David
> 
> 
> >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).
> 
> [David writes:]
> 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.
> 
> [David wrote:]
> >> 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)
> >...
> 
> [Hugo wrote:]
> >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.
> 
> 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
> derivation function.
> 
> >... 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
> prf.
> 
> 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)
> >including HMAC.
> 
> 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
> >key derivation.
> 
> 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.
> 
> -- David
>