On 04/15/2014 06:05 PM, Nordgren, Bryce L -FS wrote:
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 :-)
+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. :)
We already stole Dogtag. We will enable user certs support there. It is
the question of time and resources.
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?
Probably both but I do not like B too.
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 think so.
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.
There is already a way in the browser to deliver a cert or save a file.
The cert can also be sent by kerberos as was pointed out.
There is no capability in browser to save TGT into ticket cache. And I
am not sure it is a good idea to allow it to.
I also not sure about putty/ssh client making it support either of the
options would be a challenge.
(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.
Shared key approach looks like a hack and requires new concepts and new
features in the client.
Approach A required PKINIT. I am not sure It also would require
distributions of the "collaboration domain's CA certs".
In all proposals the weakest link is the client side.
If we can hide everything under GSSAPI would be best. Then we would not
need the client changes to applications (only latest GSSAPI,
configuration and certificates).
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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
