Re: draft-ietf-ipsec-ikev2-06.txt

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

Charlie, 

This note refers to the following request of yours:

> 
> I have incorporated some of the -05 comments where I thought they would be
> noncontroversial. People who submitted them SHOULD look at the new draft
> and see whether I addressed their concerns adequately. I will continue to
> go through those comments, but it wouldn't hurt if people whose comments
> are not yet addressed forward a copy of them to me to make sure I don't
> miss them.
> 

I have seen that you took care of most of my latest comments -- thanks for
that.

There are a few that were not done even though you expressed in the list
your intention to do them; I suppose these fall under the category of yet
to be done. However, since some of these changes do modify the bits in the
wire I wanted to make sure that you really intend to do them before it is too
late (If for some reason you changed your mind please let us know). 
Here is a list of pending changes (and a couple that I spotted reading 06)

(1) ERASE g^ir as an argument to prf+ in the two places this appears now: 
in section 2.14 (4th line of page 27) and section 2.17 (line 11 of page 29).

As we discussed earlier, g^ir should be used solely for the derivation of
SKEYSEED (for either IKE_SA or CHILD_SA) and need not be re-used in the
derivation of KEYMAT. Doing the latter has no practical advantage while having
the theoretical disadvantage of spoiling a proof of security of the key
derivation based on general pseudo-random functions.

Referring to this issue you said in your note from 3/6:

> Actually, this change was made between -03 and -04. I have only a vague
> recollection as to why. I remember a discussion on the list in early
> December, but don't remember who the advocates for the change were and
> can't find it now. I'm tempted to change it back based on Hugo's objection,
> but would hate to have someone else who doesn't notice this note object in
> -07. Would anyone care to express an opinion? I think everyone agrees that
> the change has no practical impact on security either way.

There were no objections on the list since you posted this so it seems that
you can go forward with this (if not please explain why).  Just to avoid any
confusion: g^ir MUST be kept as an argument to prf (not prf+) in the
computation of SKEYSEED (sections 2.14 and 2.18).


(2) Issue of key length for the prf: Make sure that the users of ikev2
provide enough bits to key the prf. 
This is very simple and requires only the following two editorial changes:

 a- specify that the nonces (Ni and Nr) must be at least of half the length of
    the key for the negotiated prf (since Alice sends this value before
    she knows which prf is chosen by Bob, then she should send a nonce which 
    is of length half the longest prf key that she includes in her offer).

         Note: since you already require the nonces to include at least 
         128 random bits then the above length requirement will usually not 
         result in an actual increase of the length of the nonces.

    Also specify that if a nonce is longer than half the (maximal) length of
    the key accepted by the prf then for creating the key Ni|Nr (used in
    deriving SKEYSEED  for the IKE_SA) only the least significant bytes of
    that nonce are used in this concatenation.

 b- specify that when pre-sharing a key for use in prf-based authentication 
    (i.e., Shared Secret") this key SHOULD of the length of the key for the
    prf agreed for use by the parties. 

        Note: here I would have preferred to say MUST instead of SHOULD, 
	but I know that you want to allow the use of passwords in this mode.

If you intended to do the above changes any way then you can ignore the 
following explanation; if not please read.

Currently you have found a seemingly more "elegant" solution to the prf key
length issue, namely, the following text in page 25 of ikev2-06:

    We assume that the prf
    function takes a variable length key and produces a fixed length
    output. When the key for the prf function has fixed length, its
    specification for use in IKEv2 must include a procedure for deriving
    its required fixed length key from a variable length key.

This may be short and elegant but it actually creates a big problem 
for who wants to use non-HMAC prfs, in particular AES.
Indeed, AES takes fixed keys only and it has no built-in mechanism to handle
variable-length keys.  Designing such a mechanism is a very non-trivial
problem (as those subscribed to the cfrg list have witnessed recently).
Therefore, your text above while seemingly simplifying the IKE specification
actually requires to standarize something (variable key support for AES or
general block ciphers) that can take long to get right technically and even
longer to get ietf consensus. In contrast, the spedifications on the length 
of nonces and preshared key, suggested above, are simple to state, and 
transform the variable key headache into a non-issue.


(3) The specification of AUTH in the case of prf-based authentication
(pre-shared mode). On March 18 you wrote in a message to the list:

> This is also related to prf functions with fixed length keys. I had
> proposed that the AUTH payload be computed as:
> 
> AUTH = prf(Shared Secret | "Key Pad for IKEv2", <message bytes>)
> 
> which won't work if the prf has a fixed size key. Hugo proposed the
> alternative encoding:
> 
> AuthSecret = prf( prf(Shared Secret, "Key Pad for IKEv2") , <message bytes>)
> 
> and using that encoding whether or not the prf takes a fixed size key
> (presumably with Shared Secret padded or truncated as necessary to match
> the fixed key size).
> 
> I'm happy with that. Any objections?

There were no objections on the list so I guess that the current text in draft
06

  AUTH = prf(Shared Secret | "Key Pad for IKEv2", <message octets>) 

is a leftover from previous draft and will be changed to the above nested
construct. (BTW, the above use of "AuthSecret" is a typo, it should be
replaced with "AUTH").
Note that the above construct achieves your intention of avoiding the need
to store passwords at the authentication server, as it allows the server (or
gateway) to only store the result of the inner prf. The current specification
(in 06) achieves the same but ONLY for HMAC. For AES (or other block ciphers)
it puts you back into the "variable-length key issue".  Moreover, having the
key padded with "Key Pad for IKEv2" unnecessarily forces a weakening of the
prf key (this is avoided by having this pad as the input to the prf.

One last nit on this: the inner prf should be prf+ for the cases in which the
output of the prf is shorter than the key (as with 3DES).


Now to purely editorial issues in 06:

(4) It seems to me that you should switch the order between sections 
    2.17 and 2.18.  The reason is that the key derivation for CHILD_SAs
    (currently defined in 2.17) is dependent, in the case of CHILD_SAs 
    created through re-keying, on keys (SK_d) derived during rekey and
    specified in 2.18.

(5) Page 39: at the end of the paragraph

      o  Message ID (4 octets) - Message identifier used to control
          retransmission of lost packets and matching of requests and
          responses. It is essential to the security of the protocol
          because it is used to prevent message replay attacks.

add "during the establishment of CHILD_SA's."

Also, while I am glad that you added this text clarifying the role of message
id's against replay attacks, it seems to me that it does not belong here
(where it is hidden among payload format definitions) but rather in section
2.2 (or even the security considerations if you prefer)

Thanks for your attention...

Hugo