[1356] in Kerberos-V5-bugs
A New Kerberos and Cross Realm Configurable Authentication Paths
daemon@ATHENA.MIT.EDU (Doug Engert)
Wed May 3 03:31:42 1995
Date: Thu, 20 Apr 95 16:45:59 CDT
From: "Doug Engert" <DEEngert@anl.gov>
To: <krb5-bugs@MIT.EDU>
Cc: <authtf@es.net>
Ted,
I saw in a note last week that there may be a new version of
Kerberos 5 out within the next few weeks! Since I have not talked
to you about the Configurable Authentication Path modification
since last november, I would like you to consider adding this
to the new release if you have not already done so.
Attached is a copy of the note I sent to you last November
explaining how this modification will work and why it is important.
Since November, we have been working on interoperability between
OSF/DCE and Kerberos 5 beta 4 pl 3, and have been having great
success. ESnet and a number of other groups are very interested
in this, and I have been recommending proceeding in this
direction. (We have been using DCE 1.0.3, and plan to be using
DCE 1.1 soon for the projects.)
It appears that the Configurable Authentication Path
modifications to Kerberos will function with DCE even without
modification. (This still has to be tested.) Since the
gc_frm_kdc.c routine does most of the work, and is run in the
Kerberized client, and the final verifier (applicatrion server)
is also kerberized and does the final check of the transited
field, the DCE security server does not need the Configurable
Authentication Path modification. (I assume that the DCE security
server is updating the transited field as defined in the RFC1510.)
Our reasons in wanting to combine Kerberos 5 and DCE are the lack
of telnet, FTP, and "r" commands in the current DCE release, and
availability of the source code for Kerberos 5 for porting to
none DCE systems.
(You might find of interest a number ESnet proposal which all
deal with Distributed computing. See http://www.es.net/ under
"ESnet Committees and Working Groups" then "DICCE Proposals" The
"B - Authentication Infrastructure of the DICCE" deals with DCE
and Kerberos 5 interoperability. Many of the others also
recommend DCE and Kerberos.)
A copy of the diff file for the modification can be found
at ftp://achilles.ctd.anl.gov/pub/kerberos.v5/k543.cross.950420
I have also placed a modified copy of walk_rtree.c for easier
reading in the same directory named k543.cross.walk_rtree.c
If you have any questions, please let me know.
Thanks
Doug
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
----- ------ ----- ----- ----- ----- ----- ----- ----- -----
Date: 22 November 94, 13:32:21 CST
From: Doug Engert DEEngert at anl.gov
To: bcn at ISI.EDU
tytso at ATHENA.MIT.EDU
cc: auth-pilot at es.net
escc-auth at es.net
Subject: Configurable Authentication Paths
Cliff, Ted,
Last month Cliff responded to my note about Configurable
Authentication paths. That response is attached. I am sorry I did
not get back to respond to you sooner, but I have been very busy
with other projects including OSF/DCE.
I now have some time to get back to this, and still feel that the
idea of Configurable Authentication Paths, is a substantial
improvement to the Kerberos product, in that it removes the
restrictions imposed on the choice of realm names which currently
provide the cross cell routing information, and it can provide
for additional security.
In your note, you outlined 3 steps which I can easily meet
(1) Configurable at compile time.
* The mod was written this way, but the #define
CONFIGURABLE_AUTHENTICATION_PATH is defined in the in the
module.
(2) Include documentation describing how it works: Yes this can be
done.
* Would a man page for the /krb5/krb.capaths be adequate?
(3) Must explain the security implications associated with the mod.
* This is what I hope to do in this note.
You also said we need to look at:
(1) How does the modification
interact with the KDC specified path traversal.
(2) How it interacts with the validation of the transited field.
Before going into how the capaths modification works, I would
like to make comments on the current implementation in regards to
the "shortest" path and validation of the transited field, since
the behavior of these has some effect on how best to implement
capaths.
VALIDATION OF THE TRANSITED FIELD
Until 5.4.3 the transited field was not validated. In 5.4.3 a
routine krb5_check_transited_list() was added. It is called from
the krb5_rd_req_decoded() routine. In the KDC this is called via
a kdc_util.c routine, and in servers it is called via a
recvauth.c routine.
Thus both the KDCs and end servers can check the transited field.
The krb5_check_transited_list() uses the krb5_walk_realm_tree()
routine to generate the valid list of realms which may be on the
transited list.
The krb5_walk_realm_tree() is the ONLY routine which uses has any
knowledge of the hierarchical nature of the realm names. The real
function of the routine is to return a valid ROUTE of realms to
be used in getting from the client's realm to the server's realm.
SHORTEST PATH
In the existing release, the client contacts its local KDC and
requests a ticket for the destination realm. The local KDC has
the option of returning a TGT for the closest realm.
Your attached note says: "Thus the KDC has a say in determining
what the authentication path will be."
Although the client code goes through great pains to use short
cuts as allowed in the RFC, since the krb5_check_transited_list()
has no knowledge of any of these shortcuts, the check must allow
for any of the intermediate realms to be on the transited list.
A modified client could determine the path and ask each KDC along
the path for a TGT to the next realm. It does not need to ask for
a TGT to the final destination. Since each KDC is using the
krb5_check_transited_list() routine to check the transited
fields, this would still be valid. Thus the client could bypass
any attempt at using shortcuts and the
krb5_check_transited_list() has to accept this.
In other words the shortcuts are optional and can't be used to
provide additional security without additional code changes.
CONFIGURABLE AUTHENTICATION PATHS
The current capath code is completely contained in the
krb5_walk_realm_tree() routine, and thus will work with the 5.4.3
transited path check routines.
Its function is to provide a path between the client and the
server. It does this by first generating the hierarchical path,
then looking for alternate paths in the middle. This was done to
allow organizations to have multiple realms based on hierarchical
names, to continue to use the hierarchical routing within the
organization, yet use external KDC's for cross realm
authentication outside of the organization.
The /krb5/krb.capaths file consists of records which contain two
realm names followed by the path between these realms. It is
assumed that the path is the same in the reverse direction.
For example, in our Cross Realm Authentication Project, each of
the Labs picked its realm name based on its Domain name, ANL.GOV,
LLNL.GOV, NERSC.GOV, and PNL.GOV. At ANL we also added two
additional test realms of FIRST.ANL.GOV and SECOND.ANL.GOV which
are hierarchical names based on the ANL.GOV name. We are all
sharing keys with a ES.NET realm to keep down the number of keys.
(ESNet has over 30 members, and for scaleability, we can't all
share keys with one another.)
Most of the records in a /krb5/krb.capaths files looked like:
ANL.GOV NERSC.GOV ES.NET
Any ANL.GOV realm could cross authenticate with the NERSC.GOV
realm by going through the ES.NET realm.
USAGE OF THE /KRB5/KRB.CAPATHS FILE
The capath code uses a file /krb5/krb.capaths which continues
these routes between the organizations. This file is accessed by
the krb5_walk_realm_tree() routine whenever it is called. Thus
any each process which calls krb5_walk_realm_tree() needs to have
access to the file.
The client, intermediate KDCs, server's KDC and Server all call
krb5_walk_realm_tree() directly or indirectly via the
krb5_check_transited_list() routines. For this to function
properly, the krb5_walk_realm_tree() needs to return the same
path at all points.
The client uses the krb5_walk_realm_tree() to determine the path
to the final server. The /krb5/krb.capaths needs to be world
readable and needs to contain all the paths which the client need
to access any of the servers. It should have an entry for each of
the none hierarchical realms listed in the /krb5/krb.conf file.
It does not need all of the paths in the world, only the ones it
will use. If the file is compromised, the client will fail to
determine a valid path, and the KDC's it tries to contact will be
unable to give it TGTs or the krb5_check_transited_list() routine
in the KDC will not allow the path. Thus the worse case is a
denial of service.
The intermediate KDCs need access to their version of the
/krb5/krb.capaths file so they can check via the
krb5_check_transited_list() to see if the transited path is
valid. The need an entry for each client realm - server realm for
which they are on the path. (See below for comments on if this is
really needed.)
The servers KDC needs access to its own /krb5/krb.capaths file
and needs an entry for each client realm - its realm, and if it
is an intermediate KDC then the above holds true as well. It is
important that this file be protected, since it is used in the
validation of the transited field.
The server needs access to its own /krb5/krb.capaths file because
it also checks the transited field. It only needs entries for
client realms which will be contacting it.
The current implementation of configurable authentication paths
which was first tested with 5.4.1 and then with 5.4.2 would drop
right into 5.4.3 since the krb5_walk_realm_tree() routine has not
changed.
WHEN IS VALIDATION OF THE TRANSITED FIELD NEEDED
Prior to 5.4.3 there was no validation. With 5.4.3 each KDC and
server validates the transited field. I believe that the
following is true:
"Only the KDC needs to validate the transited field
of a foreign TGT when it is granting tickets for servers
in its own realm."
The RFC says: "It is important for the end-service to know which
realms were transited when deciding how much faith to place in
the authentication process". Although the end service could still
check this, if its own KDC has already checked the transited
field before giving out the ticket for the service, that should
be adequate for most services.
The reason I bring this up is that the additional checks which
are done in 5.4.3 don't hurt, and don't cost much, until
configurable authentication paths and the maintaince of their
/krb5/krb.capaths files are considered. If each intermediate KDC
checks the transited field, it must have an entry in its
/krb5/krb.capaths file for each possible route. This does not
scale well. In our ESNet sets of realms its not to bad, but say
we expand it to all of DOE with a DOE.GOV which shares a key with
the ES.NET KDC. Any new realms introduced in the DOE.GOV side
need an entry in the ES.NET. What happens with a GOV realm?
Since the purpose of the transited field is to save up the
information about which realms were involved in the
authentication so the end-service can check it, why do each of
the intermediate KDCs need to check it? I don't believe they need
to.
MODIFICATIONS TO CONFIGURABLE AUTHENTICATION PATHS
The addition of the capaths code and a simple change to the
client, can produce the desired effects of the "shortest"
authentication path code which as pointed out above is currently
optional, and simplify the maintaince of the /krb5/krb.capaths
files.
By having the the client use its /krb5/krb.capaths file to
determine the correct path, and having it ask each KDC along the
path for a TGT to the next KDC rather then the final KDC, the
intent of the "shortest" can be informed. The final KDC which
also has its own /krb5/krb.capaths file will validate the
transited field before handing out tickets for servers in its
realm, and will verify that only KDCs on the correct path were
involved in the authentication process. Since its
/krb5/krb.capaths and the clients /krb5/krb.capaths define the
same path, and take into account any "shortest" paths, the intent
of the "shortest" path can be enforced.
By having the client ask each KDC on the path for TGT for the
next KDC, the intermediate KDC's do not have to know what the
intended path between the client and the servers realm is. All
they have to do is give out a TGT. Their /krb5/krb.capaths files
can be greatly simplified in that it only needs to contain
entries for itself if it is going to grant tickets for servers in
its own realm.
CONCLUSION
I believe the above has addresses the two issues which you
pointed out in your note:
(1) "How your configured authentication paths interact with the KDC
specified path traversal,"
* This was addressed in the SHORTEST section, and I believe
I have shown that with the current validation the
"shortest" code is optional. I also show in the
MODIFICATIONS TO CONFIGURABLE AUTHENTICATION PATHS
section how this can be improved.
(2) "How your configurable authentication paths interact with the
validation of the transited field on the verifier."
* This was addressed in the CONFIGURABLE AUTHENTICATION
PATHS and WHEN IS VALIDATION OF THE TRANSITED FIELD
NEEDED and states which of the /krb5/krb.capaths files
need to protected, and how they must be kept in sync.
ADDITIONAL QUESTIONS AND ANSWERS
In your note you had a paragraph of additional questions which I
have broken out below, with answers to each questions:
o With respect to the second issue, the verifier (application
server) needs to verify the realms in the transited field to
make sure that only realms legitimately in the path are
present. In the default case, such realms are those in the
path between the client and the verifier. Does the use of a
configurable authentication paths mean that the verifier must
also accept the path (the answer is clearly yes).
* It means that the verifier expects the client to use the
correct path, and will only accept this path.
o Does this present any interoperability issue?
* I don't think so. If there are no entries in the
/krb5/krb.capaths which match or there is no file, then the
code defaults to the current hierarchical path. (But maybe
the verifier should default to not accepting the request.
This could be an improvement in that the verifier's system
manager has to OK the cross authentication path.)
o Will the verifier accept both the true hierarchical
arrangement, and the configurable paths, or both?
* No, it only accepts one. The output of the
krb5_walk_realm_tree() is modified.
o What happens if the client and verifier have a different path?
* The verifier expects the client to use the correct path, and
if any additional realms are listed, it will be rejected.
o Do we need two sets of configuration, one for the verifier
accepts, and the other for what the client uses?
* You could have a single gigantic file with all the
possible n*(n-1)/2 paths (n realms). But the client only
need to know the paths to the KDCs of servers it wants to
contact. So it could have less then N entries. The verifier
only needs to know the paths from the clients which will be
contacting it, so it has N entries as well.
I hope this addresses most of your concerns about the
modification, and I hope my comments on the "shortest" code
and the statement about only the servers KDC need to validate
the transited field are helpful.
I, as well as other members of the ESnet Cross Realm Authentication
Project, are very interested in your future work on Kerberos V6,
and public key encryption. And if there is anything we can do
to assist you in this effort, feel free to contact us.
Doug
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
