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