[secdir] Secdir review of draft-ietf-mext-mip6-tls-03

Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 29 February 2012 19:04 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ns4MUAUdEAD42e0uSFvxVjjqfzm9su7MkSXD/cJg+Yro/0/i4oc+8ufrbXJrNH73/jA26h550IPc5QRu+aH1yh04RqrIpssH+C6m8pLi4pnKCGrcSsOblgQQWIfKcp9H; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type;
Message-ID: <4F4E768B.7030302@gondrom.org>
Date: Wed, 29 Feb 2012 19:03:39 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mext-mip6-tls.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------090206010604060406010402"
Subject: [secdir] Secdir review of draft-ietf-mext-mip6-tls-03
Precedence: list

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

[secdir] Secdir review of draft-ietf-mext-mip6-tl… Tobias Gondrom