Re: some concerns about last IKEv2 draft

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   >  - in 3.6 Certificate Payload:
   > 
   >       Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of
   >       a PKIX certificate bundle followed by a variable length URL the
   >       resolves to the BER encoded certificate bundle itself. The bundle
   >       is a BER encoded SEQUENCE of certificates and CRLs.
   > 
   >  => this is an underspecified ASN.1 type: some tagging is needed,
   >     for instance by adding:
   >     ", respectively with implicit tags 0 and 1".
   
   While type-specific tagging might make life easier for the parser, it
   is not strictly necessary since it is possible to distinguish between
   certificates and CRL's by the ebedded ASN.1 type information.
   
=> I disagree: certificates and CRLs are SEQUENCEs so tagging is mandatory
(cf ITU-T REC X.680 200207 aka ISO/IEC IS 8824-1 2003, 28.3:
"The Types defined in the "AlternativeTypeList" productions in an
 "AlternativeTypeLists" shall have distinct tags")

   >  - there is nothing about the protection of peer addresses, so IKEv2 can
   >    be used to launch DoS attacks... I still believe the easiest fix is
   >    to make the peer addresses explicit parameters of the IKE SA.
   
   This is not a new issue, and the working group has decided that it is
   not worth worrying about this particular attack.

=> s/has decided/has not shown enough interest/?
And the question is not "has the IETF decided that it is not worth
worrying about this particular attack?" It seems an IETF last call
will be done one day about the IKEv2 document, doesn't it?

   I will note that the
   attack requires that the attacker be on the network path between the
   two communicating peers, and that an attacker in this position has the
   ability to carry out a multitude of attacks that disrupt the
   communication between the two peers, and indeed there are plenty of
   denial of service attacks that do not require being on the network
   path.
   
=> yes, this is not a drastic issue. But this means that IKEv1 should not
be backpatched, not that IKEv2 should be deployed with this flaw.
I am still surprised by the different handling of the same issue by
the mobility (cf. RFC 3519) and IPsec guys...

Thanks

Francis.Dupont@enst-bretagne.fr