Skip Menu |
 

Subject: Acces to AS REP keys to decrypt MS-PAC's PAC_CREDENTIAL_DATA
From: Simo Sorce <simo@redhat.com>
To: krb5-bugs@mit.edu
Date: Thu, 29 Sep 2016 16:06:21 -0400
As specified in [MS-PAC] 2.6.2 [1] the PAC_CREDENTIAL_DATA structure is
encrypted with the " cryptographic system selected through the AS
protocol and the KRB_AS_REP message (as specified in [RFC4120] section
3.1.3 and [RFC4556]".

When a client receive the AS_REP though, the MS-PAC is not immediately
available, and will be available only after a subsequent validation
step's TGS reply.

In order to be able to decrypt this PAC buffer the key used to decode
the AS reply needs to be made available to the client on request.

Simo.

[1] https://msdn.microsoft.com/en-us/library/cc237952.aspx

--
Simo Sorce * Red Hat, Inc * New York
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #8503] Acces to AS REP keys to decrypt MS-PAC's PAC_CREDENTIAL_DATA
Date: Thu, 29 Sep 2016 16:31:31 -0400
RT-Send-Cc:
Show quoted text
>>>>> "Simo" == Simo Sorce via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Simo> When a client receive the AS_REP though, the MS-PAC is not
Simo> immediately available, and will be available only after a
Simo> subsequent validation step's TGS reply.

Show quoted text
Simo> In order to be able to decrypt this PAC buffer the key used to
Simo> decode the AS reply needs to be made available to the client
Simo> on request.

Wouldn't it be better to do the decryption immediately ansd hold things
until after the validation?
The AS reply key can be somewhat to very sensitive.
Subject: Re: [krbdev.mit.edu #8503] Acces to AS REP keys to decrypt MS-PAC's PAC_CREDENTIAL_DATA
From: Simo Sorce <simo@redhat.com>
To: rt-comment@krbdev.mit.edu
Date: Thu, 29 Sep 2016 16:38:35 -0400
RT-Send-Cc:
On Thu, 2016-09-29 at 16:31 -0400, Sam Hartman via RT wrote:
Show quoted text
> >>>>> "Simo" == Simo Sorce via RT <rt-comment@krbdev.mit.edu> writes:
>
> Simo> When a client receive the AS_REP though, the MS-PAC is not
> Simo> immediately available, and will be available only after a
> Simo> subsequent validation step's TGS reply.
>
> Simo> In order to be able to decrypt this PAC buffer the key used to
> Simo> decode the AS reply needs to be made available to the client
> Simo> on request.
>
> Wouldn't it be better to do the decryption immediately ansd hold things
> until after the validation?
> The AS reply key can be somewhat to very sensitive.

You do not have access to the MS-PAC (it's encrypted with the TGT key)
until it is handed back to you in the ticket used for validation.
This mechanism is only used for pre-authentication types that do not use
passwords as long term keys, currently only with PKINIT.

--
Simo Sorce * Red Hat, Inc * New York
Can Windows do PKINIT and FAST in the same AS-REQ? If so, is the
PAC_CREDENTIAL_DATA encrypted in the actual reply key, or the reply key
before the KrbFastResponse strengthen-key is applied?

To address Sam's response: we could provide an API combining get_init_creds
and verification, or a GIC option which causes get_init_creds to perform
verification using a supplied keytab, to avoid exposing the reply key to
the application. That's more work for us, but would make it easier to
write proper login application. Of course, we would then have to surface
the decrypted PAC_CREDENTIAL_DATA to the application, probably via another
GIC option.