[secdir] SecDir review of draft-yegin-pana-encr-avp-03

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 14 July 2012 21:12 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C513F21F85DF; Sat, 14 Jul 2012 14:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cBpspmcXRD2i; Sat, 14 Jul 2012 14:12:56 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 920CC21F85CE; Sat, 14 Jul 2012 14:12:55 -0700 (PDT)
Received: by wibhm11 with SMTP id hm11so1323123wib.13 for <multiple recipients>; Sat, 14 Jul 2012 14:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PSVeY6pPY6i9l7Il0azc3VEMObMbinpmyO0wLX+KVA4=; b=foQ1gzjc46AA/azJrsOq+zzQgErBZj8LfV24gFDUVTx+0giunKVc6/sytepVzBCivt /jI2Duc6s/nblDetYFgAxUWZ6SiuIFuqoqGalNAC986t4+9Tcu/CChklXepKWRAoek3F uD9Zd3mEiKRTt0YKTpZhaM6a4ZdExQx+rRtbBMRizP6uEuJeG47s773sH3LkVVyO7sHe Z0PQeYOZUQ/c+UtsDe2rk/Cs7ijn+0JYMNpm38Ov5go5oEw6I2TlaUj7b4k5rMbH4pg5 9qdNJvQpupaNk9c51U74hyDNmjhOCk/LjU0grnmWyaeo6X31u0UsrgIgpElK5Zt/K0XO mFeQ==
Received: by with SMTP id ca1mr7165252wib.8.1342300414908; Sat, 14 Jul 2012 14:13:34 -0700 (PDT)
Received: from [] (bzq-79-182-163-254.red.bezeqint.net. []) by mx.google.com with ESMTPS id w7sm11841385wiz.0.2012. (version=SSLv3 cipher=OTHER); Sat, 14 Jul 2012 14:13:34 -0700 (PDT)
Message-ID: <5001E0FA.1070603@gmail.com>
Date: Sun, 15 Jul 2012 00:13:30 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: secdir@ietf.org, draft-yegin-pana-encr-avp.all@tools.ietf.org, iesg@ietf.org
References: <4FBFAE5F.8010305@gmail.com>
In-Reply-To: <4FBFAE5F.8010305@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-yegin-pana-encr-avp-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2012 21:12:57 -0000

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 protocol defines a new AVP that encapsulates multiple PANA AVPs 
within one message, and encrypts them. The encryption key is derived 
from EAP's MSK, and the only encryption algorithm defined is AES128-CTR.


I'm a bit worried about the quality of the proposed cryptographic
solution. While using Counter Mode as the preferred encryption mode is
completely legit, it does require some extra care.


Please note that I am neither a PANA expert nor a cryptographer.

- Sec. 2: I am not clear why MSK is used for deriving the keys, in 
preference to EMSK. I understand that one of the main differences 
between the two is that MSK is possibly shared with an Authenticator 
server (where one exists), but the EMSK is not. It would seem to me that 
a generic confidentiality mechanism should use the key that's shared 
with fewer partners.

- Sec. 2: please clarify whether Encr-Encap can already be used in the 
first message that completes negotiation of the algorithm, i.e. the 
initial PANA-Auth-Answer.

- Sec. 2: according to RFC 5191 (PANA), Sec. 5.4, the AUTH AVP is not 
mandatory (or am I missing something?) It should be made mandatory for 
messages that contain an Encr-Encap (possibly with the exception of 
authenticated encryption algorithms, but none are defined in the current 
document). Emphatically so if Counter Mode is used.

- Sec. 3: I understand why the nonces are used in the derivation. I do 
not understand why the initial messages are used - cryptographic binding 
of message contents is appropriate for authentication 
(integrity-protection) messages, but seems redundant for generation of 
confidentiality keys.

- Sec. 4: Counter Mode is infamous for being extremely sensitive to the 
quality of the IV (a.k.a. "nonce"). So I would expect a random nonce to 
be used for this purpose, rather than the concatenation of 3 protocol 
values. Specifically, what is the likelihood of these parameters 
repeating after a reboot?

- Sec. 4: please explain where the initial 02 octet of the counter block 
comes from.

- Sec. 5: The value of the Encr-Encap AVP is defined as 13 here, but is 
left open in the IANA Considerations.

- Sec. 5: I suppose there is no (block cipher) padding. Please say so 
explicitly. In fact this AVP cannot be generic if neither padding nor IV 
are catered for. In other words, it's good for Counter Mode but for 
little else.

- Sec. 6.1: the Nonce AVPs used for deriving the encryption key 
obviously cannot be encrypted.