Token Preauth for Kerberos

[Zheng, Kai]

Hi Bryce,

Thanks for your interest and valuable input.

The proposal assumes identities from 3rd party identity system are already synced with KDC backend identity store, either by manually or automatic process, 
either from other identity system to KDC or from KDC to other identity system. It assumes token authority against the identity system can issue JWT token
with defined header attributes by this mechanism, so that Kerberos and the mechanism can determine the principal and realm based on the token as 
target client principal to issue ticket.

However, I understand it's important to also consider the sync process between other identity system and KDC backend store for the users/principals that
need to do token authentication against KDC. It might be covered in this work but better in future version, or another effort. So far I just have some questions
as follows.
1. Could we define standard admin protocol to allow automatic user/principal sync between target identity system and KDC in both directions? Can kx509 
help here or other lightweight approach? Sure the process should be done in separate secure channel by KDC admin. Can the sync be done in acceptable time?

2. Related, is there any existing standard or practice to dynamically provisioning or destroying Kerberos principal accounts on demand in batch mode or one by one? 
This could be useful in large cluster with thousands of nodes (each requires quite a few service principals).

3. Could we relax Kerberos further, allow KDC issue ticket for non-exist principal and just determine the principal using defined token attributes (or mapping)? I'm not 
very sure this makes sense since this may violate Kerberos protocol but think about in some cases Kerberos can be just used as secure channel like SSL and the primary
authentication is already done for token prior to ticket requesting. Or if principal is absolutely a must and should be exist in KDC backend anyway, could it be dynamically
provisioned in the client request channel when KDC find the principal isn't exist but the KDC policy allows to create it right now?  

>> Is your MIT krb5 plugin code somewhere public?
Well I would clean up the POC codes and make it look better. When it's ready we'll make it public and update here. Hope this can be done soon.

Regards,
Kai

-----Original Message-----
From: Nordgren, Bryce L -FS [mailto:bnordgren at fs.fed.us] 
Sent: Wednesday, June 11, 2014 4:57 AM
To: Zheng, Kai; kitten at ietf.org; krbdev at mit.edu
Subject: RE: Token Preauth for Kerberos

>This proposes to add another preauthentication mechanism similar to OTP 
>and PKINIT for Kerberos, based on Kerberos preauthentication framework 
>and FAST tunnel. It allows 3rd party token in JWT format like OAuth 
>bearer token can be used as credential to authenticate to KDC for a 
>normal principal instead of user password. When using the token to 
>request a tgt, the user name or other attributes claimed in the token 
>must match the target Kerberos principal. PKI is used to establish the 
>trust relationship between 3rd party token issuer and KDC.

Very cool.

Might I ask how you map identities from the 3rd party scheme into the Kerberos PRINCIPAL at REALM scheme? I assume from the above that the actual binding is performed using a kx509 certificate issued by a trusted CA? Is there a proposed algorithm to generate Kerberos identities from 3rd party ones, or is this a function of the CA?

Let me back up a bit. Is this being proposed as a gateway such that identities from 3rd party identity systems have a standardized representation in Kerberos (thus ensuring that tokens and Kerberos identities are correctly associated)? Or is this a means for manually created users in the local KDC to use their "regular" password? If the latter, how does one ensure that the same person is in control of the Kerberos identity and the external one?

Bryce
PS: Is your MIT krb5 plugin code somewhere public? :)






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.