Here are some quick comments on the -03 draft.
Jim
In section 1.2 - should disucss reliablity requriements in the event that
you are an EAP passthrough authenticator in last paragraph
Is the ABNF for "name" still wrong?
section 3.4 missing
Section 4 - does/should the application get any control ovret the set of
allowable EAP methods to be used or is that purely a fucntion of your
GSS-API library
For consistency the paragraph:
Tokens from the initiator to acceptor use an outer token type of 06
01; tokens from acceptor to initiator use an outer token type of 06
02. These token types are registered in the registry of RFC 4121
token types; see Section 8.1.
should refer to the "token ID" rather than the "outer token type" either
that or the item in the table should be updated.
section 5.2 refers to "token type" - I think that maybe this is the most
constant phrase to be used.
I will say that this version did harmonize and make the token naming scheme
much more consistent and readable. I think this is a big improvement.
s/secondsubtoken/second subtoken/ (in the table)
Section 5.3 -
Is there going to be a rule that you should send two error subtokens
in the even t\the length is greater than 8? I can understand saying you
should ignore the extended bytes but should you really ignore the error code
itself?
Section 5.4 - you have different names for the acceptor name subtokens in
the description of what is permitted and the actual subtoken names - I think
you might want to harmonize this.
Is there a rason that the EAP request subtoken is not documented in section
5.4 since it is a required subtoken from in the Initial State message from
the acceptor?
Section 5.4.1 - I realize this is a debugging string (Vender Subtoken) but
is there any reason in this day and age not make it a UTF8 string? (Other
than it is not one for Kerbros)
Section 5.4.3 - Should something be said about what the acceptor should do
if the initiator sends an acceptor name which is not completely correct for
the specific acceptor. I am thinking specifically of things like adding a
host name or adding some service specifics to the acceptor name. Is this
permitted? Or is this and error condition or since this is typically not
sent is the acceptor name from the client to be used in all events. (unless
totally wrong)
para #2 s/this token/This token/
Section 5.5 s/ACCEPTOR/acceptor/
The first bullet of this section is causing me some mental problems. The
acceptor cannot confirm that the protected result and the final result are
consistent - this is hidden from the acceptor. --- or you need to be
passing the protected result as a RADIUS attribute, at which point it is not
really protected anymore.
The acceptor can confirm that a key has been delivered to it, but it does
not know the source of the key - i.e. was it derived or just transmitted
inside of the EAP session.
Should the acceptor or the initiator send the error subtoken - or should the
acceptor be looking for clear EAP messages and generate a failure?
I think you need to carefully re-read the section and verify that you think
it is correct.
Setion 5.6 - Please tell me which type of channel binding I am getting at
this point. (I know it is GSS-API channel binding, but given that two
different types are discussed in the document I think being explcit would be
good.)
Section 6 - Is the KMSK in the "Tn = " line supposed to be GMSK?
Section 6.1 - I am unclear what the extension option field is referring to
please clarify.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
