Last Call Review of draft-ietf-mext-mip6-tls-

Request Review of draft-ietf-mext-mip6-tls
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-02-28
Requested 2012-02-15
Authors Jouni Korhonen, Basavaraj Patil, Hannes Tschofenig, Dirk Kroeselberg
Draft last updated 2012-03-01
Completed reviews Genart Last Call review of -?? by Ben Campbell
Genart Last Call review of -?? by Ben Campbell
Secdir Last Call review of -?? by Tobias Gondrom
Assignment Reviewer Tobias Gondrom 
State Completed
Review review-ietf-mext-mip6-tls-secdir-lc-gondrom-2012-03-01
Review completed: 2012-03-01


I have reviewed this document as part of the
      security directorate's ongoing effort to review all IETF documents
      being processed by the IESG.  These comments were written
      primarily for the benefit of the security area directors. 
      Document editors and WG chairs should treat these comments just
      like any other last call comments.

      This draft of the MEXT WG is experimental and aims at using
      Transport Layer Security-based Mobile IPv6 Security Framework for
      Mobile Node to Home Agent Communication instead of IPSEC. 

      In general this can be feasible 

and the
      security considerations section is relatively extensive,

 however a number of issues come to mind, which can
      be grouped in four areas:

      1. TLS:

      - risk of TLS downgrading (via renegotiation)

      - risk of TLS stripping (by a MitM)

      2. trust and server certificates

- as we saw in websec there are a number
      of risks with the handling/provisoning of certs through CAs.

      In this case the server landscape could be much better controlled
      by the operator, this may be easier here, but still the question

      - as this uses certs for authentication, do we have to look at
      compromised certs / how to update trust-anchors in mobile nodes?

      - do we need to look into cert pinning to sustain trust

3. Cipher Suites (5.6.5. and following):

      the listed cipher suites seem limited and potentially not
      sufficiently secure and agile.

      - why are you not including AES-256 and SHA-2 (512bit)?

      - furthermore due to the list of ciphers it seems the spec is
      lacking algorithm agility, it might be apropriate to use a
      registry or even better refer to an existing registry for cipher

      4. Misc:

      - and on a personal note maybe a stupid question: why do you MUST
      set the sequence number to 0 at the start? 

      Does this 

reduction in the range of
      expected sequence number values possibly open channels for attack,

increase the risk of an attacker
      guessing sequence numbers in the stream?

In general I feel the draft could use the
      improvements in the above four areas, but as it is experimental,
      it may be sufficient. 

      Best regards, Tobias