I am starting to try and develop text for the Plasma documents on how to use GSS-API. At least initially, I want to write it to be generic GSS-API and then do specifics for the ABFAB GSS-API/EAP case.
To make my life simpler, we are going to require that the client/RP transport method always be TLS. Which means that I will at some point in the future need to worry about cases where path validation is not completely successful. But I am planning to punt that issue for now. So since we always know the name of the entity we are going to be talking to. My assumption is that we are always going to pass an acceptor name into GSS-API. The acceptor name would be "plasma/serverName@domainName". We would say strip the left most dotted name as the server name and leave the rest as the domain name. Thus an example name might be "plasma\[email protected]". Now we start looking at some fun things. 1. If the url was https://mailPDP.windows.example.com/internalPolicyChecker, should the extra verbage be reflected in the service name string? 2. Do we need to say anything special about walking up domain names when doing checking or during AAA processing? Specifically, should a domain string be truncated when doing the channel binding processing called out in the EMU channel bindings document wrt to the database lookup code? 3. In the current code, one would expect that the client would send the full name to the RP as part of the first GSS-API handshake message. I still feel somewhat uncomfortable with telling the RP what its full name is going to be, but I don't see any way around this with the current GSS-API calling code. That is since I want the channel binding to occur w/ a specific server and domain, there is no way not to let the RP know what they are going to be in advance. I understand that the AAA system will validate that the RP has the right to the name so there should not be any issues, but is there any way to make me feel more comfortable with this? 4. Since I am using TLS, I will need to specify that TLS channel binding will occur (and find the appropriate references about how this works for extraction). I am still trying to debate if I need to include additional channel binding data from my protocol dialog as well. Has anybody written any guidance on when this is recommended and what types of data need to be included? I think I have re-designed my protocol so this is no longer necessary, but I would like some assurance that I am correct. 5. If I get to this point, have I already selected the credential that I will be using with the EAP server, or I have just gotten to the point of saying that I will be using one of a set of credentials? This is an LOA question. I will have already selected the realm that I am going to be authenticated against since I know that goes out in the first GSS-API/EAP message. I also understand that by selecting a realm, I may have restricted the set of possible LOAs that I can be dealing with. Should my protocol allow for some type of re-start of negotiation if a different LOA is needed? I assume that would need to be a total re-start of the GSS-API/EAP negotiation at a minimum although I could leave up the TLS session. 6. Should I be setting up some type of negotiation in my protocol to allow for a different GSS-API mechanism to be selected? I.e. if one is within a single company one could use the Kerberos GSS-API rather than going with the EAP version. Would be think this is of importance or can I just restrict to using the one GSS-API mechanism and be done with it? Can this type of negotiation be done within GSS-API? I don't remember seeing anything of this sort but that does not mean it does not exist. My understanding was that it amounted to configuration information on the client side. Jim _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
