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:yaronf.ietf@gmail.com]
>> 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
>> On Behalf Of Internet-Drafts@ietf.org
>>> Sent: Wednesday, June 05, 2013 3:51 PM
>>> To: i-d-announce@ietf.org
>>> Cc: storm@ietf.org
>>> 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.
>>>
>>>
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>