Hi Sam,
I also performed a review of the -03 version of the draft. Thought many
of the comments were already pointed out by Jim and solved in -04
version, some of them are still valid. Most of them are typos or
clarifications. I hope the will help.
Section 1.2
* "In this case, the GSS-API peer acts..:" s/GSS-API peer/GSS-API
acceptor/
Section 3.1
* Related with the GSS_C_NT_HOSTBASED_SERVICE name, I think the
textual representation should be "SERVICE@HOST" instead of
"HOST@SERVICE".
* In the sentence "but the semantics are not similar enough semantics
to use..." the second "semantics" is redundant
Section 3.3
* Surround with () the reference in the sentence "..unless the
acceptor supplies the acceptor name response Section 5.4.3.".
Section 5
* Change "The innerToken field starts with a 16-bit network byte order
token type." with "The innerToken field starts with a 16-bit network
byte order token type identifier." to be consistent with the table.
* In the figure describing the structure of the inner token, it may
not be clear if Position is given in bits or bytes (not that in the
parragraph above it talks about a 16-bit field, not a 2-byte field.
Section 5.2
* It is stated that "The subtoken type MUST be unique within a given
token". Is there any requirement or motivation for this? Won't this
limit us in the future for extensions? Just asking, cause I don't
really know.
Section 5.4
* If the optimization related with the discussion "GSS-EAP: do we need
an identity request" is specified, the text should be changed to
reflect the fact that the acceptor response when in Initial State
may not be an EAP request/identity message, but an EAP request
starting a specific EAP method.
Section 5.4.3
* Change "Typically this token would only be send if" with
"Typically this token would only be sent if"
* Change "If the initiator receivs an EAP Success message," with
"If the initiator receives an EAP Success message"
* Change "then the acceptor sends this in the Eap Request
subtoken type" with "then the acceptor sends this in the EAP Request
subtoken type"
* What happens when none of the initiator supplied target names
are applicable? An error is produced, or a name out of the proposed
list is given? If this last case applies, then the text should be
modified to reflect this fact.
Section 5.5
* In the sentence "If the EAP state machine generates an EAP success
message, then EAP believes the authentication is successful.", did
you mean "If the EAP state machine generates an EAP success message,
then EAP authenticator believes the authentication is successful."?
* There is an inconsistence between the text in the first bullet and
the text in the second bullet. In the first one, it talks about the
EAP state machine generating EAP messages. Opposite, the second one
talks about the acceptor receiving EAP messages. Though I understand
they both are correct, I think it would be better to homogeneize
and, in the fist bullet say: "If the acceptor receives an EAP
success message.....".
* Additionally, in the second bullet it is stated that an error
subtoken is sent, and GSS failure is returned. However, in the third
bullet it is stated that a subtoken is returned. The use of "send"
and "return" may result a bit confusing. I think that we may want to
homogenize this and assume that tokens are sent while GSS errors are
returned.
Section 5.6.2
* Nothing is said about the key to be used (I guess it will be the CRK
described in section 6).
Section 5.7
* I have a question here, not an issue, I'm just curious. If the
PROT_READY is never available and per-message security services
cannot be used before context establishment, how do you call to
GSS_Wrap and GSS_GetMIC to generate the Channel Bindings and MIC
subtokens?
Section 6
* s/following procedur/following procedure/
Best regards,
Alejandro
El 01/11/11 02:11, Jim Schaad escribió:
-----Original Message-----
From: Sam Hartman [mailto:[email protected]]
Sent: Sunday, October 30, 2011 4:20 PM
To: Jim Schaad
Cc: [email protected]; [email protected]
Subject: Re: [abfab] Review on gss-eap-03
"Jim" == Jim Schaad<[email protected]> writes:
Jim> Is the ABNF for "name" still wrong?
I don't think so.
What problem or oddity do you see?
Hmm.
I see that realm is only permitted if host is present. I think I've fixed
that.
I think it's correct now in 04.
That was the specific error that I saw.
Jim> section 3.4 missing
Jim> Section 4 - does/should the application get any control ovret
Jim> the set of allowable EAP methods to be used or is that purely a
Jim> fucntion of your GSS-API library
Currently no mechanism is provided for an application to enfluence this.
A mechanism probably should have system-level policy configuration.
A mechanism could expose a credential option on the initiator.
If we ever need to standardize a credential option we can, but I don't see
a
need for that now.
Jim> For consistency the paragraph: Tokens from the initiator to
Jim> acceptor use an outer token type of 06 01; tokens from acceptor
Jim> to initiator use an outer token type of 06 02. These token
Jim> types are registered in the registry of RFC 4121 token types;
Jim> see Section 8.1.
My understanding is that the ID describes which type of token (token
type) we are dealing with.
So, I've phrased it as token s with from acceptor to initiator use an
inner
token type with ID xxx.
1) token type with ID
and 2) inner not outer
Looks fine
Jim> should refer to the "token ID" rather than the "outer token
Jim> type" either that or the item in the table should be updated.
Jim> section 5.2 refers to "token type" - I think that maybe this is
Jim> the most constant phrase to be used.
I've updated the registry to talk about token type identifiers.
Jim> I will say that this version did harmonize and make the token
Jim> naming scheme much more consistent and readable. I think this
Jim> is a big improvement.
Great!
Jim> s/secondsubtoken/second subtoken/ (in the table)
Jim> Section 5.3 - Is there going to be a rule that you should send
Jim> two error subtokens in the even t\the length is greater than 8?
Jim> I can understand saying you should ignore the extended bytes
Jim> but should you really ignore the error code itself?
In 04 we have initiators MUST ignore octets beyond the GSS EAP error code
for future extensibility. Thanks for the catch.
Jim> Section 5.4 - you have different names for the acceptor name
Jim> subtokens in the description of what is permitted and the
Jim> actual subtoken names - I think you might want to harmonize
Jim> this.
Jim> Is there a rason that the EAP request subtoken is not
Jim> documented in section 5.4 since it is a required subtoken from
Jim> in the Initial State message from the acceptor?
I've added a reference. However I think it's better to document EAP
request
and response near each other.
Note that if we adopt the proposal to reduce a round trip this subtoken
goes
away from initial state.
Jim> Section 5.4.1 - I realize this is a debugging string (Vender
Jim> Subtoken) but is there any reason in this day and age not make
Jim> it a UTF8 string? (Other than it is not one for Kerbros)
It doesn't exist for Kerberos (which has no vendor string I'm aware of) so
I
don't think that's a concern.
I've made it UTF-8; I don't care.
Jim> Section 5.4.3 - Should something be said about what the
Jim> acceptor should do if the initiator sends an acceptor name
Jim> which is not completely correct for the specific acceptor. I
Jim> am thinking specifically of things like adding a host name or
Jim> adding some service specifics to the acceptor name. Is this
Jim> permitted? Or is this and error condition or since this is
Jim> typically not sent is the acceptor name from the client to be
Jim> used in all events. (unless totally wrong)
I think you mean 5.4.2 not 5.4.3?
My assumption is that you need to send a superset of what the acceptor
expects, else things will fail at channel binding. I think you want to
leave it to
channel binding to fail unless an IDP wants to implement some form of
aliasing.
In 5.4.2 s/hosntame/hostname/
I meant 5.4.3 - because I was assuming this was an Acceptor error rather
than an Initiator. That is if the Acceptor name is not a superset then it
would return an error. The question is should you both error and return the
response in some sense.
One possibility is that the Initiator sends name #1, the Acceptor replies
with name #2 and then the intiator says that this is acceptable and sends
name #2 as part of the channel binding. In this case the was no error but
the initator name is not a superset of the acceptor name that came back.
Jim> para #2 s/this token/This token/
Jim> Section 5.5 s/ACCEPTOR/acceptor/
Not fixed
Jim> The first bullet of this section is causing me some mental
Jim> problems. The acceptor cannot confirm that the protected
Jim> result and the final result are consistent - this is hidden
Jim> from the acceptor. --- or you need to be passing the protected
Jim> result as a RADIUS attribute, at which point it is not really
Jim> protected anymore.
For combined authenticators the acceptor can and should evaluate the
protected result.
For pass-through authenticators the acceptor should confirm there's AAA
success if there is EAP success.
Ok - I think this is more clear now.
Jim> The acceptor can confirm that a key has been delivered to it,
Jim> but it does not know the source of the key - i.e. was it
Jim> derived or just transmitted inside of the EAP session.
Here, we mean the security claim discussed in section 7.10 of RFC 3748,
which
probably includes transmitting a key.
Their term, not mine.
I've added a reference.
Ok
Jim> Should the acceptor or the initiator send the error subtoken -
Jim> or should the acceptor be looking for clear EAP messages and
Jim> generate a failure?
I don't understand.
Jim> I think you need to carefully re-read the section and verify
Jim> that you think it is correct.
I think it is consistent with what EAP does and what our implementation
does.
There are some disadvantages to how EAP handles failures.
We can discuss at IETF 82 if you like.
I think this would probably be a good idea - just so I can be sure that we
understand each other and what the doc says.
Jim> Setion 5.6 - Please tell me which type of channel binding I am
Jim> getting at this point. (I know it is GSS-API channel binding,
Jim> but given that two different types are discussed in the
Jim> document I think being explcit would be good.)
Also added a forward reference.
Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be
Jim> GMSK?
Yes.
Jim> Section 6.1 - I am unclear what the extension option field is
Jim> referring to please clarify.
This was all wrong and has been fixed. Thanks for the reality check.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
