Re: FW: external mobike-protocol-02 review (technical)(issue 42)

 
>    The data associated with this notification is the SHA-1 
>    hash [FIPS180-2] of the following data:
> 
> ==> this spec is not algorithm-agile. (I can't find the ref
> right now where this is encouraged.)  In this case, maybe it
> doesn't need to be considering the impact (I don't take a
> stance on that) -- but this probably deserves at least brief
> discussion in the security considerations section.

This part is basically copied from IKEv2 NAT detection payloads,
which also use SHA-1 (and IKEv2 spec didn't include any
discussion about this either)....

However, here the situation might actually be slightly different,
since the security implications of NAT_DETECTION_*_IP payloads
and NO_NATS_ALLOWED are different. The simplest solution might
be just to place the IP addresses in this payload (and mandate
comparing them with the IP header)...

Any comments from other on this?

===> The reason IKEv2 NAT detection payloads includes only the hash and
not the actual addresses is to hide the internal addresses. But this is lost with
MOBIKE because the initiator has to include these addresses in 
ADDITIONAL_ADDRESS notification. So, including the hash or real
address in the notification payloads doesn't matter. To be consistent (as we
are using NAT-D payloads from IKEv2), we might as well use the same
hash and also not be algo-agile :-)

-mohan