Skip Menu |
 

Subject: Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
Over the last few years there have been several higher level security
protocols (TLS KRB5 and RX KRB5) which have required the ability to
perform a ticket decryption outside of the AP_REQ/AP_REP exchange.

In addition, in recent days it has become clear that there is a need for
some mechanism for tools such as kvno and asetkey to be able to validate
whether or not a given keytab in fact contains a entry that can be used
to decrypt the service ticket issued by the KDC. This has become an
issue because of Microsoft's failure to maintain consistent behavior
related to salts and the various versions of their ktpass tool when
generating keytab entries for single DES enctypes.

Attached to this ticket is a proposed src/lib/krb5/krb/srv_dec_tkt.c
file. It contains both keytab and keyblock versions of a
krb5_server_decrypt_ticket function. The keytab version is appropriate
for use with tools such as kvno and asetkey. The keyblock version is
more appropriate for use with higher level security protocols.

This contribution is a minor re-working of work originally performed by
Marcus Watts.
Download srv_dec_tkt.c
text/plain 3.2KiB
/*
* lib/krb5/krb/srv_dec_tkt.c
*
* Copyright 2006 by the Massachusetts Institute of Technology.
* All Rights Reserved.
*
* Export of this software from the United States of America may
* require a specific license from the United States Government.
* It is the responsibility of any person or organization contemplating
* export to obtain such a license before exporting.
*
* WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
* distribute this software and its documentation for any purpose and
* without fee is hereby granted, provided that the above copyright
* notice appear in all copies and that both that copyright notice and
* this permission notice appear in supporting documentation, and that
* the name of M.I.T. not be used in advertising or publicity pertaining
* to distribution of the software without specific, written prior
* permission. Furthermore if you modify this software you must label
* your software as modified software and not distribute it in such a
* fashion that it might be confused with the original M.I.T. software.
* M.I.T. makes no representations about the suitability of
* this software for any purpose. It is provided "as is" without express
* or implied warranty.
*
*
* Server decrypt ticket via keytab or keyblock.
*
* Different from krb5_rd_req_decoded. (krb5/src/lib/krb5/krb/rd_req_dec.c)
* - No krb5_principal_compare or KRB5KRB_AP_ERR_BADMATCH error.
* - No replay cache processing.
* - No skew checking or KRB5KRB_AP_ERR_SKEW error.
* - No address checking or KRB5KRB_AP_ERR_BADADDR error.
* - No time validation.
* - No permitted enctype validation or KRB5_NOPERM_ETYPE error.
* - Does not free ticket->enc_part2 on error.
*/

#include <k5-int.h>

krb5_error_code KRB5_CALLCONV
krb5_server_decrypt_ticket_keyblock(krb5_context context,
krb5_keyblock *key,
krb5_ticket *ticket)
{
krb5_error_code retval;
krb5_data *realm;
krb5_transited *trans;

retval = krb5_decrypt_tkt_part(context, key, ticket);
if (retval)
goto done;

trans = &ticket->enc_part2->transited;
realm = &ticket->enc_part2->client->realm;
if (trans->tr_contents.data && *trans->tr_contents.data) {
retval = krb5_check_transited_list(context, &trans->tr_contents,
realm, &ticket->server->realm);
goto done;
}

if (ticket->enc_part2->flags & TKT_FLG_INVALID) { /* ie, KDC_OPT_POSTDATED */
retval = KRB5KRB_AP_ERR_TKT_INVALID;
goto done;
}

done:
return retval;
}


krb5_error_code KRB5_CALLCONV
krb5_server_decrypt_ticket_keytab(krb5_context context,
krb5_keytab kt,
krb5_ticket *ticket)
{
krb5_error_code retval;
krb5_enctype enctype;
krb5_keytab_entry ktent;

enctype = req->ticket->enc_part.enctype;

if ((retval = krb5_kt_get_entry(context, keytab, req->ticket->server,
req->ticket->enc_part.kvno,
enctype, &ktent)))
return retval;

retval = krb5_server_decrypt_ticket_keyblock(context, &ktent.key, req->ticket);
/* Upon error, Free keytab entry first, then return */

(void) krb5_kt_free_entry(context, &ktent);
return retval;
}
A better version of the srv_dec_tkt.c
Download srv_dec_tkt.c
text/plain 3.2KiB
/*
* lib/krb5/krb/srv_dec_tkt.c
*
* Copyright 2006 by the Massachusetts Institute of Technology.
* All Rights Reserved.
*
* Export of this software from the United States of America may
* require a specific license from the United States Government.
* It is the responsibility of any person or organization contemplating
* export to obtain such a license before exporting.
*
* WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
* distribute this software and its documentation for any purpose and
* without fee is hereby granted, provided that the above copyright
* notice appear in all copies and that both that copyright notice and
* this permission notice appear in supporting documentation, and that
* the name of M.I.T. not be used in advertising or publicity pertaining
* to distribution of the software without specific, written prior
* permission. Furthermore if you modify this software you must label
* your software as modified software and not distribute it in such a
* fashion that it might be confused with the original M.I.T. software.
* M.I.T. makes no representations about the suitability of
* this software for any purpose. It is provided "as is" without express
* or implied warranty.
*
*
* Server decrypt ticket via keytab or keyblock.
*
* Different from krb5_rd_req_decoded. (krb5/src/lib/krb5/krb/rd_req_dec.c)
* - No krb5_principal_compare or KRB5KRB_AP_ERR_BADMATCH error.
* - No replay cache processing.
* - No skew checking or KRB5KRB_AP_ERR_SKEW error.
* - No address checking or KRB5KRB_AP_ERR_BADADDR error.
* - No time validation.
* - No permitted enctype validation or KRB5_NOPERM_ETYPE error.
* - Does not free ticket->enc_part2 on error.
*/

#include <k5-int.h>

krb5_error_code KRB5_CALLCONV
krb5_server_decrypt_ticket_keyblock(krb5_context context,
const krb5_keyblock *key,
krb5_ticket *ticket)
{
krb5_error_code retval;
krb5_data *realm;
krb5_transited *trans;

retval = krb5_decrypt_tkt_part(context, key, ticket);
if (retval)
goto done;

trans = &ticket->enc_part2->transited;
realm = &ticket->enc_part2->client->realm;
if (trans->tr_contents.data && *trans->tr_contents.data) {
retval = krb5_check_transited_list(context, &trans->tr_contents,
realm, &ticket->server->realm);
goto done;
}

if (ticket->enc_part2->flags & TKT_FLG_INVALID) { /* ie, KDC_OPT_POSTDATED */
retval = KRB5KRB_AP_ERR_TKT_INVALID;
goto done;
}

done:
return retval;
}


krb5_error_code KRB5_CALLCONV
krb5_server_decrypt_ticket_keytab(krb5_context context,
const krb5_keytab kt,
krb5_ticket *ticket)
{
krb5_error_code retval;
krb5_enctype enctype;
krb5_keytab_entry ktent;

enctype = ticket->enc_part.enctype;

if ((retval = krb5_kt_get_entry(context, kt, ticket->server,
ticket->enc_part.kvno,
enctype, &ktent)))
return retval;

retval = krb5_server_decrypt_ticket_keyblock(context, &ktent.key, ticket);
/* Upon error, Free keytab entry first, then return */

(void) krb5_kt_free_entry(context, &ktent);
return retval;
}
A patch against the trunk. Includes function exports, makefile.in
updates, and prototypes in krb5.hin.

Also includes an update to kvno.c that adds a [-k keytab] option. When
specified kvno will use the specified keytab in conjunction with
krb5_server_decrypt_ticket_keytab() to validate whether or not the
keytab can in fact be used to successfully decrypt the ticket.

Message body not shown because it is not plain text.

From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
Date: Mon, 15 Jan 2007 13:30:17 -0500
RT-Send-Cc:
In general this seems good.

Why do we want the keyblock version of the function? That seems like
it will encourage a lot of undesirable coding practices where keys are
not stored in keytabs or where applications do not support keyrollover
correctly.



We've talked in the past about having a memory keytab to deal with situations where applications don't have a keytab.
I think that would be better in this instance.
However I can't see cases where TLS or RXK5 applications will not have a keytab.

I'm also not sure I buy the idea that kvno should use this interface
rather than mk_req rd_req. I don't object to kvno using this
interface, I'm just not sure it matters.
Date: Mon, 15 Jan 2007 14:07:59 -0500
From: Jeffrey Altman <jaltman@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Sam Hartman via RT wrote:
Show quoted text
> In general this seems good.
>
> Why do we want the keyblock version of the function? That seems like
> it will encourage a lot of undesirable coding practices where keys are
> not stored in keytabs or where applications do not support keyrollover
> correctly.
>
> We've talked in the past about having a memory keytab to deal with situations where applications don't have a keytab.
> I think that would be better in this instance.
> However I can't see cases where TLS or RXK5 applications will not have a keytab.

In the RXK5 case, the initial deployments of RXK5 may in fact not have a
Kerberos 5 keytab file. The existing DES keys are stored in the AFS
keyfile. The current code generates a Kerberos 5 keyblock from the key.
It could just as easily generate a MEMORY keytab but we would have to
produce the MEMORY keytab implementation first.

Show quoted text
> I'm also not sure I buy the idea that kvno should use this interface
> rather than mk_req rd_req. I don't object to kvno using this
> interface, I'm just not sure it matters.

If we have this interface available, why do the extra work of a
mk_req/rd_req? what would be gained?

Jeffrey Altman
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
Date: Mon, 15 Jan 2007 15:02:54 -0500
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB
Show quoted text
>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Jeffrey> Sam Hartman via RT wrote:
Show quoted text
>> In general this seems good.
>>
>> Why do we want the keyblock version of the function? That
>> seems like it will encourage a lot of undesirable coding
>> practices where keys are not stored in keytabs or where
>> applications do not support keyrollover correctly.
>>
>> We've talked in the past about having a memory keytab to deal
>> with situations where applications don't have a keytab. I
>> think that would be better in this instance. However I can't
>> see cases where TLS or RXK5 applications will not have a
>> keytab.

Show quoted text
Jeffrey> In the RXK5 case, the initial deployments of RXK5 may in
Jeffrey> fact not have a Kerberos 5 keytab file. The existing DES
Jeffrey> keys are stored in the AFS keyfile. The current code
Jeffrey> generates a Kerberos 5 keyblock from the key. It could
Jeffrey> just as easily generate a MEMORY keytab but we would have
Jeffrey> to produce the MEMORY keytab implementation first.

Feedback we got even from AFS users on krbdev suggests that we do not
want to accept afs-specific code. I cannot see any reason for the
keyblock implementation that is not based on artifacts of how AFS is
deployed today.

--Sam
Date: Mon, 15 Jan 2007 15:22:11 -0500
From: Jeffrey Altman <jaltman@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
RT-Send-Cc:
Sam Hartman via RT wrote:
Show quoted text
> Feedback we got even from AFS users on krbdev suggests that we do not
> want to accept afs-specific code. I cannot see any reason for the
> keyblock implementation that is not based on artifacts of how AFS is
> deployed today.

This is not AFS specific code. Its simply a question of how are keys
stored for a service on a particular machine. For example, on a Windows
system I can easily imagine not wanting to use a keytab file.

I will remove the public definition and the exports for the keyblock
version from the patch and commit it to the head. Assuming that is ok.

I will then start working on a MEMORY keytab implementation.

Jeffrey Altman
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5349] Proposed implementation of krb5_server_decrypt_ticket_keyblock and krb5_server_decrypt_ticket_keytab
Date: Mon, 15 Jan 2007 15:33:05 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Jeffrey" == Jeffrey Altman via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Jeffrey> Sam Hartman via RT wrote:
Show quoted text
>> Feedback we got even from AFS users on krbdev suggests that we
>> do not want to accept afs-specific code. I cannot see any
>> reason for the keyblock implementation that is not based on
>> artifacts of how AFS is deployed today.

Show quoted text
Jeffrey> This is not AFS specific code. Its simply a question of
Jeffrey> how are keys stored for a service on a particular
Jeffrey> machine. For example, on a Windows system I can easily
Jeffrey> imagine not wanting to use a keytab file.

Show quoted text
Jeffrey> I will remove the public definition and the exports for
Jeffrey> the keyblock version from the patch and commit it to the
Jeffrey> head. Assuming that is ok.

Sounds good.
From: jaltman@mit.edu
Subject: SVN Commit
This commit adds two new functions, krb5_server_decrypt_ticket_keyblock
(private) and krb5_server_decrypt_ticket_keytab (public). These
functions take a krb5_ticket as input and decrypt it using the provided
key data. The public function is useful for higher level application
protocols such a TLS-KRB5 and AFS RX-KRB5 which exchange a service
but do not use the AP-REQ/AP-REP messages.

This commit also adds new functionality to kvno which permits kvno
when provided a keytab as input to verify whether or not the keytab
contains a key that can successfully decrypt the obtains service ticket.


Commit By: jaltman



Revision: 19062
Changed Files:
U trunk/src/clients/kvno/kvno.c
U trunk/src/include/krb5/krb5.hin
U trunk/src/lib/krb5/krb/Makefile.in
A trunk/src/lib/krb5/krb/srv_dec_tkt.c
U trunk/src/lib/krb5/libkrb5.exports
U trunk/src/lib/krb5_32.def
From: raeburn@mit.edu
Subject: SVN Commit
Fix typo in checked-in version.

Commit By: raeburn



Revision: 19063
Changed Files:
U trunk/src/include/krb5/krb5.hin
From: tlyu@mit.edu
Subject: SVN Commit
rename krb5_server_decrypt_ticket_keyblock() to
krb5int_server_decrypt_ticket_keyblock()


Commit By: tlyu



Revision: 19159
Changed Files:
_U trunk/
U trunk/src/include/k5-int.h
U trunk/src/lib/krb5/krb/srv_dec_tkt.c
From: tlyu@mit.edu
Subject: SVN Commit
pull up r19062 from trunk

r19062@cathode-dark-space: jaltman | 2007-01-15 23:18:02 -0500
ticket: 5349
tags: pullup

This commit adds two new functions, krb5_server_decrypt_ticket_keyblock
(private) and krb5_server_decrypt_ticket_keytab (public). These
functions take a krb5_ticket as input and decrypt it using the provided
key data. The public function is useful for higher level application
protocols such a TLS-KRB5 and AFS RX-KRB5 which exchange a service
but do not use the AP-REQ/AP-REP messages.

This commit also adds new functionality to kvno which permits kvno
when provided a keytab as input to verify whether or not the keytab
contains a key that can successfully decrypt the obtains service ticket.




Commit By: tlyu



Revision: 19160
Changed Files:
_U branches/krb5-1-6/
U branches/krb5-1-6/src/clients/kvno/kvno.c
U branches/krb5-1-6/src/include/krb5/krb5.hin
U branches/krb5-1-6/src/lib/krb5/krb/Makefile.in
A branches/krb5-1-6/src/lib/krb5/krb/srv_dec_tkt.c
U branches/krb5-1-6/src/lib/krb5/libkrb5.exports
U branches/krb5-1-6/src/lib/krb5_32.def
From: tlyu@mit.edu
Subject: SVN Commit
pull up r19063 from trunk

r19063@cathode-dark-space: raeburn | 2007-01-16 18:29:46 -0500
ticket: 5349

Fix typo in checked-in version.



Commit By: tlyu



Revision: 19161
Changed Files:
_U branches/krb5-1-6/
U branches/krb5-1-6/src/include/krb5/krb5.hin
From: tlyu@mit.edu
Subject: SVN Commit
pull up r19159 from trunk

r19159@cathode-dark-space: tlyu | 2007-02-12 19:35:48 -0500
ticket: 5349

rename krb5_server_decrypt_ticket_keyblock() to
krb5int_server_decrypt_ticket_keyblock()




Commit By: tlyu



Revision: 19162
Changed Files:
_U branches/krb5-1-6/
U branches/krb5-1-6/src/lib/krb5/krb/srv_dec_tkt.c
From: tlyu@mit.edu
Subject: SVN Commit
back-port k5-int.h change to krb5.hin


Commit By: tlyu



Revision: 19163
Changed Files:
_U branches/krb5-1-6/
U branches/krb5-1-6/src/include/krb5/krb5.hin