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

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

Hi Yaron,

> > I left the must-implement DH groups to the underlying IPsec specs; is it
> > 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 :-)

Sure, I'll do that.

> > 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.
> 
> Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we
> 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

> -----Original Message-----
> From: Yaron Sheffer [mailto:[e-mail]]
> Sent: Thursday, June 06, 2013 4:59 PM
> To: Black, David
> Cc: IPsecme WG
> Subject: Re: [IPsec] FW: I-D ACTION:draft-ietf-storm-ipsec-ips-update-00.txt
> 
> Hi David,
> 
> please see follow up comments below.
> 
> Thanks,
> 	Yaron
> 
> On 2013-06-06 15:33, Black, David wrote:
> > 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" -
> >> are there any cases when they're not?
> >
> > I left the must-implement DH groups to the underlying IPsec specs; is it
> > 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 :-)
> 
> >
> > 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.
> 
> Now I'm confused: we're using DH in Quick Mode (and IKEv2 CCSA) if we
> want PFS. So what do you mean?
> 
> >
> >> * 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.
> >
> > 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
> >> generated PSK would be so much more convenient... See RFC 6631, Sec.
> >> 3.5+3.6. But of course it is only experimental, sigh.
> >
> > 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).
> 
> I'm really tempted to go into a lengthy discussion of PAKE and IPR, but
> I'd rather not spam this list.
> 
> >
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Yaron Sheffer [mailto:[e-mail]]
> >> 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" -
> >> 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:
> >>> 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: [e-mail] [mailto:[e-mail]]
> >> On Behalf Of [e-mail]
> >>> Sent: Wednesday, June 05, 2013 3:51 PM
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> 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 "Updates:" 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.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> IPsec mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ipsec
> >>>
> >