# Presentation: 256231

## Cross-Cell Authentication Using Configurable Authentication Paths

- Douglas E. Engert
- DEEngert@anl.gov
- Argonne National Laboratory
- 11/05/96

## Introduction

- What is Cross-Cell Authentication?
- How Kerberos and DCE implement it
- What’s wrong with this?
- Configurable Authentication Paths
- Results of testing
- Futures

## Definitions

- Cell  Vs  Realm
- Security Server Vs KDC
- /.../cellname/user Vs user@realm
- principal and account Vs principal

## Cross-Cell Authentication

- A user in one cell can authenticate to a service in another cell
- Feature of Kerberos
- Version 4 - Direct cell to cell
- Version 5 - Allows intermediate cell
- Requires cell_admins to setup shared keys

## Kerberos Basics 

- Key Distribution Center KDC or DCE Security Server

- Client

- Server

- Cache

- kinit

- APPL

- APPLD

- User

**Notes:**
This shows the traffic flow when a client gets tickets. 	
The user runs the kinit program which gets a “ticket granting ticket” TGT that is stored in the cache usually on disk.
The application, such as telnet, checks the cache to see if it has a ticket for the server, telnetd.  If it does not, it will contact its own KDC using the TGT to get a ticket for the server.  The ticket is encrypted in the server’s key, so when the server receives the ticket it knows that it was generated by the KDC for this user.  
The user’s password is never sent over the network.  It is only used in the kinit program.  

## Cross Cell AuthenticationShared Keys

- Client’s KDC

- KDC 1

- KDC 2

- Server’s KDC

- User

- Server

**Notes:**
This shows who shares key with whom.  Kerberos 5 can use this string of trust to allow the user to get a ticket for a server in another realm.  The server will check who was involved in the authentication process and decide whether or not to allow the request. 
Each of the realms is administered by a different organization.  The administrators take care of setting up the shared keys between each site.

## Cross Cell Authentication

- Client’s KDC

- KDC 1

- KDC 2

- Server’s KDC

- Client

- Server

- Cache

- kinit

- APPL

- APPLD

- User

**Notes:**
This shows the traffic flow when a client gets tickets. 	

The user runs the kinit program which gets a “ticket granting ticket” TGT which is stored in the Cache on disk.
The application such as telnet, checks the cache to see if it has a ticket for the server, telnetd, and if it does not, it will contact its own KDC to get a ticket. If the server is in another cell, it will contact its own KDC to get a ticket for the next KDC, until it gets a ticket for the servers KDC. It will ask that KDC for a ticket to the server. 

Note that most of the “smarts” for cross cell authentication are in the application,  i.e. the Kerberos Library routines. The adjoining KDCs above each share a key with each other, but don’t directly communicate. I believe that the OSF/DCE 1.1 security server has the ability to grant these TGTs for the next cell. We need to check on this. 

## Hierarchical Organization of Cells

- “Realms are typically organized hierarchically”
- RFC 1510 Section 1.1
- Kerberos 5 use DNS style
- DCE uses cell aliases
- They don’t interoperate

## Kerberos 5 Hierarchy

- Right to left separator is “.”
- A.B.C
- B.C
- C
- Z.C
- Y.Z.C

## DCE Hierarchy

- Left to Right separator is “/”
- /c/b/a
- /c/b
- /c
- /c/z
- /c/z/y
- Requires user to specify the hierarchy
- Transitive Trust

## What's wrong with this?

- The world is not hierarchical
- How does ANL.GOV authenticate to WIDGET.COM
- Who runs GOV, COM, EDU, ORG cells?
- Can’t belong to more then one hierarchy
- DCE and K5 do not interoperate
- Hierarchy is tied to the realm name

## Cross Cell

**Notes:**
This slide shows the hierarchical nature of cross realm authentication. In the original MIT implementation, the hierarchy was defined by the realm/cell name. In our modifications, it is defined in a table, thus allowing realm names which are convenient for the users and match their domain names to be chosen.

It was also designed to show that if ESnet was the four realms in the lower left corner, at a later time, the ESnet cell could communicate with a DOE cell, with the four nodes on the other side being other parts of DOE. 

## Cross Cell

**Notes:**
This slide shows the hierarchical nature of cross realm authentication. In the original MIT implementation, the hierarchy was defined by the realm/cell name. In our modifications, it is defined in a table, thus allowing realm names which are convenient for the users and match their domain names to be chosen.

It was also designed to show that if ESnet was the four realms in the lower left corner, at a later time, the ESnet cell could communicate with a DOE cell, with the four nodes on the other side being other parts of DOE. 

## Cross Cell

**Notes:**
This slide shows the hierarchical nature of cross realm authentication. In the original MIT implementation, the hierarchy was defined by the realm/cell name. In our modifications, it is defined in a table, thus allowing realm names which are convenient for the users and match their domain names to be chosen.

## Cross Cell

**Notes:**
This slide shows the hierarchical nature of cross realm authentication. In the original MIT implementation, the hierarchy was defined by the realm/cell name. In our modifications, it is defined in a table, thus allowing realm names which are convenient for the users and match their domain names to be chosen.

## Configurable Authentication Paths

- “Realms are typically organized hierarchically.... If a hierarchical organization is not used, it may be necessary to consult some database in order to construct an authentication path between realms.”
- RFC1510 Section 1.1
- So use a database!

## Configurable Authentication Paths

- lib/krb5/krb/walk_rtree.c
- krb5_walk_realm_tree(client,server,sep)
- Return the authentic	ation path based on client and server realms
- Used by client to find authentication path
- Used by server to check transited field
- Has been incorporated in MIT Kerberos 5 beta 6 and beta 7
- krb5.conf
- New section [capaths]

## Why Check the Transited Field ?

**abc**

**abc**

**ghi**

**def**

**Client: abc                Server: ghi       Transited field: def**
**Bogus client: abc     Server:ghi      Transited Field: xyz,jkl,def**
**DCE 1.0.3 did not check!  **

**xyz**

**jkl**

## Testing CAPATH in DCE  

- Modified DCE 1.1 walk_rtree.c
- Kept simple to show proof of concept
- walk_rtree.c is in shared libdce
- capath.conf
- equivalent to krb5.conf [capaths] information

## capath.conf

- client-cell   server-cell   intermediates dce.anl.gov dce.es.net   .dce.anl.gov dce.pnl.gov  dce.es.netdce.es.net  dce.anl.gov  .dce.pnl.gov dce.anl.gov  dce.es.netdce.es.net  dce.pnl.gov  .dce.pnl.gov dce.es.net   .
- n*(n-1) number of records
- Each cell need 2*(n-1) records

## Testing CAPATH in DCE

- Need modified libdce.so on server and security server
- Need modified libdce.so on client
- AIX 4.1.4  - relinked libdce.a
- Solaris 2.5 - setenv LD_PRELOAD
- HP - Have not figured out a way yet

## Cross Cell Authentication

- Cache

- dce_login

- rlogin

- klogind

- User

**dce.anl.gov**
**HP**

**dce.es.net**
**Transarc**

**dce.pnl.gov**
**Transarc**

- secd

- secd

- secd

**AIX**

**libdce.so**

**Notes:**
This shows the traffic flow when a client gets tickets. 	

The user runs the declogin program which gets a “ticket granting ticket” TGT which is stored in the Cache on disk.
The application, such as nlogin, checks the cache to see if it has a ticket for the server, klogind, and if it does not, it will contact its own secd to get a ticket.  If the server is in another cell, it will contact its own secd to get a ticket for the next secd, until it get a ticket for the server’s secd. It will ask that secd for a ticket to the server. 

Note that most of the “smarts” for cross cell authentication are in the application, i.e. the Kerberos Library routines linked into orlogin. The adjoining secd above each share a key with each other, but don’t directly communicate. With a modified libdce.so this works.

## Cache

- pembroke% /krb5/bin/rlogin moonbeam.pnl.gov -x -l engert
- This rlogin session is using DES encryption for all data transmissions.
- Last login: Thu Oct 24 17:01:49 from pembroke.ctd.anl
- Sun Microsystems Inc.   SunOS 5.5.1     Generic May 1996
- moonbeam.pnl.gov% exit
- moonbeam.pnl.gov% logout
- Connection closed.
- pembroke% /krb5/bin/klist
- Ticket cache: /opt/dcelocal/var/security/creds/dcecred_626fb170
- Default principal: b17783@dce.anl.gov
- Valid starting      Expires             Service principal
- 25 Oct 96 09:03:01  25 Oct 96 19:03:01  krbtgt/dce.anl.gov@dce.anl.gov
- 25 Oct 96 09:03:17  25 Oct 96 19:03:01  afsx/anl.gov@dce.anl.gov
- 25 Oct 96 09:10:28  25 Oct 96 19:03:01  krbtgt/dce.es.net@dce.anl.gov
- 25 Oct 96 09:10:28  25 Oct 96 19:03:01  krbtgt/dce.pnl.gov@dce.es.net
- 25 Oct 96 09:10:31  25 Oct 96 19:03:01  host/moonbeam.pnl.gov@dce.pnl.gov

## Cross Cell Authentication

- Cache

- dce_login

- rgy_edit

- RPC

- User

**dce.anl.gov**
**HP**

**dce.es.net**
**Transarc**

**dce.pnl.gov**
**Transarc**

- secd

- secd

- secd

**AIX**

**Notes:**
This shows the traffic flow when a client gets tickets. 	

This shows what I would like to see work.

## Cache

- Klist output
- Default principal: b17783@dce.anl.gov
- Server: krbtgt/dce.anl.gov@dce.anl.gov
- Client: dce-ptgt@dce.anl.gov	Server: krbtgt/dce.anl.gov@dce.anl.gov
- Client: dce-ptgt@dce.anl.gov	Server: dce-rgy@dce.anl.gov
- Server: krbtgt/dce.es.net@dce.anl.gov
- Server: krbtgt/dce.pnl.gov@dce.es.net
- Server: dce-ptgt@dce.pnl.gov
- Client: dce-ptgt@dce.anl.gov	Server: krbtgt/dce.es.net@dce.anl.gov
- Client: dce-ptgt@dce.anl.gov	Server: krbtgt/dce.pnl.gov@dce.es.net
- Client: dce-ptgt@dce.anl.gov	Server: dce-ptgt@dce.pnl.gov

## Compatibility

- Defaults to previous method if:
- capath.conf not found
- client-server record not found
- Works with MIT Kerberos

## Futures

- Request OSF and HP incorporate the modification
- Replace capath.conf file
- Store in registry
- Locally cached by dced
- Public key for cross-cell
- capath.conf then becomes list of trusted Cas

## ESnet Pilot Project

- Final Report and Recommendations of the ESnet Authentication Pilot Project
- G. R. Johnson	PNL
- C. L. Athey		LLNL
- D. E. Engert		ANL
- J. P. Moore		PNL
- J. E. Ramus		NERSC
- http://www.es.net/pub/esnet-doc/auth-and-security/auth-pilot-report.ps

**Notes:**
The final report can be found at the ESnet zaxC          server.

## The End

## Who has our mods

- Downloads of k5[67].cdiffs.*
- .edu
- bu, utah, umich, uoknor, stanford, cornell, fsu, geneseo, unm, ncsu, colorado, uic, uchicago, osc, vanderbilt, missouri, arizona, louisville
- .com/org
- sun, dec, bell, hp, ibm, unisys, auspex, cybersafe, cray, xerox, hitc, mitre
- .gov/mil
- nih, lanl, ameslab, nrl.navy, ornl, llnl, jpl.nasa, pppl, sandia, noaa, nasa, nosc, wpafb.af
- Foreign
- th, ru, eg,  hk, mx,  hu, ae, se, uk, no, cz, ca

## Cross-Cell Authentication Using Configurable Authentication Paths

- Douglas E. Engert
- DEEngert@anl.gov
- Argonne National Laboratory
- 11/05/96

## DICCE Progress

- Cross-cell Cook book
- Kerberos 5 beta 7