Subject: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt

From: "Black, David" <[email-masked]>
Date: Wed, 5 Jun 2013 16:30:32 -0400

FYI - this draft is likely to move fairly quickly, with both
WG Last Call and the publication request that hands off draft from
the WG to the AD happening before the Berlin IETF meetings.

WG Last Call in the storm WG is expected to start next week.

Thanks,
--David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 05, 2013 3:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the STORage Maintenance Working Group of the IETF.

    Title         : IP Storage: IPsec Requirements Update for IPsec v3
    Author(s)     : D. Black, et al
    Filename      : draft-ietf-storm-ipsec-ips-update
    Pages         : 13 
    Date          : June 5, 2013 
    
   RFC 3723 includes requirements for IPsec usage with IP Storage
   protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related
   RFCs).  This document updates those requirements to IPsec v3 (RFC
   4301 and related RFCs) and updates implementation requirements to
   reflect developments in cryptography since RFC 3723 was published.

   [RFC Editor: The &quot;Updates:&quot; list above has been truncated by xml2rfc.
   The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172,
   4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if
   approved) ]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-storm-ipsec-ips-update-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLXN0b3JtLWlwc2VjLWlwcy11cGRhdGUNCg==

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 06 Jun 2013 08:45:05 +0300

Hi David,

• The ref for AES-GMAC is RFC 3543, should be 4543.
• 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption?
• The separation of GMAC and CTR, when we really want the combined-mode 
GCM, is very confusing.
• 3: why no must-implement DH group? Also, "when DH groups are used" - 
are there any cases when they're not?
• 3.1: I would expect a discussion here about correlation between IKE 
identity and the application protocol. E.g. are target names used as 
IKEv2 ID values? This probably makes more sense when iSCSI discovery is 
being used.
• 3.1: (shameless plug...) instead of certs, PACE with an automatically 
generated PSK would be so much more convenient... See RFC 6631, Sec. 
3.5+3.6. But of course it is only experimental, sigh.

Thanks,
	Yaron

On 2013-06-05 23:30, Black, David wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 6 Jun 2013 08:33:03 -0400

Hi Yaron,

Thank you for the quick review.

> * The ref for AES-GMAC is RFC 3543, should be 4543.

That's embarrassing - not just off-by-1, but off-by-1000 :-).
I will definitely fix that in the -01.

> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption?
> * The separation of GMAC and CTR, when we really want the combined-mode
> GCM, is very confusing.

See the end of 2.2.  AES CTR changes from MAY to SHOULD, and there's a SHOULD
for AES GCM.  I'll add a sentence after the two bullets at the start of 2.2
to make it clear that both requirements are being changed.

> * 3: why no must-implement DH group? Also, "when DH groups are used" -

I left the must-implement DH groups to the underlying IPsec specs; is it
important to repeat that here?

For no DH group, see IKEv1 Quick Mode without perfect forward secrecy,
and I need to add a sentence requiring PFS to be implemented for that case.
Text suggestions are welcome.

> * 3.1: I would expect a discussion here about correlation between IKE

That belongs in an iSCSI-specific doc; this draft is generic to a number
of IP Storage protocols - e.g., iSCSI, FCIP, iFCP.

> * 3.1: (shameless plug...) instead of certs, PACE with an automatically

Plug noted ;-).  Independently, FWIW, if there had not been IPR complications
at the time, SRP would have been the mandatory-to-implement inband
authentication mechanism for iSCSI (in the main iSCSI doc, not here).

Thanks,
--David

> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Thursday, June 06, 2013 1:45 AM
> To: Black, David
> Cc: IPsecme WG
> Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt
> 
> Hi David,
> 
> * The ref for AES-GMAC is RFC 3543, should be 4543.
> * 2.1: AES-GMAC and not AES-GCM? Authentication but no encryption?
> * The separation of GMAC and CTR, when we really want the combined-mode
> GCM, is very confusing.
> * 3: why no must-implement DH group? Also, "when DH groups are used" -
> * 3.1: I would expect a discussion here about correlation between IKE
> * 3.1: (shameless plug...) instead of certs, PACE with an automatically

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 06 Jun 2013 23:58:57 +0300

Hi David,

please see follow up comments below.

Thanks,
	Yaron

> important to repeat that here?

I suggest that you add something like: Requirements for DH groups and 
PRF are as specified in RFC 4109 (for IKEv1), RFC 4307 (for IKEv2) or 
any documents updating them. (That's assuming your implementers can 
navigate our must-minuses and should-pluses :-)

> Text suggestions are welcome.

Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we 
want PFS. So what do you mean?

> authentication mechanism for iSCSI (in the main iSCSI doc, not here).

I'm really tempted to go into a lengthy discussion of PAKE and IPR, but 
I'd rather not spam this list.

---

From: "Black, David" <[email-masked]>
Date: Thu, 6 Jun 2013 17:07:13 -0400

Hi Yaron,

> navigate our must-minuses and should-pluses :-)

Sure, I'll do that.

> want PFS. So what do you mean?

Sorry, I mixed two separate concepts in one sentence:

- Quick mode can be used without DH when there's no key exchange and hence
	no PFS.  That's the case in which there may be no DH involved in
	an IKEv1-based SA setup.
- Independent of that observation, RFC 3723 contains a "MUST implement"
	requirement for IKEv1 PFS that ought to be repeated in this draft.
	I'll add that, but note that it's not a "MUST use" requirement.

Thanks,
--David

> Sent: Thursday, June 06, 2013 4:59 PM
> To: Black, David
> Cc: IPsecme WG
> >>>      [RFC Editor: The &quot;Updates:&quot; list above has been truncated
> by
> >> xml2rfc.