>>>>> "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.
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
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.
Jim> para #2 s/this token/This token/
Jim> Section 5.5 s/ACCEPTOR/acceptor/
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.
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.
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.
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
