Today's Page Hits: 2
This page validates as XHTML 1.0, and will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device. It was created using techniques detailed at glish.com/css/.
Tuesday June 14, 2005 Kerberos is a network authentication protocol, designed to provide strong authentication for client-server applications by using shared secret cryptography. Kerberos will not only authenticate a client to a server, but the server to the client.
All entities (users and services) have credentials stored in clear text in a central database. The design of Kerberos was done in time before secure transport layers (like SSL or IPSec) were created or common. Kerberos was designed for use embedded into unencrypted communications, and therefore certain design assumptions were made.
On the Key Distribution Center (KDC) servers, all credentials are stored encrypted with the KDC master’s key. This is necessary for the KDC to access the clear text of the credentials, and ensure that no credentials cross the wire in clear text. This is in contrast to the basic form of network authentication that uses a simple username and plaintext password. Frequently, systems that use this type of authentication will store the passwords in a hashed form, in order to defend against the password database from being stolen. Kerberos implementations need to guard carefully against the credentials database from being stolen.
The intent of Kerberos is to be tightly integrated into the environment of a client. The key example here is Windows 2000 and Windows XP clients, which can use a Kerberos login to authenticate the user to the computer. Then any application that is Kerberos aware may access the Kerberos credentials and authenticate to network services, with the authentication transparent to the user.
In order to facilitate client-server applications using Kerberos services, a standardized API and network interchange model was developed called GSS-API (Generic Security Services Application Programming Interface). GSS-API defines a standard programming model for both clients and servers, and a interchange format using tokens that are opaque to the application using GSS-API. In order to authenticate to each other, a client application and server application will exchange a series of GSS-API tokens, with the content of the tokens interpreted by the GSS-API libraries. There are multiple GSS-API token formats, one of which encapsulates Kerberos tickets into the token.
The interaction between the Kerberos key distribution center (KDC), and clients and servers, is centered on ‘tickets’. Kerberos clients communicate with the KDC to acquire a ticket, which they then provide to a server. Servers validate the tickets that clients provide them.
All of the protocols and interfaces of Kerberos are defined by IETF RFC’s. RFC 1510 defines the core protocol, and RFC 2743 defines GSS-API. Kerberos GSS-API tokens are defined by RFC 1964. Kerberos has a number of possible encryption and hash algorithms that can be used; these are defined elsewhere.
At the core, Kerberos is client-server, remote procedure call, network protocol. The client makes a request of the server, and the server responds to a request. There are two key sets of exchanges between the client and server – the Authentication Service exchange, and the Ticket Granting Service exchange.
The end result of this exchange is the client has an authentication ticket and session key that it uses for accessing the Ticket Granting Service.
Once a user has successfully decrypted the response from the authentication service, the user now needs to communicate with the Ticket Granting Service to get first, a Ticket Granting Ticket, and later server specific tickets. This step is necessary to prove to the server that the client actually knows the user’s secret – if the client does not know the user’s secret, then the response from the authentication service won’t be successfully decrypted.
The Sun Java System Access Manager server manages security for web applications. The core services allow web browser users to authenticate themselves to a central service, then to access multiple web sites with a shared session cookie. The central Access Manager service works with policy agents installed on web servers to validate the end users session cookie. The Access Manager policy agents will allow or deny the end user to access protected URL resources based on policies configured on the central Access Manager service.
Access Manager is primarily designed to work with the standard web browsers (Internet Explorer, Netscape, Mozilla and Firefox) as user clients. Policy agents are produced for a wide variety of industry standard HTTP servers (Apache, IIS, Sun Web Server); Java Application servers (Sun Application Server, WebLogic, WebSphere); and web front-ends for enterprise applications (SAP, Domino, Peoplesoft). Upon authentication, a session cookie is stored in a user’s web browser, and this session cookie is provided to all web servers in a given domain.
The security of Access Manager is based on methods that are built into modern web browsers and web servers – SSL or TLS to protect the transport layer, and encrypted cookies stored in a web browser.
Access Manager has a flexible, modular user authentication system. The authentication system works on similar principals to the PAM and JAAS authentication systems, and in fact there is support for integrating a JAAS authentication module into Access Manager.
When a user accesses the authentication system, which authentication modules presented to the user are based on what the administrator has configured for the system, and by the URL the user accesses. By default, Access Manager will authenticate users in a LDAP database, using a single form that requests a username and password for the user, However, administrators can choose to have more complex authentications (such as using digital tokens that produce one-time passwords), or authentication that can happen transparent to the end user; either with a digital certificate, or a Kerberos authentication.
By itself, Kerberos does not define a way for it to work with a web browser and web server. Microsoft defined a way for integration to happen between a Kerberos enabled host, a web browser, and a Kerberos enabled web server. This method was published in an IETF draft document, and Internet Explorer, Mozilla and Firefox have implemented the client portion. IIS, and Apache have implemented the server portion.
The mechanism defined uses HTTP headers (‘WWW-Authenticate’, and ‘Authorization’) defined in the standard HTTP protocol, but extends them with GSS-API specific ‘Negotiate’ method. When a web server wants a client to authenticate using this method, it sends a ‘401 Unauthorized’ response to a HTTP request. Then, the server expects the client to retry the request with a ‘Authorization’ header, and a GSS-API token.
Access Manager implements the WWW-Negotiate authentication protocol with the ‘WindowsDesktopSSO’ authentication module. In order for a user to authenticate with this module, they either need to have this module configured as the default one for their organization, or explicitly name the module in the URL used to access the authentication service.
This diagram shows how a client will use a Kerberos ticket, and the WWW-Negotiate authentication protocol to authenticate to a web server. Omitted from the diagram is the first step in the sequence – the web server has requested a Kerberos ticket by returning a ‘401 Unauthorized’ response to the web browser.
Microsoft has taken the lead on integrating Kerberos with its clients and servers. The primary network authentication protocol used by Windows 2000 domains and Active Directory is based on Kerberos. Microsoft also has published RFCs and draft RFCs with the IETF, documenting various extensions and updates to the core Kerberos protocol. One of these extensions documented in a RFC is a GSS-API token format called SPNEGO. This token format is a useful way for a client to communicate to a server all the possible types of GSS-API tokens they are capable of using. While GSS-API was designed primarily for the use of Kerberos implementations, there are many GSS-API token formats defined that do not use Kerberos at all. SPNEGO allows a client to state that in addition to Kerberos, they may be able to send a different authentication token like NTLM.
By default, Internet Explorer on Windows will send SPNEGO tokens to servers that request a GSS-API token with the WWW-Negotiate protocol.
Kerberos is a multi-platform authentication system – clients and servers may run on many variants of Unix, Macintosh OS, or Windows. The key development of the standards and the free versions of Kerberos were primarily done on Unix variants at MIT.
The Mozilla project integrated support for the WWW-Negotiate protocol into the 1.7 and later releases. All recent Mozilla variants, on all supported platforms, can use this protocol. The author of this paper has personally tested Mozilla, Firefox, and Camino on Mac OS X, and Firefox on Solaris.
The ability to generate a SPNEGO token is dependent on the underlying GSS-API libraries, and not the browser. All browsers on the Windows platform will generate these tokens, as well as Mozilla on Solaris 10. On other platforms, the browsers will generate Kerberos v5 tokens.
Identity Server 6.2 (in JES 2004 Q2) supported only SPNEGO tokens with AD as the server. Access Manager 6.3 (in JES 2005 Q1) supports both SPNEGO tokens and Kerberos tokens; with any Kerberos server.
Wyllys Ingersoll has an excellent explanation of how to set up Kerberos authentication with Apache as the web server.
Documentation for configuring Kerberos KDC on Solaris 10.
SUNPME.COM red.iplanet.com icebox34.red.iplanet.com icebox15.red.iplanet.com kws/admin icebox12.red.iplanet.com icebox15.red.iplanet.com, icebox34.red.iplanet.com
[libdefaults]
default_realm = SUNPME.COM
default_tgs_enctypes = des-cbc-crc des-cbc-md5 des-cbc-md4
default_tkt_enctypes = des-cbc-crc des-cbc-md5 des-cbc-md4
permitted_enctypes = des-cbc-crc des-cbc-md5 des-cbc-md4
[realms]
SUNPME.COM = {
kdc = icebox34.red.iplanet.com
kdc = icebox15.red.iplanet.com
admin_server = icebox34.red.iplanet.com
}
[domain_realm]
.red.iplanet.com = SUNPME.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
gkadmin = {
help_url = http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
}
[kdcdefaults]
kdc_ports = 88,750
[realms]
SUNPME.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}
kws/admin@SUNPME.COM * kiprop/icebox15.red.iplanet.com@SUNPME.COM p
host/icebox34.red.iplanet.com@SUNPME.COM host/icebox15.red.iplanet.com@SUNPME.COM
# /usr/sbin/kdb5_util create -r SUNPME.COM -s # /usr/sbin/kadmin.local > addprinc kws/admin > addprinc -randkey kiprop/icebox34.red.iplanet.com > ktadd -k /etc/krb5/kadm5.keytab kadmin/icebox34.red.iplanet.com > ktadd -k /etc/krb5/kadm5.keytab changepw/icebox34.red.iplanet.com > ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw > ktadd -k /etc/krb5/kadm5.keytab kiprop/icebox34.red.iplanet.com > quit # svcadm enable -r network/security/krb5kdc # svcadm enable -r network/security/kadmin # /usr/sbin/kadmin -p kws/admin > addprinc -randkey host/icebox34.red.iplanet.com > addprinc clntconfig/admin > ktadd host/icebox34.red.iplanet.com > quit
# /usr/sbin/kadmin -p kws/admin > addprinc -randkey host/icebox15.red.iplanet.com > addprinc -randkey kiprop/icebox15.red.iplanet.com > quit # svcadm restart network/security/kadmin
'sunw_dbprop_slave_poll = 2m' to kdc.conf.# /usr/sbin/kadmin -p kws/admin > ktadd host/icebox15.red.iplanet.com > ktadd kiprop/icebox15.red.iplanet.com > quit # /usr/lib/krb5/kpropd # /usr/sbin/kdb5_util stash # svcadm enable network/security/krb5kdc
# kadmin -p kws/admin > ank hippie > ank -randkey HTTP/icebox12.red.iplanet.com > quitPut the host user in a keytab:
# kadmin -p kws/admin > xst -k /etc/opt/SUNWam/config/AM.keytab\ HTTP/icebox12.red.iplanet.com > quit # chown orion:orion /etc/opt/SUNWam/config/AM.keytab
HTTP/icebox12.red.iplanet.com@SUNPME.COM/etc/opt/SUNWam/config/AM.keytabSUNPME.COMicebox15.red.iplanet.com