Token Preauth for Kerberos

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Token Preauth for Kerberos

drankye
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 wit!
 h 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 applicatio!
 n 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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Token Preauth for Kerberos

Thomas Hardjono
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:[hidden email]] On
Behalf Of Zheng, Kai
Sent: Tuesday, June 10, 2014 8:19 AM
To: [hidden email]; [hidden email]
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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Token Preauth for Kerberos

Greg Hudson
In reply to this post by drankye
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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Token Preauth for Kerberos

Nordgren, Bryce L -FS
In reply to this post by drankye
>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.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Token Preauth for Kerberos

drankye
In reply to this post by Thomas Hardjono
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:[hidden email]] On Behalf Of Thomas Hardjono
Sent: Tuesday, June 10, 2014 11:10 PM
To: [hidden email]; [hidden email]
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:[hidden email]] On Behalf Of Zheng, Kai
Sent: Tuesday, June 10, 2014 8:19 AM
To: [hidden email]; [hidden email]
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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: [kitten] Token Preauth for Kerberos

drankye
In reply to this post by Greg Hudson
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:[hidden email]]
Sent: Wednesday, June 11, 2014 12:30 AM
To: Zheng, Kai; [hidden email]; [hidden email]
Subject: Re: [kitten] Token Preauth for Kerberos

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.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Verified authorization data

Peter Mogensen
In reply to this post by Greg Hudson
Hi,

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

On 2014-06-10 18:30, Greg Hudson wrote:

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


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



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Token Preauth for Kerberos

drankye
In reply to this post by Nordgren, Bryce L -FS
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:[hidden email]]
Sent: Wednesday, June 11, 2014 4:57 AM
To: Zheng, Kai; [hidden email]; [hidden email]
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@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.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Token Preauth for Kerberos

drankye


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

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:[hidden email]]
Sent: Wednesday, June 11, 2014 4:57 AM
To: Zheng, Kai; [hidden email]; [hidden email]
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@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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Token Preauth for Kerberos

Nathaniel McCallum-5
In reply to this post by drankye
On Wed, 2014-06-11 at 08:15 +0000, Zheng, Kai wrote:
> 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.

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

Nathaniel

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Simo Sorce-3
In reply to this post by Peter Mogensen
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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Peter Mogensen
On 2014-06-11 18:17, Simo Sorce wrote:
> 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.


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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Simo Sorce-3
On Wed, 2014-06-11 at 19:02 +0200, Peter Mogensen wrote:

> On 2014-06-11 18:17, Simo Sorce wrote:
> > 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.
>
>
> 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.

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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Peter Mogensen
On 2014-06-11 19:08, Simo Sorce wrote:
>> Still... the whole EncTicketPart has to be constructed and DER-encoded
>> 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.

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



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Simo Sorce-3
On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote:

> On 2014-06-11 19:08, Simo Sorce wrote:
> >> Still... the whole EncTicketPart has to be constructed and DER-encoded
> >> 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.
>
> 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.

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.

> 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?

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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Peter Mogensen
On 2014-06-12 14:47, Simo Sorce wrote:
> On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote:
>> 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.
>
> 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.


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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Simo Sorce-3
On Thu, 2014-06-12 at 14:55 +0200, Peter Mogensen wrote:

> On 2014-06-12 14:47, Simo Sorce wrote:
> > On Thu, 2014-06-12 at 09:12 +0200, Peter Mogensen wrote:
> >> 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.
> >
> > 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.
>
>
> 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?

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.

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

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.

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

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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Peter Mogensen
On 2014-06-12 15:01, Simo Sorce wrote:
> 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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Simo Sorce-3
On Thu, 2014-06-12 at 15:19 +0200, Peter Mogensen wrote:

> On 2014-06-12 15:01, Simo Sorce wrote:
> > 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.
>
> 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.

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.

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Verified authorization data

Peter Mogensen
On 2014-06-12 15:23, Simo Sorce wrote:
> 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 ?

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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
12