[5876] in Kerberos
Re: Problems with forwarding tickets using rlogin with
daemon@ATHENA.MIT.EDU (Doug Engert)
Mon Sep 18 10:03:39 1995
Date: Mon, 18 Sep 95 08:52:47 CDT
From: "Doug Engert" <DEEngert@anl.gov>
To: <KERBEROS@MIT.EDU>
Kerberos V5.5
schwartz@roke.cse.psu.edu (Scott Schwartz) wrote:
>Ticket forwarding has never worked in 5.5. klist -e will show
that >the ticket that gets forwarded has ETYPE_UNKNOWN. This has
been >reported by a number of people, with no fix forthcoming.
Maybe in the >next release? Is anyone working on this code who
could comment?
Yes people are working on this, and we can comments.
First I would like to qualify my remarks, since we are using a
DCE security server in place of the KDC. There are some subtle
differences which may account for or success. It may also help to
explain what is occurring. In addition to forwarding tickets, we
also have some code working which will allow you to use the
forwarded ticket to get a DCE context, which is very useful in
allowing a user to logon from a none DCE client, to a DCE machine
and have access to the DFS files on that machine without sending
passwords over the network.
Scott, I don't know if you have seen these mods, but you can find
our set of diffs for Kerberos 5 beta 5 at:
ftp://achilles.ctd.anl.gov/pub/kerberos.v5/k55.cdiff.950905
If you have these mods, please try the suggestion I gave to Venn,
as I am not sure if the problem he is seeing was introduced by these
mods. If you don't have these mods, then the problem you are seeing
must be in the Kerberos code itself.
This file is a context diff file of our changes which include
many of the changes sent to the krb5-bugs list by others as well.
It does not contain the DCE context code, as that is still under
development, and it does not have any Kerberos code. (DCE can
read the Kerberos created type 1 cache file to get the forwarded
ticket.)
Attached are a number of notes from over the last few months,
which deal with forwarding and the subtle differences between DCE
and Kerberos 5 beta 5. The first note is to Venn, who I responded
to last week on this subject, with a suggestion on what to try
with a real KDC to see what happens. Scott, if you could try this
as well, it would be helpful in solving the problem.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
----- ------ ----- ----- ----- ----- ----- ----- ----- -----
Date: Thu, 14 Sep 95 15:13:52 CDT
From: "Doug" <Engert@anl.gov>
To: <venn@utkux.utcc.utk.edu>
Cc: <ramus@nersc.gov>
Subject: Kerberos 5 beta 5 and ETYPE_UNKNOWN
Venn,
I believe that what you are seeing (ETYPE_UNKNOWN) in the klist
is caused by the DCE compatibility modification in
lib/krb5/ccache/file/fcc.h, which sets the cache type to a 1.
But the mod in lib/krb5/ccache/file/fcc_read.c should have fixed that.
We are using the DCE security server as the KDC, I believe you and
Joe Ramus are using the MIT KDC. This may cause a diffenrence, and
there may be a bug in the fcc_read.c fix.
Also if you are not using DCE, you probably don't wan't the
-DANL_DCE define, since that sets the cache type to 1 and the
etype is not saved. In a type 3 cache it is saved.
You can look at the cache type with "od" and the first byte
should be a 05 and the second the cache type.
Try removing the -DANL_DCE, and recompling the fcc_read.c routine,
which will cause everything to be relinked. This may help.
I would be very interesed in seeing what the etype shows up
when you have a type 3 cache. In my DCE invironment, the above
change substitutes ETYPE_DES_CBC_CRC.
Attached are a number of other notes, including one form Ted saying
that there is a problem with the protocol. We may be seeing this.
The other way to "fix" this might be to the lib/krb5/krb/init_ctx.c
routine at lines 105 and 106 to use the ETYPE_DES_CBC_CRC before the
ETYPE_DES_CBC_MD5, or do what the comment says at line 104.
Let me know if this makes any sense to either of you, since I
am a little fuzy on it right now.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
----- ------ ----- ----- ----- ----- ----- ----- ----- -----
Date: 8 May 95, 16:13:21 CDT
From: Doug Engert DEEngert at anl.gov
To: authtf at es.net
Subject: Kerberos 5 Beta 5 Interoperability with DCE No. 2
(This is resending a note I sent to krb5-bugs@mit.edu....
since my mailier bounced it at es.net)
When using a DCE security server as the KDC, and using the K5.5
kinit and the K5.5 rlogin every works. (This is with the fix I sent
in saturday.)
When using the dce_login command, the krbtgt is obtained, but
when the rlogin tries to get the ticket for host/.... it gets a
KRB5_WRONG_ETYPE return code from ./lib/krb5/krb/decode_kdc.c.
(This worked in K5.4.3.)
It appears that the "if (local_dec_rep->enc_part.etype != etype)"
is not adequate in this situation, where one encryption method is
used for the krbtgt, and another is used for the host/... ticket.
Kerberos 5 beta 5 introduced a second encryption type,
ETYPE_DES_CBC_MD5, in addition to the ETYPE_DES_CBC_CRC. This
allowed the client to suggest and the KDC to select which one to
use.
Since the etype in this routine was taken from the krbtgt and as
the comments in the krb5.h for the krb5_keyblock indicate, it is
only a HINT. It appears that the ETYPE_DES_CBC_CRC was used by
the dce_login, while the ETYPE_DES_CBC_MD5 was used by the
rlogin.
A better test might be:
if(krb5_csarray[local_dec_rep->enc_part.etype]->system->proto_keytype
!= key->keytype)
Test if the key can be used for this encryption method.
The K5.5 clients are on a AIX 3.2.5 system, the K5.5 rlogind is on a
SunOS 4.1.3_U1 and the DCE security server is on a Solaris 2.4
system with the Transarc 1.0.3a DCE. (I have also built k5.5 on
a Linux system at home, and it works as well!)
A complete context diff file can be found at
ftp://achilles.ctd.anl.gov/pub/kerberos.v5/k55.cdiff.950508
which contains a number of other changes, some for AIX.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
------------------------------------------
*** ./lib/krb5/krb/,decode_kdc.c Thu Apr 13 19:53:55 1995
--- ./lib/krb5/krb/decode_kdc.c Mon May 8 15:25:17 1995
***************
*** 60,66 ****
if (retval)
return retval;
! if (local_dec_rep->enc_part.etype != etype) {
krb5_free_kdc_rep(context, local_dec_rep);
return KRB5_WRONG_ETYPE;
}
--- 60,78 ----
if (retval)
return retval;
! /* ANL - The following check is being changed, since the
! * etype being tested is only a hint at what etype to expect.
! * See the krb5_keyblock definition in krb5.h.
! * Also see the XXX comment in krb5.h before krb5_keytype_array
! * This causes a problem with tickets obtained from DCE.
! * which suggest one etype, but may have another.
! * This problem was introduced in 5 beta 5 when a second etype
! * was added.
! */
! /* if (local_dec_rep->enc_part.etype != etype) { */
!
! if (krb5_csarray[local_dec_rep->enc_part.etype]->system->proto_keytype
! != key->keytype) {
krb5_free_kdc_rep(context, local_dec_rep);
return KRB5_WRONG_ETYPE;
}
Date: 10 May 95, 08:54:38 CDT
From: Doug Engert DEEngert at anl.gov
To: KERBEROS at MIT.EDU
cc: JOEK at CYBERSAFE.COM
KRB5-BUGS at ATHENA.MIT.EDU
Subject: Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
Joe,
Thanks for the response to my bug report. I have made a number
of comments, and in doing so, I have a better understanding
of how the keytype and etypes have to work together.
On May 9 Joe responded to my note with:
>On 8 May 1995, Doug Engert wrote:
>[...]
>> Since the etype in this routine was taken from the krbtgt and as
>> the comments in the krb5.h for the krb5_keyblock indicate, it is
>> only a HINT. It appears that the ETYPE_DES_CBC_CRC was used by
>> the dce_login, while the ETYPE_DES_CBC_MD5 was used by the
>> rlogin.
>>
>> A better test might be:
>> if(krb5_csarray[local_dec_rep->enc_part.etype]->system->proto_keytype
>> != key->keytype)
>> Test if the key can be used for this encryption method.
>[...]
>
>While the above will work, I believe the fix violates the spirit (if not
>the letter?) of the RFC; the original code is, I believe, simply
>deficient.
I agree, the original code may be deficient, and the fix is not perfect.
The above fix got it to work, and hopefully in the following
discussion, I can map out a better fix.
>
>The e-type in the request is more than a "hint". The KDC should use the
>first supported e-type; it is assumed that the client put the e-types in
>order of preference for a reason. At any rate, the KDC _must_ use one of
>the requested e-types, or it should reject the request with an
>"unsupported e-type" error--it should not simply pick something it happens
>to like.
The "hint" I talked about was not the AS_REQ etype sequence. I
believe the DCE KDC is using the etype sequence, which is a
sequence in preference order. It is selecting one of these,
and I believe it is the first one.
The "hint" I referred to is in the krb5_keyblock.etype (krb5.h)
which says: /* hint of what encryption type to use */.
This appears to come from the as_reply->ticket->enc_part.etype
which is the encryption method used with the AS_REP and should be one
of the types requested in the AS_REQ etype sequence.
When the client issues a TGS_REQ it also can fill in the etype sequence
with a list, which should be chosen based on the keytype returned
in the AS_REP. The krb5_send_tgs() routine has an etypes parameter
which appears to be designed for this purpose. But if it is NULL
a default list is used instead. The only place krb5_send_tgs()
appears to be called from is gc_via_tkt.c, and it sets etypes to NULL.
A fix could be to have it pass the single etype
which was saved in the "hint", and tell the KDC which method to use.
(Thats what K5.4.3 did.) A better fix would be to have it fill in
the TGS_REQ etype sequence with a list of etypes which can
be used with the returned key.
>
>By the same token, the client should reject the reply if it does not match
>_one_ of the requested e-types. (The function described above only
>accepts a single e-type. Oh well.) This may be different than the e-type
>of the TGT, since, of course, the server in question may not support all
>of the client's e-types (or for a couple other reasons).
I believe the KDC (both the MIT 5.5 and the DCE server) are selecting
one of the etypes from the sequence. That is not the problem.
K5.5 made the assumption that the client in the AS_REQ
and the client in the TGS_REQ will use the same etype sequence. i.e. the
etype used in the AS_REP is saved in the "hint" and it will be the
same method used when the TGS_REP is processed, even though the
TGS_REQ specified a different etype sequence.
The REAL problem is that the K5.5 code is testing the TGS_REP
using the "hint" etype rather then testing if the etype used
was one of the ones it sent in the TGS_REQ.
In my testing, the AS_REQ is generated by the dce_login program,
and the TGS_REQ is done by the K5.5 rlogin. I believe they are
sending two different sequences.
With K5.4.3 I did not have this problem. The etype for the TGS_REQ was
obtained in gc_frm_kdc.c:
#define TGT_ETYPE \
krb5_keytype_array[tgt.keyblock.keytype]->system->proto_enctype;
>
>While simply saying that any e-type will do (as long as the key will
>work), I think that a response that uses an e-type other than one of the
>ones requested indicates a broken KDC, and the client should reject the
>reply. This is in the same spirit as the rest of the checks made by the
>client of KDC replies: even though a reply may decrypt properly and is
>within the clock skew, the client still checks--and will reject--a KDC
>reply for any number of reasons; many of those checks are "if it ain't
>exactly what I requested, reject it with a 'KDC reply modified' error".
>
>Yes, one could make the argument that, since the client has already
>decrypted the original KDC reply, that the KDC knows that the client
>supports that e-type, and that the client doesn't have to explicitly
>request the e-type present in the TGT. But this raises several other
>questions/ambiguities (which is one thing we don't need more of :); but
>any discussion of them would would probably induce disorientation and
>nausea, if not bore you to death.
>
I hope that the comments I have made above makes it clear, that I am
NOT saying to disregard the *_REQ etype sequence, but rather the
checks used in K5.5 are wrong and this caused the problem.
>Then again, the RFC can be a bit fuzzy when it comes to the treatment of
>multiple e-types and key types, so some additional discussion and comment
>is probably in order...
>
>
>Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
Well, I have been writing this note now for over two hours,
and there is still another issue which will cloud this area. That
is the addition of other keytypes. Now there is only the DES key,
and all of the etype methods use DES. When the TGS_REQ etype sequence
is generated, this list will have to be made up of etypes which
work with the keytype as returned in the AS_REP.
The krb5_get_default_in_tkt_etypes() may need to be changed
to add the keytype as a parameter.
The fix I produced is usable, but I would hope the next beta version
would provide a better one. I am reluctant to make major changes in
an area of the code which may change in the next release.
As you said further discussion is still needed....
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
Received: from ANLVM by ANLVM (Mailer R2.07B) with BSMTP id 5156; Wed, 10 May
95 00:10:44 CDT
Received: from dns2.anl.gov by ANLVM.CTD.ANL.GOV (IBM VM SMTP R1.2.2ANL-MX) with
TCP; Wed, 10 May 95 00:10:42 CDT
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.72.0.21]) by
dns2.anl.gov (8.6.11/8.6.11) with SMTP id AAA22637 for <DEEngert@anl.gov>; Wed,
10 May 1995 00:10:43 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA03465; Wed, 10 May 95 00:57:21 EDT
Received: by pad-thai.cam.ov.com (8.6.12/)
id <AAA24453@pad-thai.cam.ov.com>; Wed, 10 May 1995 00:57:30 -0400
Received: from GATEWAY by pad-thai.cam.ov.com with netnews
for kerberos-wrapper@cam.ov.com (kerberos@mit.edu)
To: kerberos@MIT.EDU
Date: Tue, 9 May 1995 21:27:11 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
Message-Id: <Pine.SUN.3.91.950509203716.19642D-100000@kerby.ocsg.com>
Organization: CyberSAFE Corporation
Sender: usenet@cam.ov.com
References: <9505082157.AA19182@MIT.EDU>
Subject: Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
On 8 May 1995, Doug Engert wrote:
[...]
> Since the etype in this routine was taken from the krbtgt and as
> the comments in the krb5.h for the krb5_keyblock indicate, it is
> only a HINT. It appears that the ETYPE_DES_CBC_CRC was used by
> the dce_login, while the ETYPE_DES_CBC_MD5 was used by the
> rlogin.
>
> A better test might be:
> if(krb5_csarraylocal_dec_rep->enc_part.etypeY->system->proto_keytype
> != key->keytype)
> Test if the key can be used for this encryption method.
[...]
While the above will work, I believe the fix violates the spirit (if not
the letter?) of the RFC; the original code is, I believe, simply
deficient.
The e-type in the request is more than a "hint". The KDC should use the
first supported e-type; it is assumed that the client put the e-types in
order of preference for a reason. At any rate, the KDC _must_ use one of
the requested e-types, or it should reject the request with an
"unsupported e-type" error--it should not simply pick something it happens
to like.
By the same token, the client should reject the reply if it does not match
_one_ of the requested e-types. (The function described above only
accepts a single e-type. Oh well.) This may be different than the e-type
of the TGT, since, of course, the server in question may not support all
of the client's e-types (or for a couple other reasons).
While simply saying that any e-type will do (as long as the key will
work), I think that a response that uses an e-type other than one of the
ones requested indicates a broken KDC, and the client should reject the
reply. This is in the same spirit as the rest of the checks made by the
client of KDC replies: even though a reply may decrypt properly and is
within the clock skew, the client still checks--and will reject--a KDC
reply for any number of reasons; many of those checks are "if it ain't
exactly what I requested, reject it with a 'KDC reply modified' error".
Yes, one could make the argument that, since the client has already
decrypted the original KDC reply, that the KDC knows that the client
supports that e-type, and that the client doesn't have to explicitly
request the e-type present in the TGT. But this raises several other
questions/ambiguities (which is one thing we don't need more of :); but
any discussion of them would would probably induce disorientation and
nausea, if not bore you to death.
Then again, the RFC can be a bit fuzzy when it comes to the treatment of
multiple e-types and key types, so some additional discussion and comment
is probably in order...
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
Re: Kerberos 5 Beta 5 Interoperability with DCE # 2 ER
Received: from ANLVM by ANLVM (Mailer R2.07B) with BSMTP id 3456; Fri, 19 May
95 13:50:18 CDT
Received: from dns2.anl.gov by ANLVM.CTD.ANL.GOV (IBM VM SMTP R1.2.2ANL-MX) with
TCP; Fri, 19 May 95 13:50:11 CDT
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dns2.anl.gov
(8.6.11/8.6.11) with SMTP id NAA16327 for <DEEngert@anl.gov>; Fri, 19 May 1995
13:50:14 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA20241; Fri, 19 May 95 14:16:07 EDT
Received: by dcl.MIT.EDU (5.0/4.7) id AA07427; Fri, 19 May 1995 14:16:07 +0500
Date: Fri, 19 May 1995 14:16:07 +0500
From: "Theodore Ts'o" <tytso@MIT.EDU>
Message-Id: <9505191816.AA07427@dcl.MIT.EDU>
To: Joe Kovara <joek@CyberSAFE.COM>
Cc: kerberos@MIT.EDU
In-Reply-To: Joe Kovara's message of Wed, 17 May 1995 21:53:07 -0700,
<Pine.SUN.3.91.950517214006.381A-100000@kerby.ocsg.com>
Subject: Re: Kerberos 5 Beta 5 Interoperability with DCE # 2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 5780
Date: Wed, 17 May 1995 21:53:07 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
A serious problem is that there is no mechanism for negotiating the e-
type. Specifically, there is no way to find out what e/k-types the
other side of a connection supports, outside of the context of the
AS/TGS request, which is very limited. All anyone has to go on is
what they can infer from the e-types of messages they have in hand (or
have received), and the k-types from keys (either session keys or
stored keys), from which one can infer e-types. While this has not
been a problem with only one e/k-type, it can be a major problem with
multiple types--inferring e/k-types becomes very tricky, dangerous, or
impossible.
Yes. For better or for worse, the original protocol design for Kerberos
V5 envisioned that e-types and k-types were orthoganol (although
obviously only a very small intersection of e-types and k-types would be
allowed).
However, there wasn't enough thought put into the negotiation of what
the appropriate e-type would be --- in fact, the definition of the
e-type field was not fully defined in the protocol RFC. I have
developed a set of proposed errata which will hopefully clarify the
situation. They were written up early in the beta 5 design work, but
I've deliberately not sent them to Cliff yet because I want to gain some
implementation experience with adding a new e-type, such as triple DES,
before I make these new semantics "official". I'll include them below
for general comment.
The inclusion of the e-type in the key block in beta 5 appears to be
an attempt to remedy part of the problem by remembering an e-type used
by the other side. Apparently, the "hint" referred to in the code is
essentially a statement to the effect of "The last time I talked to
the other side, they used an e-type of X with this k-type, so I
suppose that's the e-type that they prefer (at least I know they
support this combination of e/k-types), and that I should use X when
talking to them." However, since you have the ticket, you have the
ticket's e-type, so why store it? I can think of two reasons: (1) so
you don't have to decode the ticket to sniff out the e-type; (2) it
has nothing to do with this, but...
Yes, both reasons where correct; the first is as an efficiency hack so
that we don't have to keep parsing out the ticket in order to figure out
the e-type. The second was that, before we made the auth context change
to the API, there was no way to pass the encryption type to
krb5_{rd,mk}_{safe,priv}. The original code assumed a one-to-one
mapping between the encryption type and the key type, which was a bad
assumption to make.
So, adding the e-type in the key block was a cheap way to preserve the
existing API while allowing the information to be properly passed to the
routines. Ultimately, though, we decided to bite the bullet and fix the
API, even though I knew that would inconvenience some people who had
starting code applications using our Beta 4 application. Storing the
e-type field there is still useful as an efficiency hack for reason
number 1, though.
-----------------------
Here's the draft errata that I had composed last November.
Assuming that we get multi-encryption support working without a glitch,
this is what I plan to propose as an errata to RFC-1510. Some of the
simplifying assumptions which are made in this errata should help
preserve people's sanity. (Sorry, Joe; if I known this was an area you
were investigating, I would have sent this to you, and perhaps saved a
bit of hair-pulling on your part.)
Any comments to this draft are appreciated.
Processing of the etype field, described in 3.1.3, and 5.4.1.
(Obsoletes errata #2.)
The etype field in the KDC-REQ message is a list of encryption types in
order of preference. [*] When processing a AS or TGS request, the KDC
will use the first encryption type which meets the following criteria:
* The encryption must be a strong encryption type.
* The KDC must support the encryption type
* The Kerberos database must indicate that the encryption type
is acceptable for the application server.
This encryption type will be used to generate the returned Kerberos
ticket, and the random session key in the ticket will be suitable for
use with this encryption type. In the case of a AS request, this
encryption type will also be used to encrypt the encrypted portion of
the KDC-REP message. In the case of a TGS request, the encrypted
portion of the KDC-REP message will be encrypted using the same
encryption type that was used to encrypt the authenticator.
[*] This is clear from the ASN.1 specification, but the definition of
the etype field which follows near the end of section 5.4.1 is
confusing, as it makes it appear that etype field is specifies a single
encryption type, not a list. I suspect, from the implementation
history, that the protocol originally specified that etype was an
INTEGER, and only later was expanded to be a LIST OF INTEGER. Also note
that the etype field is mandatory; the second paragraph of errata #2
makes it appears that it is optional, which it is not.
Clarification to section 3.2.2.
The authenticator is encrypted using the encryption type that was used
to encrypt the ticket.
Clarification to section 3.2.4
The KRB_AP_REQ message is encrypted using the encryption type that was
used to encrypt the authenticator (and the ticket) in the preceeding
KRB_AP_REQ message.
Clarification to section 3.5.1 and 3.6.1
The KRB_PRIV message and the KRB_CRED message are encrypted using the
using the encryption type that was used to encrypt the ticket and
authenticator used to establish the session key or subkey.
- Ted
