Last Call Review of draft-ietf-mext-mip6-tls-
review-ietf-mext-mip6-tls-secdir-lc-gondrom-2012-03-01-00
| Request | Review of | draft-ietf-mext-mip6-tls |
|---|---|---|
| Requested revision | 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
|
|
| Completed | 2012-03-01 |
review-ietf-mext-mip6-tls-secdir-lc-gondrom-2012-03-01-00
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
remains:
- 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
relationships?
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
suites?
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,
like
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