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?

-- section 4.1.1, 2nd paragraph:

Is HMAC-MD5 still a reasonable choice for a single mandatory-to-implement 
algorithm these days?

-- 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.

-- 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. 


-Nits/editorial comments:

-- section 2, paragraph 2, 2nd sentence:

s/chose/choose

-- 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..."?

-- 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?

"...must be known in advance..."

Who must know it?

-- section 4.3.1.1, 1st paragraph: "...X509_V3_CERT, AUTHENTICATION_DATA 
MUST be generated following these steps"

Who must generate it?

-- section 4.3.1.1, 2nd paragraph: "...verification MUST be done following 
these steps:"

Who must do the verification?

-- 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.

-- section 4.3.1.2, 1st paragraph: "...AUTHENTICATION_DATA MUST be 
generated following these steps:"

Who must generate it?

-- section 4.3.1.2, first bullet in list of steps:

That's not really a step.

--... Third bullet

Who signs it?

-- ... First paragraph after first bullet list: "verification MUST be done"

Who must do the verification?

-- 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..."

-- 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.