Re: [secdir] (Security sections) SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06

"Black, David" <david.black@emc.com> Tue, 09 October 2012 16:14 UTC

Return-Path: <david.black@emc.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 B60D921F86FD; Tue, 9 Oct 2012 09:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level:
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, 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 iLTawxpQTlhy; Tue, 9 Oct 2012 09:14:28 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2E01F0C8C; Tue, 9 Oct 2012 09:14:28 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q99GENsZ018919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2012 12:14:24 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 9 Oct 2012 12:14:12 -0400
Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q99GEAGf001999; Tue, 9 Oct 2012 12:14:10 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Tue, 9 Oct 2012 12:14:10 -0400
From: "Black, David" <david.black@emc.com>
To: Mallikarjun Chadalapaka <cbm@chadalapaka.com>, Alexey Melnikov <alexey.melnikov@isode.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-storm-iscsi-cons.all@tools.ietf.org" <draft-ietf-storm-iscsi-cons.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Tue, 9 Oct 2012 12:14:08 -0400
Thread-Topic: (Security sections) SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
Thread-Index: Ac2lzsXPBS9OBtwqStSh6+tbLAcd7AAZqScA
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DF11D8F@MX15A.corp.emc.com>
References: <E160851FCED17643AE5F53B5D4D0783A4C411CA2@BL2PRD0610MB361.namprd06.prod.outlook.com>
In-Reply-To: <E160851FCED17643AE5F53B5D4D0783A4C411CA2@BL2PRD0610MB361.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Thu, 11 Oct 2012 07:49:56 -0700
Cc: "Black, David" <david.black@emc.com>
Subject: Re: [secdir] (Security sections) SecDir and AppsDir review of draft-ietf-storm-iscsi-cons-06
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: Tue, 09 Oct 2012 16:14:30 -0000

> Hi Alexey, here are the responses to your comments specific to security
> sections of iSCSI consolidated draft - actually, I am deferring mostly to
> Julian and David who are better suited than me to comment on this area, :-)

That would be my cue ... inline ...

> >
> > In 9.3.1:
> >
> > - HMAC-SHA1 MUST be implemented [RFC2404].
> >
> > RFC 2404 seems to define HMAC-SHA-1-96, not HMAC-SHA1.
> [Mallikarjun:] That is true. I do not know the reason for this citing.
> Julian/David?
> 
> I also found it interesting that the abstract for 2404 itself does not use the
> "96" qualifier.

IPsec uses HMAC-SHA1 with its output truncated to 96 bits.  HMAC-SHA1 was
used here as being a more recognizable algorithm name, but the specific
requirements of RFC 2404 do apply.  Here's some revised text that handles
both concerns:

 - HMAC-SHA1 MUST be implemented in the specific form of HMAC-SHA-1-96 [RFC2404].

> >
> > 9.3.2. Confidentiality
> >
> >    The NULL encryption algorithm MUST also be implemented.
> >
> > I find it odd that the section talks about how weak DES is and then
> > requires NULL encryption to be supported. What is the reason for this?
> 
>  [Mallikarjun:] IIRC, I *think* this was because we wanted implementations to
> be able to use the authentication/MAC of IPSec suite, without forcing them
> always to use encryption. David, can you please add/correct?

Mallikarjun is basically correct, but there's more to explain.

The NULL encryption algorithm is needed to allow use of ESP for authentication
(cryptographic integrity) without encryption.  This is often preferred to AH
for that purpose, especially in hardware implementations.

> >
> > 9.3.3. Policy, Security Associations, and Cryptographic Key
> >          Management
> >
> >       - When digital signatures are used to achieve authentication,
> >         an IKE negotiator SHOULD use IKE Certificate Request
> >         Payload(s) to specify the certificate authority. IKE
> >         negotiators SHOULD check the pertinent Certificate
> >         Revocation List (CRL) before accepting a PKI certificate for
> >         use in IKE authentication procedures.
> >
> > What are the reasons for these requirements being SHOULD level (as
> > opposed to MUST level)?

There are environments in which a small number of certificates are statically
configured as trust anchors in which these mechanisms may not be needed.

> >
> >    - The following identification type requirements apply to IKEv1.
> >      ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports
> >      IPv6) and ID_FQDN Identification Types MUST be supported;
> >      ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address
> >      Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types
> >      SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT
> >      be used.
> >
> > It would be good to know the reason for the last SHOULD NOT and the last
> > MUST NOT.
> 
>  [Mallikarjun:] I will defer to Julian and David on these.

Sure ... this was done back in RFC 3270 and is being carried forward
from there (i.e., none of these requirements are new).

IP Subnet and IP Address Range are too broad to usefully identify an
iSCSI endpoint, hence they are "SHOULD NOT".

The _DN and _GN types are X.500 identities; unless one is a PKI
expert, the better approach is usually to use subjectAltName.
The primary reason for the "SHOULD NOT" was to warn those who
are not PKI experts away from X.500 identities.

ID_KEY_ID is not interoperable as specified in RFC 2407
("opaque byte stream which may be used to pass vendor-specific
information"), hence they are "MUST NOT".

Should explanatory text for these be added to the draft?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------