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

["Black, David" <[e-mail]>]

> 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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------