Re: [MSEC] WGLC on draft-ietf-msec-gdoi-update-08

[Brian Weis <[e-mail]>]

Hi Sean,

On Apr 18, 2011, at 1:54 PM, Sean Turner wrote:

> Here's the rest of my comments on Sections 7 and 8 (all in 8):
> 
> Section 5.3.7 shows TBD-6 to 9 but the second paragraph in 8.1 only discussed TBD-6.  The others should be added in 8.1.
> 
> Section 5.6 shows TBD-7 and so does Section 8.1, but there's already a TBD-7 in Section 5.3.7.  Maybe renumber the one in Section 5.6 TBD-10?

I also noticed these issues when removing RSA-PSS. The TBD-7 in Section 5.3.7 became TBD-6, and the rest retain their original numbering. Section 8.1 was also brought up to date.

> Section 8.2: In the new registries, you need to say what needs to be done to update the registries (e.g., specification required, standards action).

Vincent also has pointed this out. But Section 8 that says:

   "When the new
   registries are added, the following terms are to be applied as
   described in the Guidelines for Writing an IANA Considerations
   Section in RFCs [RFC5226]: Standards Action, and Private Use."

From RFC 5226:

      Standards Action - Values are assigned only for Standards Track
            RFCs approved by the IESG.
      Private Use: Private use only (not assigned), as described in Section 4.1.

I'm not sure how to be state this more clearly, but it seems as if that's needed. Suggestions are welcome.

Thanks,
Brian

> 
> spt
> 
> On 4/2/11 1:09 PM, Sean Turner wrote:
>> #1) Add "updates: 3547 (once approved)" to the header. This will make it
>> match the intro/abstract. I can almost guarantee a discuss from somebody
>> on this.
>> 
>> #2) ISAKMP Phase 1 is described in Section 2.1 as "one such mechanism".
>> This isn't a MUST support. As far as I can tell there isn't a MUST
>> implement Phase 1 protocol (the protocols in Appendix A are also just
>> examples). But, to implement this document you've got to do things as
>> described in RFC 2407-2409. It seems like this doc and IKEv1 are pretty
>> well intertwined. And, the g-ikev2 draft doesn't use these formats it
>> uses something else...Let's be clear about what it's being used with. It
>> seems like this section ought to be changed as follows:
>> 
>> OLD:
>> 
>> The following sections describe one such "phase 1" protocol. Other
>> protocols which may be potential "phase 1" protocols are described in
>> Appendix A. However, the use of the protocols listed there are not
>> considered part of this document.
>> 
>> 2.1. ISAKMP Phase 1 protocol
>> 
>> This document defines how the ISAKMP phase 1 exchanges as defined in
>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following
>> sections define characteristics of the ISAKMP phase 1 protocols that
>> are unique for these exchanges when used for GDOI.
>> 
>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
>> requirements of a GDOI "phase 1" protocol.
>> 
>> NEW:
>> 
>> This document defines how the ISAKMP phase 1 exchanges as defined in
>> [RFC2409] can be used a "phase 1" protocol for GDOI. The following
>> sections define characteristics of the ISAKMP phase 1 protocols that
>> are unique for these exchanges when used for GDOI.
>> 
>> Section 7.1 describes how the ISAKMP Phase 1 protocols meet the
>> requirements of a GDOI "phase 1" protocol.
>> 
>> 
>> Delete the 2.1 header and renumber 2.1.1 and 2.1.2 to 2.1 and 2.2,
>> respectively.
>> 
>> I would also delete Appendix A. The currently proposed IKEv2 mechanism
>> isn't reusing these fields and the KINK option never got defined.
>> 
>> #3) Sec 3.2: r/Hashes are computed in the manner described within RFC
>> 2409./Hashes are computed in the manner described within [RFC2409].
>> 
>> #4) Sec 3.2: expand prf on first use.
>> 
>> #5) Sec 3.3: 2 lower case "must" should they be "MUST"?
>> 1 lower case "should" should it be "SHOULD"?
>> 
>> #6) Sec 4.2: Something is wrong with this:
>> 
>> Flags MUST have the Encryption bit set according to [RFC2008, Section
>> 3.1].
>> 
>> Maybe it should be:
>> 
>> Flags MUST have the Encryption bit set according to Section 3.1 of
>> [RFC2408].
>> 
>> #7) Sec 5: r/in accordance with RFC 2408./in accordance with [RFC2408].
>> 
>> #8) Sec 5.1, 5.2: r/defined in RFC 2408./defined in [RFC2408].
>> 
>> #9) Sec 5.2: This is difficult to parse:
>> 
>> The
>> next payload MUST NOT be a SAK Payload or SAT Payload type, but the
>> next non-Security Association type payload.
>> 
>> Maybe it's supposed to be:
>> 
>> The
>> next payload MUST NOT be a SAK Payload or SAT Payload type; it MUST
>> be the
>> next non-Security Association type payload.
>> 
>> #9) Sec 5.2: r/Must/MUST X4
>> 
>> #10) Sec 5.2.1: r/SA Attributes payloads must be/SA Attributes payloads
>> MUST be
>> 
>> #11) Sec 5.3: r/Must/MUST X2
>> r/should/SHOULD
>> r/must/MUST
>> 
>> #12) Sec 5.3: What is the conformance requirement for the following:
>> 
>> Any or all attributes may be optional, depending on the group policy.
>> 
>> #13) Sec 5.3.1:
>> 
>> r/ attributes may be present / attributes MAY be present or change to
>> say they are OPTIONAL.
>> 
>> r/attributes must/attributes MUST
>> 
>> #14) Sec 5.3.1:
>> 
>> The KEK_MANAGEMENT_ALGORITHM attribute may only be included in a
>> GROUPKEY-PULL message.
>> 
>> What happens if it's included in the PUSH message?
>> 
>> #15) Just noted to instances of GROUPKEY_. Aren't they supposed to be
>> GROUPKEY-*?
>> 
>> #16) Sec 5.3.3.3: r/as recommended in/as defined in
>> 
>> #17) Sec 5.3.6: Any reason not to point to FIPS 180-3?
>> 
>> #18) Sec 5.3.6: r/and SIG_HASH_ALGORITHM is not required to be present
>> in a SAK Payload/and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload
>> 
>> #19) Sec 5.3.7: Does anybody really want RSA-PSS?
>> 
>> #20) Sec 5.4: r/Must/MUST
>> r/Section 3.3 of RFC 2408./Section 3.3 of [RFC2408].
>> 
>> #21) Sec 5.4.1: r/ Section 4.2.1 of RFC 5374/Section 4.2.1 of [RFC5374]
>> r/should/SHOULD X2 ??
>> 
>> #22) Sec 5.5: r/Must/MUST
>> 
>> #23) Sec 5.5.1: Protocol, SEC ID Port, DST ID Prot, DST ID Port bullets
>> r/should/SHOULD ?
>> 
>> #24) Sec 5.5.1: r/from RFC 2407/from [RFC2407]
>> r/[RFC2407],/[RFC2407]),
>> r/ESP must also/ESP MUST also
>> 
>> #25) Sec 1.3: Add GSPD
>> 
>> #26) Sec 5.5.1.1.1: r/ RFC 5374/[RFC5374]
>> 
>> #27) Sec 5.5.1.1.1: r/must/MUST ?
>> 
>> #28) Sec 5.5.1.1.1: In the following, is 2119 language needed:
>> 
>> SA TEK payload
>> may be required in one or both directions.
>> 
>> #29) Sec 5.5.2: r/All Security Protocols must provide/All Security
>> Protocols MUST provide
>> 
>> #30) Sec 5.6.1: r/The attributes must follow/The attributes MUST follow
>> r/At least one TEK must be/At least one TEK MUST be
>> 
>> #31) Sec 5.6.1.2: r/to the member./to the GM.
>> 
>> #32) Sec 5.6.2 and 5.6.3: r/The attributes must follow/The attributes
>> MUST follow
>> 
>> #33) Sec 5.6.3 and 5.6.3.1: r/there must be only/there MUST be only
>> 
>> #34) Sec 5.6.3.1 and 5.6.3.2: r/Must/MUST
>> 
>> #35) Sec 1.3: add SSIV
>> 
>> #36) Sec 5.7: r/Must/MUST
>> r/must/MUST X3
>> 
>> #37) Sec 5.9: r/must be deleted, they must be/are to be deleted, they
>> MUST be
>> 
>> #38) Sec 10: References for 2403, 2404, 2407-2409, 3447, 4106, 4543,
>> 4754, 4868, 5903 are normative according to the following:
>> http://www.ietf.org/iesg/statement/normative-informative.html
>> 
>> Assuming you delete App A, remove references to 4330 and 5996.
>> 
>> Please ensure the classification of the other references are in
>> accordance with the IESG statement. If you've got any questions, let me
>> know. I don't want to find out later that some informative reference to
>> an informative RFC is actually a normative reference and we need to do a
>> 2nd IETF LC to note the DOWNREF.
>> 
>> I still need to finish Section 7 and 8.
>> 
>> spt
>> 
>> 
>> On 3/31/11 12:14 PM, Vincent Roca wrote:
>>> Hello everybody,
>>> 
>>> As you probably noticed the GDOI draft has been significantly
>>> updated WRT the previous 07 version. For details see:
>>> 
>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-msec-gdoi-update-08.txt
>>> 
>>> This situation motivates another WGLC. So please review
>>> 
>>> draft-ietf-msec-gdoi-update-08
>>> http://datatracker.ietf.org/doc/draft-ietf-msec-gdoi-update/
>>> 
>>> and send comments to the WG mailing list by April 18th.
>>> (NB: if ever this deadline is too close, then tell me...)
>>> 
>>> Regards,
>>> 
>>> Vincent
>>> _______________________________________________
>>> MSEC mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/msec
>>> 
>> _______________________________________________
>> MSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/msec
>> 
> _______________________________________________
> MSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/msec


-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]