Subject: [kitten] Token Preauth for Kerberos

From: "Zheng, Kai" <[email-masked]>
Date: Tue, 10 Jun 2014 12:19:19 +0000

Hi all,

I would like to mention an effort regarding Kerberos and propose a new Kerberos preauth mechanism, token-preauth. Before dive into that, please kindly allow me to introduce, mainly for the background and scenario for the proposal.

I'm an engineer from Intel and develop identity and security related products. The current focus is Apache Hadoop, and our goal is enabling Hadoop to support more authentication mechanisms and providers. Currently Hadoop only supports Kerberos authentication method as the built-in secured one and it's not easy to add more since it involves changing into many projects on top of it in the large ecosystem. The community had proposed a token based authentication, planned to add TokenAuth method for Hadoop and by TokenAuth then all kinds of authentication providers can be supported since their authentication results can be wrapped into token, and the token can be employed to authenticate to Hadoop across the ecosystem. The effort is still undergoing. Considering the complexity, risk and deployment overhead of this approach, our team investigate and think of another possible solution, i.e. support token in Kerberos. The basic idea is allow end users to authenticate to Kerberos with their tokens and obtain tickets, then access Hadoop services using the tickets as current flow goes. The PoC was already done, and we make it work seamlessly from MIT Kerberos to Java world and Hadoop. However we think it's very important to get the key point token-preauth be reviewed by you security and Kerberos experts, to make sure it's defined and implemented in compliance with the existing standards and protocols, without involving security critical leaks. So please kindly give your feedback and we appreciate it.

The proposal - Kerberos token-preauth

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. According to configured certificate and public/private keys KDC decrypt and verify the token, and determines to issue ticket or not according to configured policy. The token itself will be wrapped into ticket as new authorization data and carried on to application server side. The tgt and derived service ticket resulted from token are not in much difference except the contained token and work exactly as normally. Besides that in application servers, token can be extracted from service ticket and employed further to do fine-grained authorization since the token can contain rich identity attributes.

POC implementation

1.       We implement a token-preauth plugin for MIT Kerberos like OTP one and it does all the necessary work that should be done for Kerberos itself in both client side and KDC side. We need update krb5.conf and kdc.conf to use and enable the mechanism. The plugin is a so module and can be separately installed/deployed. To protect token between client and KDC in KDC-REQ/KDC-REP exchanges, FAST must be used, therefore we suggest PKINIT be deployed also.

2.       For end users, we provide ktinit tool as follows:
ktinit -h
This tool uses token to authenticate to KDC and obtains tgt for you.
ktinit [-t token | -T token-cache-file] [-c kerb-ccache-file]
      when no token specified, ~/.tokenauth.token will be used by default

In the behind, it requests the needed armor ticket using PKINIT anonymous and then executes kinit with the armor ticket and token with -X option, gets tgt and puts the tgt in specified credential cache

3.       For JAVA application servers (Apache Hadoop services), we figured out how to extract token from service tickets from both GSSAPI layer and SASL layer.

It's planned to have a draft for this work. Our team is making effort to enable Kerberos to be easily deployed in large Hadoop clusters and big data platform and can integrate with other authn & authz solutions well from enterprise and internet. Thanks for your input, feedback and correction.

Regards,
Kai

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 10 Jun 2014 15:10:00 +0000

Kai,

I think a token-preauth mechanism would be a very
useful addition to the set of mechanisms that we
have today.  

When do you plan to submit the draft to the KITTEN
WG?

Best.

/thomas/

____________________________________________

From: Kitten [mailto:[email-masked]] On
Behalf Of Zheng, Kai
Sent: Tuesday, June 10, 2014 8:19 AM
To: [email-masked]; [email-masked]
Subject: [kitten] Token Preauth for Kerberos

Hi all,

I would like to mention an effort regarding
Kerberos and propose a new Kerberos preauth
mechanism, token-preauth. Before dive into that,
please kindly allow me to introduce, mainly for
the background and scenario for the proposal.

I’m an engineer from Intel and develop identity
and security related products. The current focus
is Apache Hadoop, and our goal is enabling Hadoop
to support more authentication mechanisms and
providers. Currently Hadoop only supports Kerberos
authentication method as the built-in secured one
and it’s not easy to add more since it involves
changing into many projects on top of it in the
large ecosystem. The community had proposed a
token based authentication, planned to add
TokenAuth method for Hadoop and by TokenAuth then
all kinds of authentication providers can be
supported since their authentication results can
be wrapped into token, and the token can be
employed to authenticate to Hadoop across the
ecosystem. The effort is still undergoing.
Considering the complexity, risk and deployment
overhead of this approach, our team investigate
and think of another possible solution, i.e.
support token in Kerberos. The basic idea is allow
end users to authenticate to Kerberos with their
tokens and obtain tickets, then access Hadoop
services using the tickets as current flow goes.
The PoC was already done, and we make it work
seamlessly from MIT Kerberos to Java world and
Hadoop. However we think it’s very important to
get the key point token-preauth be reviewed by you
security and Kerberos experts, to make sure it’s
defined and implemented in compliance with the
existing standards and protocols, without
involving security critical leaks. So please
kindly give your feedback and we appreciate it.

The proposal – Kerberos token-preauth

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. According to configured
certificate and public/private keys KDC decrypt
and verify the token, and determines to issue
ticket or not according to configured policy. The
token itself will be wrapped into ticket as new
authorization data and carried on to application
server side. The tgt and derived service ticket
resulted from token are not in much difference
except the contained token and work exactly as
normally. Besides that in application servers,
token can be extracted from service ticket and
employed further to do fine-grained authorization
since the token can contain rich identity
attributes.

POC implementation

1.       We implement a token-preauth plugin for
MIT Kerberos like OTP one and it does all the
necessary work that should be done for Kerberos
itself in both client side and KDC side. We need
update krb5.conf and kdc.conf to use and enable
the mechanism. The plugin is a so module and can
be separately installed/deployed. To protect token
between client and KDC in KDC-REQ/KDC-REP
exchanges, FAST must be used, therefore we suggest
PKINIT be deployed also.
2.       For end users, we provide ktinit tool as
follows:
ktinit -h
This tool uses token to authenticate to KDC and
obtains tgt for you.
ktinit [-t token | -T token-cache-file] [-c
kerb-ccache-file]
      when no token specified, ~/.tokenauth.token
will be used by default

In the behind, it requests the needed armor ticket
using PKINIT anonymous and then executes kinit
with the armor ticket and token with –X option,
gets tgt and puts the tgt in specified credential
cache
3.       For JAVA application servers (Apache
Hadoop services), we figured out how to extract
token from service tickets from both GSSAPI layer
and SASL layer.

It’s planned to have a draft for this work. Our
team is making effort to enable Kerberos to be
easily deployed in large Hadoop clusters and big
data platform and can integrate with other authn &
authz solutions well from enterprise and internet.
Thanks for your input, feedback and correction.

Regards,
Kai

---

From: Greg Hudson <[email-masked]>
Date: Tue, 10 Jun 2014 12:30:06 -0400

On 06/10/2014 08:19 AM, Zheng, Kai wrote:
> This proposes to add another preauthentication mechanism similar to OTP
> and PKINIT for Kerberos, based on Kerberos preauthentication framework
> and FAST tunnel. It allows 3^rd 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.

Without knowing more details, here are three areas where there might be
concerns:

1. How is the reply key computed during an AS request?

I am guessing that you took the OTP approach of using the FAST armor key
as the reply key.  This is not ideal, but may be the path of least
resistance if you have to work with bearer tokens.  The limitations of
this approach are:

* It precludes the preauth mechanism from working securely inside FAST
channels which do not authenticate the KDC (such as anonymous PKINIT
channels without KDC certificate verification).

* It means any holder of the FAST armor key (e.g. someone who has the
host keytab) can passively observe the exchange and decrypt the ticket,
not just the holder of some user-specific authentication secret.

If you use holder-of-key tokens instead of bearer tokens, the key can be
used in one of several ways to more securely establish a reply key.

The last time I talked about this with Sam Hartman in person, he
suggested that perhaps mechanisms which can't securely establish a reply
key should be doing an unauthenticated DH exchange within the FAST
channel, which would prevent a passive observer with the armor key from
decrypting the ticket.  That would add a lot of complexity and have a
performance impact, however.

2. Can a service impersonate the client to other services?

If you're handing out client bearer tokens to each service the client
authenticates to, and the bearer token can be used to obtain a TGT, then
a service can use that bearer token to get its own TGT and authenticate
as the user to other services.

This problem goes away if the bearer tokens are restricted to particular
services and the KDC doesn't issue TGTs.  The client would make an AS
request for a specific server (identified in the bearer token) and get a
service ticket for that server directly, without making a TGS request.
The service can then only impersonate a user to itself, which is harmless.

3. Is the authdata correctly packaged?

In the Kerberos 5 authdata model, the KDC is assumed to blindly pass
through authdata requested by the client.  If the authdata is to be
trusted by the target service as something vetted by the KDC, it needs
to be packaged accordingly.

The traditional method for doing this is a container called
AD-KDC-ISSUED which contains a checksum for the authdata in a key which
cannot be known (in advance) by the client.  This container has not seen
much practical use, and it turns out that RFC 4120 says conflicting
things about which key to use for the checksum.  To the extent that
there are implementations, they use the ticket session key.

A more recent container for this purpose is AD-CAMMAC, as specified in:

    http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-01

In addition to not having key ambiguity issues, AD-CAMMAC also contains
a KDC verifier which allows the authdata to be propagated through an
S4U2Proxy request.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 10 Jun 2014 20:56:41 +0000

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

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 11 Jun 2014 06:47:07 +0000

Hi Thomas,

Thanks for your confirm and encouraging. I think the feedback and input from the community for the idea are very important,
so please kindly allow me to understand them and prepare well for the initial draft for your review. Thanks.

Regards,
Kai

-----Original Message-----
From: Kitten [mailto:[email-masked]] On Behalf Of Thomas Hardjono
Sent: Tuesday, June 10, 2014 11:10 PM
To: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

Kai,

I think a token-preauth mechanism would be a very useful addition to the set of mechanisms that we have today.  

When do you plan to submit the draft to the KITTEN WG?

Best.

/thomas/

From: Kitten [mailto:[email-masked]] On Behalf Of Zheng, Kai
Sent: Tuesday, June 10, 2014 8:19 AM
To: [email-masked]; [email-masked]
Subject: [kitten] Token Preauth for Kerberos

Hi all,

I'm an engineer from Intel and develop identity and security related products. The current focus is Apache Hadoop, and our goal is enabling Hadoop to support more authentication mechanisms and providers. Currently Hadoop only supports Kerberos authentication method as the built-in secured one and it's not easy to add more since it involves changing into many projects on top of it in the large ecosystem. The community had proposed a token based authentication, planned to add TokenAuth method for Hadoop and by TokenAuth then all kinds of authentication providers can be supported since their authentication results can be wrapped into token, and the token can be employed to authenticate to Hadoop across the ecosystem. The effort is still undergoing.
Considering the complexity, risk and deployment overhead of this approach, our team investigate and think of another possible solution, i.e.
support token in Kerberos. The basic idea is allow end users to authenticate to Kerberos with their tokens and obtain tickets, then access Hadoop services using the tickets as current flow goes.
The PoC was already done, and we make it work seamlessly from MIT Kerberos to Java world and Hadoop. However we think it's very important to get the key point token-preauth be reviewed by you security and Kerberos experts, to make sure it's defined and implemented in compliance with the existing standards and protocols, without involving security critical leaks. So please kindly give your feedback and we appreciate it.

POC implementation

In the behind, it requests the needed armor ticket using PKINIT anonymous and then executes kinit with the armor ticket and token with -X option, gets tgt and puts the tgt in specified credential cache 3.       For JAVA application servers (Apache Hadoop services), we figured out how to extract token from service tickets from both GSSAPI layer and SASL layer.

It's planned to have a draft for this work. Our team is making effort to enable Kerberos to be easily deployed in large Hadoop clusters and big data platform and can integrate with other authn & authz solutions well from enterprise and internet.
Thanks for your input, feedback and correction.

Regards,
Kai

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 11 Jun 2014 08:15:32 +0000

Hi Greg,

Thanks for your valuable feedback and suggestions!

1. Yes you're right I'm taking the OTP approach and use the FAST armor key as the reply key. As mentioned in the proposal we suggest PKINIT be deployed along with this mechanism,
And client uses PKINIT anonymous to obtain the armor ticket. It doesn't provide mutual authentication since only KDC is authenticated to client with the configured certificate of KDC and 
client doesn't due to lacking of certificate as to avoid the deployment overhead in our solution. So protecting the token here in AS-REQ exchange mainly depends on the FAST tunnel and
client should be careful about the armor ticket.

I agree using Holder-of-Key token is much secure. Does that mean KDC needs to authenticate client and user still needs to provide credential like password right. Perhaps we could support 
both since they're useful in different situations and requirements.

2. Can a service impersonate the client to other services? It depends. Sometimes we want to avoid the impersonation as you mentioned for security concern, sometimes it's desired like 
we might consider to support similar flows as S4U2Self and S4U2Proxy. What do you think about this? Could we do it in a restricted way like constrained delegation? At least if we have to 
avoid the impersonation, sure we can consider your suggestion and don't get tgt but get service ticket directly using token. A problem would be it's hard for now to make it work in JAVA 
because using tgt requesting service ticket is buried in JRE and we can't hack into it. Getting tgt using token works well because we can put the credential into cache then JRE picks it from the cache file
to request service ticket without extra effort. Another way to avoid the impersonation would be we don't pass token to service. Since only token attributes are really needed for authorization stuff 
so KDC could just emit the token attributes into service ticket and don't put the token into it. But I'm not very sure if token itself is desired or not in more general cases.

3. Yes we considered support packing the new authorization data type, though not in AD-KDC-ISSUED, AD-IF-RELEVANT instead. We would encrypt the data using the server key probably as MS-PAC
does. Sure we can use more secure way if it doesn't involve too much deployment overhead for services.

Please help clarify and correct, and again thanks for your great input.

Regards,
Kai

-----Original Message-----
From: Greg Hudson [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2014 12:30 AM
To: Zheng, Kai; [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

On 06/10/2014 08:19 AM, Zheng, Kai wrote:
> framework and FAST tunnel. It allows 3^rd party token in JWT format 
> KDC for a normal principal instead of user password.

I am guessing that you took the OTP approach of using the FAST armor key as the reply key.  This is not ideal, but may be the path of least resistance if you have to work with bearer tokens.  The limitations of this approach are:

* It precludes the preauth mechanism from working securely inside FAST channels which do not authenticate the KDC (such as anonymous PKINIT channels without KDC certificate verification).

* It means any holder of the FAST armor key (e.g. someone who has the host keytab) can passively observe the exchange and decrypt the ticket, not just the holder of some user-specific authentication secret.

If you use holder-of-key tokens instead of bearer tokens, the key can be used in one of several ways to more securely establish a reply key.

The last time I talked about this with Sam Hartman in person, he suggested that perhaps mechanisms which can't securely establish a reply key should be doing an unauthenticated DH exchange within the FAST channel, which would prevent a passive observer with the armor key from decrypting the ticket.  That would add a lot of complexity and have a performance impact, however.

If you're handing out client bearer tokens to each service the client authenticates to, and the bearer token can be used to obtain a TGT, then a service can use that bearer token to get its own TGT and authenticate as the user to other services.

This problem goes away if the bearer tokens are restricted to particular services and the KDC doesn't issue TGTs.  The client would make an AS request for a specific server (identified in the bearer token) and get a service ticket for that server directly, without making a TGS request.
The service can then only impersonate a user to itself, which is harmless.

In the Kerberos 5 authdata model, the KDC is assumed to blindly pass through authdata requested by the client.  If the authdata is to be trusted by the target service as something vetted by the KDC, it needs to be packaged accordingly.

The traditional method for doing this is a container called AD-KDC-ISSUED which contains a checksum for the authdata in a key which cannot be known (in advance) by the client.  This container has not seen much practical use, and it turns out that RFC 4120 says conflicting things about which key to use for the checksum.  To the extent that there are implementations, they use the ticket session key.

In addition to not having key ambiguity issues, AD-CAMMAC also contains a KDC verifier which allows the authdata to be propagated through an S4U2Proxy request.

---

From: Peter Mogensen <[email-masked]>
Date: Wed, 11 Jun 2014 14:20:58 +0200

Hi,

Greg Hudson summes up the situation fine here. I feel the urge to 
comment. (below)

> a KDC verifier which allows the authdata to be propagated through an

I did some work to implement RFC6806 AD-LOGIN-ALIAS which requires 
AD-KDC-ISSUED and noticed the ambiguity in RFC4120 regarding which key 
to use for the checksum.
I also noticed that AD-CAMMAC explicitly uses the service-key (and not 
the ticket session key) to do the same.
... and that to embed a ~10 bytes username in a ticket as AD-LOGIN-ALIAS 
I end up increasing the ticket size with about 110 bytes. - which is a 
rather significant increase if you are worried about ticket sizes.

So, I wonder... is this really the optimal way to extend a ticket with 
verified information?
If I just wanted to verify the login-alias to the service it seems like 
a waste of ~100 bytes to checksum it with the service-key (like RFC4120 
also states). If it wasn't for the authdata-model Greg describes above, 
where the DC is assumed to blindly pass through authdata requested by 
the client, then no checksum would have been needed. The ticket it self 
would protect the integrity of the field. (and saving ~100 bytes ticket 
size).

It seems to me that a lot of complexity in verifying authdata originates 
from this authdata model where the client can put anything it likes in 
the authorization-data. This is of course useful for negative 
authorization, but makes things complicated for positive authorization 
data. (like simple info the KDC just want to assert to the service, like 
AD-LOGIN-ALIAS)

The solution in AD-CAMMAC seems very complex too, requiring effectively 
calculating the entire EncTicketPart twice - and once for every present 
AD-CAMMAC present.

Things would have been much simpler if there were an authdata field in a 
ticket outside of the clients control. Now, - I know - there's probably 
very good reasons why extending the EncTicketPart and Ticket definitions 
is difficult, but...

In an ideal world, maybe something like:

EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
         flags                   [0] TicketFlags,
         key                     [1] EncryptionKey,
         crealm                  [2] Realm,
         cname                   [3] PrincipalName,
         transited               [4] TransitedEncoding,
         authtime                [5] KerberosTime,
         starttime               [6] KerberosTime OPTIONAL,
         endtime                 [7] KerberosTime,
         renew-till              [8] KerberosTime OPTIONAL,
         caddr                   [9] HostAddresses OPTIONAL,
         authorization-data      [10] AuthorizationData OPTIONAL
         protected-authdata      [11] AuthorizationData OPTIONAL
}

Where the client can't add to "protected-authdata".
This would make the AD-KDC-ISSUED and svc-verifier of AD-CAMMAC redundant.

( It would also relieve the clients from having to verify every 
AD-KDC-ISSUED element in order to find the one it's interested in - of 
course, this is an API artifact of libkrb5's 
krb5_verify_authdata_kdc_issued(). )

And then:

Ticket          ::= [APPLICATION 1] SEQUENCE {
         tkt-vno         [0] INTEGER (5),
         realm           [1] Realm,
         sname           [2] PrincipalName,
         enc-part        [3] EncryptedData -- EncTicketPart
         kdc-verifier    [4] Verifier-MAC OPTIONAL,
}

Which would solve the S4U2proxy use case mentioned where the KDC needs 
to protect the Ticket from tampering by the service.
Of course this changes some of the binding semantics of the current 
AD-CAMMAC draft. Specically this now binds all authdata together with 
one checksum. But the kdc-verifier cannot be verified without the Ticket 
anyway.

This would also make the need for a special AD-CAMMAC limited to 
providing for "other-verifiers"

I realize that it's non-trivial to extend these ASN.1 definitions, but 
something similar was suggested in draft-ietf-krb-wg-ticket-extensions

To do the above example there will also have to be API-changes. Like 
krb5_find_authdata() needs to know about this.
But it seems AD-CAMMAC will require minor API changes too, since it uses 
the service-key and not the session-key like implementations of 
AD-KDC-ISSUED (as Greg mentioned). Using the session-key is a lot easier 
for client verification. Using the service-key would probably need 
krb5_rd_req() to verify AD-CAMMAC to avoid the application having to 
look up its service-key independently .

So maybe it's worth investigating if there's anyway to provide 
verified/signed AD-DATA in a simpler way, requiring smaller tickets and 
less computation when signing/verifying.

I hope these thoughts are not so naive that the answer is that it will 
require a new protocol version or a new tkt-vno... ;-)

/Peter

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 11 Jun 2014 13:28:40 +0000

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:[email-masked]] 
Sent: Wednesday, June 11, 2014 4:57 AM
To: Zheng, Kai; [email-masked]; [email-masked]
Subject: RE: Token Preauth for Kerberos

>and FAST tunnel. It allows 3rd party token in JWT format like OAuth 
>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.

Bryce

---

From: "Zheng, Kai" <[email-masked]>
Date: Wed, 11 Jun 2014 13:42:56 +0000

-----Original Message-----
From: Kitten [mailto:[email-masked]] On Behalf Of Zheng, Kai
Sent: Wednesday, June 11, 2014 9:29 PM
To: Nordgren, Bryce L -FS; [email-masked]; [email-masked]
Cc: Jiang, Weihua
Subject: Re: [kitten] Token Preauth for Kerberos

Hi Bryce,

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?

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?  

Regards,
Kai

-----Original Message-----
From: Nordgren, Bryce L -FS [mailto:[email-masked]]
Sent: Wednesday, June 11, 2014 4:57 AM
To: Zheng, Kai; [email-masked]; [email-masked]
Subject: RE: Token Preauth for Kerberos

Very cool.

Bryce

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Simo Sorce <[email-masked]>
Date: Wed, 11 Jun 2014 12:17:24 -0400

On Wed, 2014-06-11 at 14:20 +0200, Peter Mogensen wrote:
> The solution in AD-CAMMAC seems very complex too, requiring
> effectively calculating the entire EncTicketPart twice - and once for
> every present AD-CAMMAC present.

I am confused about this statement. The AD-CAMMAC draft specifies that
it contains a sequence of AD elements, that means you have only 1
AD-CAMMAC for all the AD data you want to protect. You check the whole
thing only once.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Peter Mogensen <[email-masked]>
Date: Wed, 11 Jun 2014 19:02:46 +0200

> AD-CAMMAC for all the AD data you want to protect. You check the whole

I were not sure whether you could rule out any use case requiring 
merging of 2 AD-CAMMAC elements with - say - different other-verifier 
checksums for which the KDC didn't have all the keys.
But I guess that since other-verifier restricts the principals to be in 
the KDC realm, that could not happen.

Still... the whole EncTicketPart has to be constructed and DER-encoded 
twice to add a kdc-verifier.

/Peter

---

From: Simo Sorce <[email-masked]>
Date: Wed, 11 Jun 2014 13:08:10 -0400

> twice to add a kdc-verifier.

That is done to bind the CAMMAC to a specific ticket, it is an
additional protection that you probably want for your use case too.

Simo.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 11 Jun 2014 10:52:04 -0400

> client should be careful about the armor ticket.

You may be interested in this proposal:
http://mailman.mit.edu/pipermail/krbdev/2014-May/011958.html

Nathaniel

---

From: Peter Mogensen <[email-masked]>
Date: Thu, 12 Jun 2014 09:12:12 +0200

> additional protection that you probably want for your use case too.

Sure... any solution to the S4U2proxy use case would require protecting 
the ticket and attached authdata, which the KDC has to trust against 
service tampering.
As the cammac draft says:
"...assuring the KDC that a malicious service has not substituted a 
mismatched CAMMAC received from another ticket."

But if the kdc-verifier was placed out side the EncTicketPart, then that 
would also provide that protection and not require computing the ticket 
twice - right?

/Peter

---

From: Simo Sorce <[email-masked]>
Date: Thu, 12 Jun 2014 08:47:12 -0400

> the ticket and attached authdata, which the KDC has to trust against 

Sorry, no, the binding to the specific ticket is not a requirement for
s4u2proxy. The only requirement there is the KDC MAC which could be done
the same way as the SVC MAC.

> would also provide that protection and not require computing the ticket 

Exactly, the computing of EncTicketPart is used to bind the CAMMAC to a
specific TGT, it is an additional feature that basically allows you to
bind service tickets back to the original TGT and back to the original
AS Request (assuming you keep track of that information via some sort of
auditing logs and perhaps a new AD with a session number).

Simo.

---

From: Peter Mogensen <[email-masked]>
Date: Thu, 12 Jun 2014 14:55:29 +0200

> the same way as the SVC MAC.

Doesn't that depend on what any authdata plugin at the KDC might need to 
do with any authdata in the evidence ticket when processing the 
S4U2proxy TGS?
Such authdata in the evidence ticket could be something which the KDC 
would be in a position to verify in the principal database and issue a 
fresh copy.
But it could also be that the KDC had to trust the authdata in the 
evidence ticket at copy that information into the issued ticket.
In that case, you would need to protect against a service inserting 
authdata from another ticket into the evidence ticket.

/Peter

---

From: Simo Sorce <[email-masked]>
Date: Thu, 12 Jun 2014 09:01:00 -0400

> do with any authdata in the evidence ticket when processing the 

Yes, but we could as well have added just the principal name and the
expiration time of the authdata owner as an AD inside the CAMMAC, and
that was considered. But in the end we found more useful to just add all
the data from EncTicketPart as it included all the above and
additionally bind to the ticket.

> would be in a position to verify in the principal database and issue a 

Yes there are plans see the old draft about PAD which we put on hold
until CAMMAC was ready, that is an example of what you say.

> authdata from another ticket into the evidence ticket.

Yes, we decided to combine this protection with ticket binding in one
single operation by using EncTicketPart in the MAC calculation, makign
the CAMMAC *simpler* to build.

Simo.

---

From: Peter Mogensen <[email-masked]>
Date: Thu, 12 Jun 2014 15:19:53 +0200

> the CAMMAC *simpler* to build.

I must have misunderstood something fundamental then.

The draft says:
"the KDC computes the MAC in the kdc-
       verifier over the ASN.1 DER encoding of the EncTicketPart of the
       surrounding ticket, *but* where the AuthorizationData value in the
       EncTicketPart contains the AuthorizationData value contained in
       the CAMMAC instead of the AuthorizationData value that would
       otherwise be present in the ticket."

(My emphasis)

So it's not the actual EncTicketPart which is used for the MAC. It's 
another version with different AuthorizationData. You have to compute 
both versions.
Compared to simply just placing the kdc-verifier outside of the 
EncTicketPart and using the actual EncTicketPart for computing the MAC.
... which I know can give compatability problems, but just so we 
understand what each other is talking about.

I would intuitively think it was simpler to just sign the entire actual 
EncTicketPart with the kdc-verifier. Of course, that will then bind to 
also any other authdata in the ticket.

/Peter

---

From: Simo Sorce <[email-masked]>
Date: Thu, 12 Jun 2014 09:23:25 -0400

> also any other authdata in the ticket.

The idea is to compute MAC on:

1) EncTicketPart w/o any Authorization Data (otherwise chicken-egg as
you are still computing AD data, CAMMAC is AD data itself)
+
2) AD Data contained in CAMMAC (we want to protect data within the
CAMMAC, anything outside of it is not our business).

Makes sense ?

Simo.

---

From: Peter Mogensen <[email-masked]>
Date: Thu, 12 Jun 2014 15:38:14 +0200

> CAMMAC, anything outside of it is not our business).

Yes. And that's also the way I've read the draft and which is the basis 
for what I wrote.

So, do you agree that the chicken-egg problem in 1) would also have been 
solved if the kdc-verifier were placed in the ticket outside of the 
EncTicketPart?

Are you saying that computing EncTicketPart w/o any Authorization Data + 
computing the final EncTicketPart is simpler than just computing the 
final EncTicketPart?

And is it correct that even though AD not in the CAMMAC is not our 
business it doesn't make much difference whether it's included in the 
kdc-verifier, since it can only be verified having that specific ticket 
anyway?

In an ideal world I would have considered placing the kdc-verifier 
outside of EncTicketPart more intutive.

Anyway... I guess my primary grief is not the kdc-verifier, but the 
svc-verifier and that just adding a small piece of data in AD-CAMMAC to 
a ticket will increase its size from 400-500 bytes (AFAIR) to >600. 
About 20%. That's a problem if you try to squeeze several tickets into 1 
IP packet. ... and it seems like only necessary because of the rule that 
the client can add anything to authorization-data. Otherwise the data 
would already have been protected by the service-key once.

/Peter

---

From: Simo Sorce <[email-masked]>
Date: Thu, 12 Jun 2014 09:50:04 -0400

> would already have been protected by the service-key once.

We have to work within the framework of RFC 4120 I am afraid, so it is
what it is.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Thu, 12 Jun 2014 17:37:18 -0400

On Tue, 2014-06-10 at 12:19 +0000, Zheng, Kai wrote:
> Hi all,
> 
> I would like to mention an effort regarding Kerberos and propose a new
> Kerberos preauth mechanism, token-preauth. Before dive into that,
> please kindly allow me to introduce, mainly for the background and
> scenario for the proposal.
> 
> I'm an engineer from Intel and develop identity and security related
> products. The current focus is Apache Hadoop, and our goal is enabling
> Hadoop to support more authentication mechanisms and providers.
> Currently Hadoop only supports Kerberos authentication method as the
> built-in secured one and it's not easy to add more since it involves
> changing into many projects on top of it in the large ecosystem. The
> community had proposed a token based authentication, planned to add
> TokenAuth method for Hadoop and by TokenAuth then all kinds of
> authentication providers can be supported since their authentication
> results can be wrapped into token, and the token can be employed to
> authenticate to Hadoop across the ecosystem. The effort is still
> undergoing. Considering the complexity, risk and deployment overhead
> of this approach, our team investigate and think of another possible
> solution, i.e. support token in Kerberos. The basic idea is allow end
> users to authenticate to Kerberos with their tokens and obtain
> tickets, then access Hadoop services using the tickets as current flow
> goes. The PoC was already done, and we make it work seamlessly from
> MIT Kerberos to Java world and Hadoop. However we think it's very
> important to get the key point token-preauth be reviewed by you
> security and Kerberos experts, to make sure it's defined and
> implemented in compliance with the existing standards and protocols,
> without involving security critical leaks. So please kindly give your
> feedback and we appreciate it.

Kai,
have you considered protocol transition (s4u2self) + constrained
delegation (s4u2proxy) to get tickets at an authentication gateway
instead of a new pre auth mechanism ?

Simo.

---

From: "Zheng, Kai" <[email-masked]>
Date: Fri, 13 Jun 2014 07:16:19 +0000

Hi Simo,

>> have you considered protocol transition (s4u2self) + constrained delegation (s4u2proxy) to get tickets at an authentication gateway instead of a new pre auth mechanism ?

Yes we proposed for the Hadoop community a centralized Authn & Authz Server (HAS) that might be like the gateway as you mentioned. It's widely discussed and confirmed that it would be great the server allows plugin of authentication module/provider but all mechanisms output token. Sure I guess it's possible to use token to go thru s4u2self and s4u2proxy in the Kerberos facility across the ecosystem but as far as I know JRE just starts to support it from JDK8. Anyhow I would check this and make sure it's a doable option not in so long future.

A question regarding this:
Is it possible to contain the token in service ticket resulted from s4u2self and s4u2proxy as authorization data so that services can get it as proposed in token-preauth? Note in our wanted solution, token not just serves for authentication, but also is meant to be passed (or the token attributes) to service side for fine-grained authorization.

Thanks & regards,
Kai

-----Original Message-----
From: Simo Sorce [mailto:[email-masked]] 
Sent: Friday, June 13, 2014 5:37 AM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

> feedback and we appreciate it.

Kai,
have you considered protocol transition (s4u2self) + constrained delegation (s4u2proxy) to get tickets at an authentication gateway instead of a new pre auth mechanism ?

Simo.

---

From: "Zheng, Kai" <[email-masked]>
Date: Fri, 13 Jun 2014 07:31:08 +0000

Hi Max,

Would you help clarify the support situation or plan/schedule in JRE/JDK for the mentioned protocol transition (s4u2self) + constrained delegation (s4u2proxy) if I'm not correct? Thanks.

Regards,
Kai

-----Original Message-----
From: Zheng, Kai 
Sent: Friday, June 13, 2014 3:16 PM
To: 'Simo Sorce'
Cc: [email-masked]; [email-masked]
Subject: RE: [kitten] Token Preauth for Kerberos

Hi Simo,

Thanks & regards,
Kai

-----Original Message-----
From: Simo Sorce [mailto:[email-masked]]
Sent: Friday, June 13, 2014 5:37 AM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

Kai,

Simo.

---

From: Wang Weijun <[email-masked]>
Date: Fri, 13 Jun 2014 15:35:04 +0800

JDK 8 has S4U2self and S4U2proxy, but it hasn't been tested in the real world. Also, client, service and backend service must be in the same realm now, since referral is still not supported.

--Max

---

From: "Zheng, Kai" <[email-masked]>
Date: Fri, 13 Jun 2014 07:40:25 +0000

Got it, thanks Max.

-----Original Message-----
From: Wang Weijun [mailto:[email-masked]] 
Sent: Friday, June 13, 2014 3:35 PM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]; Simo Sorce
Subject: Re: [kitten] Token Preauth for Kerberos

--Max

On Jun 13, 2014, at 15:31, Zheng, Kai <[email-masked]> wrote:

>> I would like to mention an effort regarding Kerberos and propose a 
>> new Kerberos preauth mechanism, token-preauth. Before dive into that, 
>> products. The current focus is Apache Hadoop, and our goal is 
>> enabling Hadoop to support more authentication mechanisms and providers.
>> tickets, then access Hadoop services using the tickets as current 
>> flow goes. The PoC was already done, and we make it work seamlessly 
>> from MIT Kerberos to Java world and Hadoop. However we think it's 
>> very important to get the key point token-preauth be reviewed by you

---

From: "Zheng, Kai" <[email-masked]>
Date: Fri, 13 Jun 2014 08:07:50 +0000

Nathaniel,

Yes I like the idea and hopefully token-preauth mechanism can benefit from it. Thanks.

Regards,
Kai

-----Original Message-----
From: Nathaniel McCallum [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2014 10:52 PM
To: Zheng, Kai
Cc: Greg Hudson; [email-masked]; [email-masked]; Jiang, Weihua
Subject: Re: [kitten] Token Preauth for Kerberos

On Wed, 2014-06-11 at 08:15 +0000, Zheng, Kai wrote:
> 1. Yes you're right I'm taking the OTP approach and use the FAST armor 
> key as the reply key. As mentioned in the proposal we suggest PKINIT 
> be deployed along with this mechanism, And client uses PKINIT 
> anonymous to obtain the armor ticket. It doesn't provide mutual authentication since only KDC is authenticated to client with the configured certificate of KDC and client doesn't due to lacking of certificate as to avoid the deployment overhead in our solution. So protecting the token here in AS-REQ exchange mainly depends on the FAST tunnel and client should be careful about the armor ticket.

Nathaniel

---

From: Simo Sorce <[email-masked]>
Date: Fri, 13 Jun 2014 08:41:17 -0400

On Fri, 2014-06-13 at 07:16 +0000, Zheng, Kai wrote:
> Yes we proposed for the Hadoop community a centralized Authn & Authz
> Server (HAS) that might be like the gateway as you mentioned. It's
> widely discussed and confirmed that it would be great the server
> allows plugin of authentication module/provider but all mechanisms
> output token. Sure I guess it's possible to use token to go thru
> s4u2self and s4u2proxy in the Kerberos facility across the ecosystem
> but as far as I know JRE just starts to support it from JDK8. Anyhow I
> would check this and make sure it's a doable option not in so long
> future.

You need to modify something anyway, constrained delegation sound like a
better way than trying to devise a whole new pre-auth plugin.

> Is it possible to contain the token in service ticket resulted from
> s4u2self and s4u2proxy as authorization data so that services can get
> it as proposed in token-preauth? Note in our wanted solution, token
> not just serves for authentication, but also is meant to be passed (or
> the token attributes) to service side for fine-grained authorization.

Well, theorethically it should be possible to ad AD data in the ticket
before the s4u2proxy call and the KDC should just preserve it.
However you should only transmit the authorization data, not the whole
token, otherwise you destroy every single security property of Kerberos.
I can't see any krb admin as accepting something like that.

Simo.

---

From: "Zheng, Kai" <[email-masked]>
Date: Tue, 17 Jun 2014 05:35:23 +0000

>> You need to modify something anyway, constrained delegation sound like a better way than trying to devise a whole new pre-auth plugin.
As far as I know s4u2self & s4u2proxy plus contrained delegation are from MS and I'm not sure we could modify it as we need. A new token-preauth based on existing Kerberos and framework is more preferred for us since the plugin is easy to deploy, also we believe the mechanism using JWT token will open the door to integrate Kerberos with OAuth.

>>However you should only transmit the authorization data, not the whole token, otherwise you destroy every single security property of Kerberos.
Yes I agree. As discussed with Greg and also said here in my previous email, we will not pass the token itself to service, instead token attributes or the derivation that can't be used to authenticate with KDC. 

Thanks for your feedback.

Regards,
Kai

-----Original Message-----
From: Simo Sorce [mailto:[email-masked]] 
Sent: Friday, June 13, 2014 8:41 PM
To: Zheng, Kai
Cc: [email-masked]; [email-masked]
Subject: Re: [kitten] Token Preauth for Kerberos

> would check this and make sure it's a doable option not in so long 

You need to modify something anyway, constrained delegation sound like a better way than trying to devise a whole new pre-auth plugin.

> the token attributes) to service side for fine-grained authorization.

Well, theorethically it should be possible to ad AD data in the ticket before the s4u2proxy call and the KDC should just preserve it.
However you should only transmit the authorization data, not the whole token, otherwise you destroy every single security property of Kerberos.
I can't see any krb admin as accepting something like that.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Tue, 17 Jun 2014 08:43:29 -0400

On Tue, 2014-06-17 at 05:35 +0000, Zheng, Kai wrote:
> >> You need to modify something anyway, constrained delegation sound
> like a better way than trying to devise a whole new pre-auth plugin.
> As far as I know s4u2self & s4u2proxy plus contrained delegation are
> from MS and I'm not sure we could modify it as we need. A new
> token-preauth based on existing Kerberos and framework is more
> preferred for us since the plugin is easy to deploy, also we believe
> the mechanism using JWT token will open the door to integrate Kerberos
> with OAuth.

I think AD data can be added with s4u2self/s4u2proxy as well, what other
modifications do you have in mind ?

> >>However you should only transmit the authorization data, not the
> whole token, otherwise you destroy every single security property of
> Kerberos.
> Yes I agree. As discussed with Greg and also said here in my previous
> email, we will not pass the token itself to service, instead token
> attributes or the derivation that can't be used to authenticate with
> KDC. 

Do you have a standardized AD element in mind, or are you going to
define a new one ?

Simo.