Re: comments on ikev2 05 (editorial)

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

> >
> >       AUTH = prf(Shared Secret, "Key Pad for IKEv2" | <message bytes>)
> 
> I added the following explanatory text:
> 
> The pad string is added so that if the shared secret is derived from a
> password, the IKE implementation need not store the password in cleartext,
> but rather can store a one way transformation of it that could not be used
> as a password equivalent for protocols other than IKEv2.
> 
> Adding the key pad as a prefix to the message bytes does not in general
> give the same security benefit.
> 
> If you still don't understand the goal, I can try to elaborate more. If you
> do understand but think it does not provide the promised benefit, please
> explain.

Yes. I now understand.
However, this is too much of HMAC-centric thinking.
In your above proposal you are assuming an arbitrary key-length prf,
which is not the general case as discussed in realtion to the Ni|Nr
issue (to which I answered separately).

Here, there is a (mathematically) cleaner way to achieve what you want.
Assuming that SharedSecret is suitable as key to a prf, then you can 
define AuthSecret = prf(SharedSecret, "Key Pad for IKEv2")
and AUTH = prf(AuthSecret, <message bytes>).

Note that in this way you make it clear that it suffices to keep the value
AuthSecret in memory (rather than Shared Secret) for authentication
(thus achieveing the password protection you intended)

Hugo