[secdir] secdir review of draft-ietf-krb-wg-camellia-cts-01

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Thu, 27 September 2012 00:25 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80FA21F8602; Wed, 26 Sep 2012 17:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyLOUKDVJwt; Wed, 26 Sep 2012 17:25:01 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77821F8615; Wed, 26 Sep 2012 17:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1138; q=dns/txt; s=iport; t=1348705501; x=1349915101; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MOgeHfy/pbBA5P+v/jERFUGT/lKPVbUmaUcXTantSJA=; b=X0SKY3/wdCsXAtpUuPygDIX2iih9ba1a59XSvn0mDYR8glO9+G8cHn6F IJdsmcDbX3W8JB1HyLtIN+Oc/2Tl1CRtDdKw4YvtrWazu1MVcQjgeR6iD h9wjmSDQzXv5cCUJOWkE4DezYn4b1MrpwidDtbpJrcvCMtr/DkK6tXze0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKSbY1CtJV2c/2dsb2JhbABFvj+BCIInEgEnUQE+QicEATSHY5dYoCiQQWADlWmOQoFpgmeCFw
X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="125706036"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2012 00:25:00 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8R0P0Pr011565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 00:25:00 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 26 Sep 2012 19:25:00 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-krb-wg-camellia-cts.all@tools.ietf.org" <draft-ietf-krb-wg-camellia-cts.all@tools.ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: secdir review of draft-ietf-krb-wg-camellia-cts-01
Thread-Index: AQHNnEaGnyDgSpi90UuEmG8RUqbF8w==
Date: Thu, 27 Sep 2012 00:24:58 +0000
Message-ID: <6BFA95AE-9F90-490B-9C63-8C7C96D2BCF3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.249.65]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004
x-tm-as-result: No--33.359400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DD6F629DE924584A9113FF70655CC877@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] secdir review of draft-ietf-krb-wg-camellia-cts-01
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: Thu, 27 Sep 2012 00:25:02 -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.

The only big  issue I see is that the draft uses a different key derivation than the simplified profile in RFC 3961.   What is the reason for this?  Assuming there is a suitable reason for this I think the draft is ready to go with some minor issues. 

1. I think in section 3 random2key should be random-to-key as in section 4.
2. It would be good to reference section 6 for random-to-key and RFC 3961 for k-truncate as well. 
3. Section 6 does not provide an entry for "string-to-key parameter format"
4. The encryption and decryption description in section 6 seems a little incomplete.  In particular the setting of newstate seems to be missing in the encryption.  In the decryption perhaps you should define how newIV is determined.  

Cheers,

Joe