[Freeipa-users] External Collaboration Domains

[Nordgren, Bryce L -FS]

> > 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 at 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 :-)


+1
+1

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.

Bryce




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 immediately.