> 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
That's a good question. The application can select which GSS EAP variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sure how the application might select EAP methods. Sounds like something we could make a settable attribute on either the credential or context object. > 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? This doesn't sound right, there should be a single error token, extra bytes are ignored for extensibility. > 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) Makes sense. > 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) Also, given the entire exchange is not protected, what are the security implications given the acceptor name is vulnerable to a MITM? Should we send a MIC of it in the last token? > 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.) Being explicit in every instance would be useful, I agree, because it is very confusing when you first start to understand this protocol. -- Luke _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
