On Fri, Dec 16, 2011 at 2:01 AM, Jim Schaad <[email protected]> wrote: > 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.
Since we're talking about doing channel binding the simplest thing to do is to say that whatever certificate the server uses, you'll accept -- i.e., simply turn off validation. (Oh, you might want to say that the cert must not be expired, and you'll definitely want to say something about key algorithms and key sizes, but validation? just turn it off.) > 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 You always know the name of the RP that you want to be talking to. If you want to do GSS w/ CB to TLS then ignore the RP's name from TLS. Note that CB implies that GSS must authenticate the RP to the client. > GSS-API. The acceptor name would be "plasma/serverName@domainName". We Something like that, yes. > 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]". The details of this will likely be different. I'd say that you'd use GSS_C_NT_HOSTBASED syntax: service@hostname (FQDN). If a "realm" is needed we'll either inspect the actual target name after authentication completes or we'll use GSS_Set_name_attribute() to set the expected realm name of the target on the client side. The mechanism's translation of this might be service/hostname.fqdn@REALM, e.g., in the case of Kerberos. > 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? If the URL's scheme was HTTP and we're usign HTTP/Negotiate then the RP's name should be [email protected]. We could agree to make it different, but that would break the current convention. Or we could use something other than HTTP/Negotiate. > 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? I don't understand this. Are we talking about EAP channel binding here instead of GSS channel binding? > 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 It is not possible to design an authentication protocol that provides privacy protection (from active attacks) to both peers, not without having a trusted third party to which the two peers authenticate first and which then decides if/what they should be allowed to know each other. Moreover, traffic analysis alone will generally disclose the name of the RP, except in peer-to-peer applications. Is this a p2p application? > 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? What is the problem with the RP knowing what it was called by the client? (I'm not saying there can't be a problem, just that I want to know it :) > 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 You certainly can! > 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. CB can be used to provide [after-the-fact] integrity protection to non-CB data that is sent in the clear before or during the GSS security context token exchange. More later, after lunch, Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
