Re: Gen-ART LC Review of draft-ietf-nsis-nslp-auth-06

[Roland Bless <[e-mail]>]

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