Hi Ben, On 01.09.2010 00:55, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may receive. Thanks for the review and sorry for the late response, but I was still on vacation. > Document: draft-ietf-nsis-nslp-auth-06.txt > Reviewer: Ben Campbell > Review Date: 2010-08-31 > IETF LC End Date: 2010-08-31 > IESG Telechat date: (if known) > > Summary: > > This draft is almost ready for publication as an experimental RFC. There are some minor issues that should be considered first, and a few editorial comments. > > -Major issues: None > > -Minor issues: > > -- section 3.2.7, 2nd paragraph: "The creator of this attribute lists every NSLP object..." > > Is there an order requirement? At least, the order in this list must match the order in the signature, right? That's correct. Will add sentence: The hash computation has to follow the order of the NSLP object types as specified by the list. > -- section 4.1.1, 2nd paragraph: > > Is HMAC-MD5 still a reasonable choice for a single mandatory-to-implement algorithm these days? Good question. I thought that HMACs are not so strongly affected by the discovered hash algorithm weaknesses w.r.t. collision attacks. I could change this to HMAC-SHA-256 though. Any other suggestions? > -- Section 6.4, 1st paragraph: > > This paragraph seems to conflate authentication with authorization. Integrity protection provides authentication, from which one can apply authorization policy. But it's not authorization policy in itself. That's correct. I'm proposing a change as follows: The SESSION_AUTH object can also be used to provide an integrity protection for every NSLP signaling message, thereby also authenticating requests or responses. Assume that a user has deposited a shared key at some NN. This NN can then verify the integrity of every NSLP message sent by the user to the NN. Based on this authentication the NN can apply authorization policies to actions like performing resource reservations or opening firewall pinholes. > -- Section 7, 3rd paragraph: > > This seems to conflict with 3.2.7 and 3.2.8, which only conditionally require AUTHENTICATION_DATA to be included. I guess that the MUST was related to the untrusted environments only.... The second issue, the integrity of the policy element, is preserved in untrusted environments by including the AUTHENTICATION_DATA attribute in such environments. > -Nits/editorial comments: > > -- section 2, paragraph 2, 2nd sentence: > > s/chose/choose good catch. > -- section 2, 5th paragraph, 1st sentence: "...operation of the authorization is to add one authorization policy object" > > Does this mean "... operation of the authorization layer..."? Will rephrase to: The default operation when using NSLP layer session authorization is to add one authorization policy object. > -- section 4.2, 2nd paragraph: "The ticket can be presented to the NSLP node via Kerberos by sending a KRB_CRED message to the NSLP node..." > > Who presents it? The NSLP requesting host can present the ticket to the NSLP node via Kerberos by sending a KRB_CRED message to the NSLP node independently but prior to the NSLP exchange. > > "...must be known in advance..." > > Who must know it? Thus, the principal name of the service must be known _at the client_ in advance, though the exact IP address may not be known in advance. > -- section 4.3.1.1, 1st paragraph: "...X509_V3_CERT, AUTHENTICATION_DATA MUST be generated following these steps" > > Who must generate it? (stated in 4.3.1) When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA MUST be generated by the authorizing entity following these steps: > -- section 4.3.1.1, 2nd paragraph: "...verification MUST be done following these steps:" > > Who must do the verification? When the AUTH_ENT_ID is of type X509_V3_CERT, verification at the verifying network element (PDP or router) MUST be done following these steps: > -- section 4.3.1.1, 7th paragraph: " ... the public key of the authorizing entity can be extracted from the certificate." > I assume this step is not intended to be optional, but the language "can be" implies that it is. I guess that this is only necessary if the public key isn't already known from earlier verification procedures, that's why it says "can be". > -- section 4.3.1.2, 1st paragraph: "...AUTHENTICATION_DATA MUST be generated following these steps:" > > Who must generate it? authorizing entity (see above) > -- section 4.3.1.2, first bullet in list of steps: > > That's not really a step. Will be fixed. > --... Third bullet > > Who signs it? the authorizing entity > -- ... First paragraph after first bullet list: "verification MUST be done" > > Who must do the verification? the verifying network element (PDP or router) > -- section 4.4, 1st paragraph after bullet list: The Key-ID in the AUTHENTICATION_DATA allows to refer" > > "allows" is a transitive verb in this context. I suggest "... allows [some actor] to refer", or "...allows the reference..." ok. > -- section 6.2.3, general: > > It's not clear to me if you mean for QNE/PDP to refer to one or the other, or the combination of the QNE and PDP. QNE or PDP, but the PDP could also be integrated into the QNE. Will replace with "QNE or PDP". Regards, Roland _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf