> > Variant (A) - IdP + PKINIT:
> > A1) User authenticates to his SAML/OpenID provider (external domain)
> > A2) User locally generates CSR
> > A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to
> > the IdP
> > A4) IdP returns short-lived certificate (validity period matches
> > policy for TGT)
> > A5) User presents certificate issued by IdP to KDC
> > A6) KDC authenticates user via PKINIT and issues TGT as usual
> >
> > This variant doesn't require any change to Kerberos protocol. It needs
> > IdP with CA + some client software automating described steps.
> >
> >
> > Variant (B) - IdP without PKINIT is almost the same, just uses symmetric
> crypto:
> > A1) User authenticates to his SAML/OpenID provider (external domain)
> > A2) User contacts IdP (gssapi/saml ; gssapi/openid) and sends
> > authentication request
> > A4) IdP changes principal password to some random value and sends
> > keytab back to the user (via GSSAPI-secured connection)
> > A5) User uses keytab to get TGT from KDC
> >
> > Obvious problem is that keytab received by user has to be short-lived.
> > For example, IdP could generate a new random password for user
> > principal 1 minute after sending keytab to the user.

Interesting notion. My understanding of B is that KDC would need an entry for 
the user in order to store the shared secret. This may "interact" with the 
principal name mapping in some hard-to-understand-right-now ways. For instance:

KDC manages "EXAMPLE.ORG".

User is coming in from google openID account. Pretend "mapped" Kerberos 
principal is: username@OPENID:www.google.com/openid/provider/url

Can the KDC for EXAMPLE.ORG store that? I can see approach A working because 
the user principal doesn't have to exist in the KDC. Seems like case "B" 
involves a shared secret between external user and the local KDC, whereas 
approach A doesn't.

I would vote for making the lifetime of the shared secret be derived from the 
lifetime of the credential the person used to get it. (if the openID session is 
good for 12 hours, the keytab should be too.) I don't see a need to null out 
the keytab after one minute.

> >
> > This could work if the whole process should be automated.
> http://www.umich.edu/~x509/
> I already have a plan to implement this in Ipsilon eventually :-)


Perhaps the NSCA MyProxy CA also has some ideas worth implementing? It seems to 
be geared to a full-on PKI environment, where it issues derived (proxy) 
certificates for users to use in a login session. It appears that it could make 
kx509 certs as it is configurable w.r.t. what fields appear in the generated 
certificates and how identities are mapped. Also, it has client side programs 
for certificate storage and retrieval. Some concepts may be worth stealing. :)

Overall, it appears to me that short-lived certs (approach A) have a certain 
time-tested feel to them earned by many years of regular use captured in 
RFC3820. Approach A, in the parlance of RFC3820, could potentially be expressed 
as "External users delegate to a local Kerberos session the right to use their 
non-Kerberos identity by causing a proxy kx509 certificate to be issued." The 
cross-technology aspect makes the wording weird, since you rarely consider 
self-delegation to be delegation. The only real addition here is the use of the 
proxy certificates to gain entry to the local Kerberos universe.

Short-lived "long term secrets" don't have this pedigree. Also, not real fond 
of transmitting the shared secret over the network, as required by B (even if 
it is a one-time-use thing. Makes me twitchy.) For that reason I might lean 
towards approach A, but would be happy with either.

Approach A has the client map the identities to generate the CSR. The IdP 
un-maps them to verify before issuing credentials. Seems this requires mapping 
strategy to be coordinated, perhaps standardized? Approach B, I presume, puts 
control of the mapping in the hands of the IdP? I assume this mapping would 
need to be coordinated with any realms to which this IPA is connected by trust, 
regardless of whether A or B is chosen? Things to think about...

> > Is seems that variant (B) should be really simple to code/script when
> > we have SAML/OpenID capable IdP.
> It can be done indeed.

I need to rework my RFE with diagrams to capture either A or B. Do you have a 
preference? Should I put both in as options?

One comment/question: in both A and B, step 1 seems superfluous? Gssapi/saml 
and gssapi/openid both support initial authentication, if no cached creds 
exist, I think. Could step one be dropped and/or integrated into step A3 or B2?

I'm still not understanding why transferring a TGT via a browser is more 
difficult than linking to a file-based representation of it and ensuring 
there's a "helper application" ready to handle that mime type on the client. 
(By "handle", I mean store in the local cache.)  Presumably, the IdP could 
communicate the reply key to the client securely, but that's more or less the 
same as transmitting the shared secret over the network. That puts the browser 
TGT solution on par with "B" for me. What I am seeing is two suggestions which 
eliminate the need for such a transfer, whether it be trivial or impossible. 
It's all good.


This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 

Freeipa-users mailing list

Reply via email to