The set of Plasma people is close to finishing the use case/architecture document and already we have a fairly stable document for how CMS is used. I am currently trying to get finished with a huge set of edits to the client/server protocol document which includes the use of GSS-API as one of the options.
However, many of the questions below fall into the category of how do you do things with GSS-API/EAP and thus are not restricted to the Plasma work. Jim > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:[email protected]] > Sent: Sunday, December 18, 2011 2:02 AM > To: ext Jim Schaad; [email protected] > Subject: RE: [abfab] Trying to get Plasma text correct. > > Hi Jim, > > When you say "Plasma" you are referring to "The PoLicy Augmented S/Mime > (plasma)" > https://www.ietf.org/mailman/listinfo/plasma > > Correct? > > To judge whether it is useful to write about that work I have to admit that I > am not fully up-to-speed with the latest status of that effort. > > Can you shed some light on that? > > Ciao > Hannes > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of ext Jim Schaad > > Sent: Friday, December 16, 2011 10:01 AM > > To: [email protected] > > Subject: [abfab] Trying to get Plasma text correct. > > > > 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
