From jgm+@andrew.cmu.edu Mon Nov 4 21:06:26 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id VAA08908 for <bugs@RT-11.MIT.EDU>; Mon, 4 Nov 1996 21:06:25 -0500
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA20975; Mon, 4 Nov 96 21:06:24 EST
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id VAA00608 for krb5-bugs@athena.mit.edu; Mon, 4 Nov 1996 21:06:20 -0500
Received: via switchmail; Mon, 4 Nov 1996 21:06:19 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.wmTe3bO00WBw018vg0>;
Mon, 4 Nov 1996 21:05:28 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.cmTe3aK00WBw0N0Hg0>;
Mon, 4 Nov 1996 21:05:26 -0500 (EST)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Mon, 4 Nov 1996 21:05:24 -0500 (EST)
Message-Id: <wmTe3YG00WBw0N0HU0@andrew.cmu.edu>
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
Subject: provide method to disable krb4 in_tkt interfaces
bit set. I need to be able to support v4 services, using a v4 tgt
obtained from krb524d. I do not want to support the v4 initial ticket
request protocol, since that can be used by attackers to perform
offline dictionary attacks on the keys in the database.
The "v4 key compatibilty" check is far too lax, causing known
plaintext encrypted with non-v4 salted keys to be exposed through the
v4 compatibility layer. This patch tightens up that check.
For bonus points, the code should be modified to return a correct
error code (KDC_NULL_KEY) to the caller. But I don't know how to get
that error propagated up from the kerb_get_principal interface.
(In my opinion, REQUIRES_PREAUTH should disable the v4 initital ticket
protocol, but my previous suggestion to that effect hasn't been
accepted by MIT.)
*** kerberos_v4.c 1996/11/02 20:54:26 1.1.1.1
--- kerberos_v4.c 1996/11/05 01:49:08
***************
*** 401,407 ****
krb5_dbe_find_enctype(kdc_context,
&entries,
ENCTYPE_DES_CBC_CRC,
! -1,
-1,
&pkey))
{
--- 401,407 ----
krb5_dbe_find_enctype(kdc_context,
&entries,
ENCTYPE_DES_CBC_CRC,
! KRB5_KDB_SALTTYPE_AFS3,
-1,
&pkey))
{
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
The krb5 krb4 compatability exposes keys when preauth or a complex salt is used.
Add a flag (through policy?) that disable v4 in_tkt.
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, John Gardiner Myers <jgm@CMU.EDU>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 22:36:13 -0500
Your patch assumes that the correct V4 key is using the CMU salttype;
that's not a good assumption. Standard V4 sites will have a salt type
of KRB5_KDB_SALTTYPE_V4, for example....
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 23:00:42 -0500 (EST)
Your analysis of my patch is incorrct. Code surrounding the submitted
patch does the correct thing for KRB5_KDB_SALTTYPE_V4.
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: John Gardiner Myers <jgm@CMU.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 23:17:50 -0500
So it does; I had only looked at your patch when I made my comment. My
apologies...
From: John Gardiner Myers <jgm@CMU.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Tue, 5 Nov 1996 19:31:53 -0500 (EST)
My patch has the problem that it then also disables being able to get
tickets for authenticating to services which have non-(v4 or afs)
salted keys.
So, to do this, we need to be a bit more sophisticated. Pass in an
argument to the routine which says whether or not arbitrary salts are
ok, or add an option in kdc.conf which turns off the v4 initial ticket
protocol. Do you have any preferences?
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From: Marc Horowitz <marc@MIT.EDU>
To: John Gardiner Myers <jgm@CMU.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU,
"Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Tue, 05 Nov 1996 21:21:11 EST
I say don't beat around the bush. If you want to turn off the v4
in_tkt code, then we should have a flag which does just and exactly
that. The semantics are a lot cleaner than a flag which says "whether
or not arbitrary salts are ok", which is going to be meaningless to
95% of the users.
Marc
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: John Gardiner Myers <jgm@CMU.EDU>, krb5-bugs@MIT.EDU,
gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU,
"Theodore
Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Fri, 8 Nov 1996 14:54:29 -0500
Date: Tue, 05 Nov 1996 21:21:11 EST
From: Marc Horowitz <marc@MIT.EDU>
I say don't beat around the bush. If you want to turn off the v4
in_tkt code, then we should have a flag which does just and exactly
that. The semantics are a lot cleaner than a flag which says "whether
or not arbitrary salts are ok", which is going to be meaningless to
95% of the users.
Yes, especially if you have krb524 running, a flag which means "don't do
V4 AS requests" seems like a reasonable thing to do. As long as you
allow V4 transactions, the amount of security this buys you is minimal;
people can still attack the V4 TGT key, but it's better than nothing.
In the long run I suppose we could imagine a V4 library where all of the
V4 tickets are obtained via krb524d, and the V4 compatibility code is
turned off completely. This prevents an attack on the V4 TGT, so
attackers would have to break each single DES V4 service key
individually. After we get triple-DES support in, it might make sense
for an especially paranoid site to use this as an option.
Most of this sounds like a post 1.0 issue, though....
- Ted
From: John Gardiner Myers <jgm@CMU.EDU>
To: Marc Horowitz <marc@MIT.EDU>, "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU,
"Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Fri, 8 Nov 1996 15:00:02 -0500 (EST)
I'm a bit less worried about the V4 tgt key, since it tends to have a
bit more entropy than users' private keys.
A flag to turn off the v4 in_tkt code would be just what I'd like.
For now, I'll probably just dike out the appropriate code.
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Responsible-Changed-From-To: gnats-admin->tytso
Responsible-Changed-By: hartmans
Responsible-Changed-When: Sat Nov 9 08:14:38 1996
Responsible-Changed-Why:
From: Tom Yu <tlyu@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/154: provide method to disable krb4 in_tkt interfaces
Date: Wed, 20 Nov 1996 13:40:09 -0500
`Tom Yu' made changes to this PR.
*** /tmp/gnatsa0028. Wed Nov 20 13:36:49 1996
--- /tmp/gnatsb0028. Wed Nov 20 13:39:27 1996
***************
*** 17,30 ****
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
! Subject: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
! Subject: provide method to disable krb4 in_tkt interfaces
Changed priority as per release meeting and de-obfuscate synopsis.
State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Wed Apr 10 16:00:32 2002
State-Changed-Why:
V4 compat handling has been merged in.
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id VAA08908 for <bugs@RT-11.MIT.EDU>; Mon, 4 Nov 1996 21:06:25 -0500
Received: from PO10.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA20975; Mon, 4 Nov 96 21:06:24 EST
Received: (from postman@localhost) by po10.andrew.cmu.edu (8.8.2/8.8.0) id VAA00608 for krb5-bugs@athena.mit.edu; Mon, 4 Nov 1996 21:06:20 -0500
Received: via switchmail; Mon, 4 Nov 1996 21:06:19 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.wmTe3bO00WBw018vg0>;
Mon, 4 Nov 1996 21:05:28 -0500 (EST)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jgm/.Outgoing/QF.cmTe3aK00WBw0N0Hg0>;
Mon, 4 Nov 1996 21:05:26 -0500 (EST)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.54
via MS.5.6.hogtown.andrew.cmu.edu.sun4_51;
Mon, 4 Nov 1996 21:05:24 -0500 (EST)
Message-Id: <wmTe3YG00WBw0N0HU0@andrew.cmu.edu>
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
Subject: provide method to disable krb4 in_tkt interfaces
Show quoted text
>Number: 154
>Category: krb5-kdc
>Synopsis: provide method to disable krb4 in_tkt interfaces
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tytso
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Nov 04 21:07:01 EST 1996
>Last-Modified: Wed Apr 10 16:00:48 EDT 2002
>Originator: John Gardiner Myers <jgm@CMU.EDU>
>Organization:
>Release: 1.1-development
>Environment:
>Description:
I have my realm set up with all principals having the REQUIRES_PREAUTH>Category: krb5-kdc
>Synopsis: provide method to disable krb4 in_tkt interfaces
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tytso
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Nov 04 21:07:01 EST 1996
>Last-Modified: Wed Apr 10 16:00:48 EDT 2002
>Originator: John Gardiner Myers <jgm@CMU.EDU>
>Organization:
>Release: 1.1-development
>Environment:
>Description:
bit set. I need to be able to support v4 services, using a v4 tgt
obtained from krb524d. I do not want to support the v4 initial ticket
request protocol, since that can be used by attackers to perform
offline dictionary attacks on the keys in the database.
The "v4 key compatibilty" check is far too lax, causing known
plaintext encrypted with non-v4 salted keys to be exposed through the
v4 compatibility layer. This patch tightens up that check.
For bonus points, the code should be modified to return a correct
error code (KDC_NULL_KEY) to the caller. But I don't know how to get
that error propagated up from the kerb_get_principal interface.
(In my opinion, REQUIRES_PREAUTH should disable the v4 initital ticket
protocol, but my previous suggestion to that effect hasn't been
accepted by MIT.)
*** kerberos_v4.c 1996/11/02 20:54:26 1.1.1.1
--- kerberos_v4.c 1996/11/05 01:49:08
***************
*** 401,407 ****
krb5_dbe_find_enctype(kdc_context,
&entries,
ENCTYPE_DES_CBC_CRC,
! -1,
-1,
&pkey))
{
--- 401,407 ----
krb5_dbe_find_enctype(kdc_context,
&entries,
ENCTYPE_DES_CBC_CRC,
! KRB5_KDB_SALTTYPE_AFS3,
-1,
&pkey))
{
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
The krb5 krb4 compatability exposes keys when preauth or a complex salt is used.
Show quoted text
>How-To-Repeat:
>Fix:
>Fix:
Add a flag (through policy?) that disable v4 in_tkt.
Show quoted text
>Audit-Trail:
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, John Gardiner Myers <jgm@CMU.EDU>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 22:36:13 -0500
Your patch assumes that the correct V4 key is using the CMU salttype;
that's not a good assumption. Standard V4 sites will have a salt type
of KRB5_KDB_SALTTYPE_V4, for example....
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 23:00:42 -0500 (EST)
Your analysis of my patch is incorrct. Code surrounding the submitted
patch does the correct thing for KRB5_KDB_SALTTYPE_V4.
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: John Gardiner Myers <jgm@CMU.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Mon, 4 Nov 1996 23:17:50 -0500
So it does; I had only looked at your patch when I made my comment. My
apologies...
From: John Gardiner Myers <jgm@CMU.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/154: krb4 interface too lax in security
Date: Tue, 5 Nov 1996 19:31:53 -0500 (EST)
My patch has the problem that it then also disables being able to get
tickets for authenticating to services which have non-(v4 or afs)
salted keys.
So, to do this, we need to be a bit more sophisticated. Pass in an
argument to the routine which says whether or not arbitrary salts are
ok, or add an option in kdc.conf which turns off the v4 initial ticket
protocol. Do you have any preferences?
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
From: Marc Horowitz <marc@MIT.EDU>
To: John Gardiner Myers <jgm@CMU.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU,
"Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Tue, 05 Nov 1996 21:21:11 EST
Show quoted text
>> So, to do this, we need to be a bit more sophisticated. Pass in an
>> argument to the routine which says whether or not arbitrary salts are
>> ok, or add an option in kdc.conf which turns off the v4 initial ticket
>> protocol. Do you have any preferences?
>> argument to the routine which says whether or not arbitrary salts are
>> ok, or add an option in kdc.conf which turns off the v4 initial ticket
>> protocol. Do you have any preferences?
I say don't beat around the bush. If you want to turn off the v4
in_tkt code, then we should have a flag which does just and exactly
that. The semantics are a lot cleaner than a flag which says "whether
or not arbitrary salts are ok", which is going to be meaningless to
95% of the users.
Marc
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: John Gardiner Myers <jgm@CMU.EDU>, krb5-bugs@MIT.EDU,
gnats-admin@rt-11.MIT.EDU, krb5-prs@rt-11.MIT.EDU,
"Theodore
Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Fri, 8 Nov 1996 14:54:29 -0500
Date: Tue, 05 Nov 1996 21:21:11 EST
From: Marc Horowitz <marc@MIT.EDU>
I say don't beat around the bush. If you want to turn off the v4
in_tkt code, then we should have a flag which does just and exactly
that. The semantics are a lot cleaner than a flag which says "whether
or not arbitrary salts are ok", which is going to be meaningless to
95% of the users.
Yes, especially if you have krb524 running, a flag which means "don't do
V4 AS requests" seems like a reasonable thing to do. As long as you
allow V4 transactions, the amount of security this buys you is minimal;
people can still attack the V4 TGT key, but it's better than nothing.
In the long run I suppose we could imagine a V4 library where all of the
V4 tickets are obtained via krb524d, and the V4 compatibility code is
turned off completely. This prevents an attack on the V4 TGT, so
attackers would have to break each single DES V4 service key
individually. After we get triple-DES support in, it might make sense
for an especially paranoid site to use this as an option.
Most of this sounds like a post 1.0 issue, though....
- Ted
From: John Gardiner Myers <jgm@CMU.EDU>
To: Marc Horowitz <marc@MIT.EDU>, "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU,
"Theodore Y. Ts'o" <tytso@MIT.EDU>
Subject: Re: pending/154: krb4 interface too lax in security
Date: Fri, 8 Nov 1996 15:00:02 -0500 (EST)
I'm a bit less worried about the V4 tgt key, since it tends to have a
bit more entropy than users' private keys.
A flag to turn off the v4 in_tkt code would be just what I'd like.
For now, I'll probably just dike out the appropriate code.
--
_.John Gardiner Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Responsible-Changed-From-To: gnats-admin->tytso
Responsible-Changed-By: hartmans
Responsible-Changed-When: Sat Nov 9 08:14:38 1996
Responsible-Changed-Why:
From: Tom Yu <tlyu@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-kdc/154: provide method to disable krb4 in_tkt interfaces
Date: Wed, 20 Nov 1996 13:40:09 -0500
`Tom Yu' made changes to this PR.
*** /tmp/gnatsa0028. Wed Nov 20 13:36:49 1996
--- /tmp/gnatsb0028. Wed Nov 20 13:39:27 1996
***************
*** 17,30 ****
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
! Subject: krb4 interface too lax in security
Show quoted text
>Number: 154
>Category: krb5-kdc
! >Synopsis: krb4 interface too lax in security>Category: krb5-kdc
Show quoted text
>Confidential: no
>Severity: serious
! >Priority: low>Severity: serious
Show quoted text
>Responsible: tytso
>State: open
>Class: sw-bug
--- 17,30 ---->State: open
>Class: sw-bug
Date: Mon, 4 Nov 1996 21:05:24 -0500 (EST)
From: John Gardiner Myers <jgm@CMU.EDU>
To: krb5-bugs@MIT.EDU
! Subject: provide method to disable krb4 in_tkt interfaces
Show quoted text
>Number: 154
>Category: krb5-kdc
! >Synopsis: provide method to disable krb4 in_tkt interfaces>Category: krb5-kdc
Show quoted text
>Confidential: no
>Severity: serious
! >Priority: medium>Severity: serious
Show quoted text
>Responsible: tytso
>State: open
>Class: sw-bug
>State: open
>Class: sw-bug
Changed priority as per release meeting and de-obfuscate synopsis.
State-Changed-From-To: open-closed
State-Changed-By: hartmans
State-Changed-When: Wed Apr 10 16:00:32 2002
State-Changed-Why:
V4 compat handling has been merged in.
Show quoted text
>Unformatted: