Developer Overview

Kerberos, GSSAPI, & SASL

Jay Kline
Version 1.0
Developer Overview
Introduction................................................................................................................................................1
Kerberos.....................................................................................................................................................1
GSSAPI......................................................................................................................................................2
SASL..........................................................................................................................................................3
A Few Quirks.............................................................................................................................................3
Revision History
Date Author Change Description Affected Section
2007/0/0! Jay Kline "nitial #riting
Introduction
$here are %ultiple #as to #rite progra%s that #ill interact #ith Ker&eros. $his
docu%ent #ill descri&e details useful for i%ple%enting Ker&eros in 'penfire and
Spar(. $he )*++ protocol prefers to use SAS, as its authentication %echanis%-
#hich defines a %ethod of using the .SSA+" protocol. .SSA+" in turn uses
Ker&eros.
Kerberos
Ja/a has had support for #or(ing directly #ith Ker&eros since 1..2. Ja/a has
i%ple%ented these o&0ects
$he Ja/a Authentication and Authori1ation Ser/ice 2JAAS3 pro/ides the o&0ect
co%.sun.security.auth.%odule.Kr&4,ogin*odule 2as #ell as %odules for other
protocols3 #hich can e/en perfor% the pro%pting to perfor% an Ker&eros login
and o&tain a $.$. JAAS is the Ja/a e5ui/alent to +A*- and is designed to &e
configured #ith separate configuration files- #hich can indicate #hich %odules
and options to use. An e6a%ple JAAS configuration is pro/ided &elo#.
Configuration is pro/ided &y the 0a/a6.security.auth.login .Configuration o&0ect-
#hose default i%ple%entation is a file. "t is possi&le to i%ple%ent a separate
Configuration o&0ect that pulls the infor%ation fro% a different source or file
for%at. $he Configuration o&0ect pro/ides an application 2specified as
Application7a%e in the e6a%ple3 #ith any nu%&er of %odules 2gi/e the full class
na%e3 #ith infor%ation a&out each %odule. A %odule can &e re5uired- re5uisite-
sufficient- or optional. 8or the purposes of this docu%ent- #e #ill only discuss
configurations #ith Ker&eros &eing the only %odule specified as re5uired. "f an
application na%e is not found- the application 9other: is loo(ed up last to pro/ide
so%e defaults.
Kr&4,ogin*odule options;
use$ic(etCache < "f true- get credentials fro% a tic(et cache. "f this is false-
it #ill atte%pt to pro%pt the user to authenticate- and not (eep the
credentials #hen done- thus a/oiding the SS' concept.
do7ot+ro%pt < "f true- the %odule #ill %a(e no atte%pt to pro%pt the user
to authenticate. "f false- the %odule #ill pro%pt the user to authenticate if
credentials can not &e o&tained fro% the tic(et cache.
useKey$a& < "f true- the %odule #ill o&tain credentials fro% the (eyta&. Set
page 1
ApplicationName {
com.sun.security.auth.module.Krb5LoginModule required debug=true;
};
this to true for ser/ers.
(ey$a& < $his is the location of the (eyta& 2if useKey$a& is true3. $he default
if this option is not set is 'S dependent.
storeKey < Set this to true for ser/ers. Since the ser/er has no #ay of
pro%pting a user- it needs to store the principals (ey the Su&0ect=s pri/ate
credentials. >ithout this option- the ser/er #ill fail since the credentials #ill
not &e stored.
principal < $his is to &e set to the principal to &e used for the ser/er.
Although you can set the principal for clients too- the client principal can &e
deter%ined fro% the credential cache- so it should &e o%itted.
$here are other options a/aila&le- &ut they #ill not &e used in this docu%ent.
GSSAPI
.SSA+" is a generic interface for passing credentials &et#een principals. Since
Ker&eros is still &eing used- the JAAS Configuration is still used. .SSA+" o&0ects
use co%.sun.security.0gss as the prefi6 for the application na%e specified in the
configuration file- and uses .initiate as the suffi6 for the client- and .accept as the
suffi6 for the ser/er. Specific protocols are loo(ed up 2such as .(r&4.initiate3 &ut
using specific protocols can li%it the fle6i&ility of the application in the future.
'&taining ne# credentials is protocols specific- therefore .SSA+" can not &e used
to ac5uire ne# credentials. $his %eans the do7ot+ro%pt option should &e set to
true for .SSA+" applications.
Since the goal is to ha/e uni/ersal access to the credentials- the syste% property
jv!"security"ut#"useSubject$redsOnly %ust &e set to false. $his property
#hen set to true 2the default3 only allo#s the .SSA+" o&0ects to access credentials
in the Su&0ect o&0ect. >hen set to false- then the .SSA+" o&0ect %ay o&tain
page 2
! "##A$% &lient !
com.sun.security.'gss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
doNot$rompt=true use(ic)et&ache=true;
};
! "##A$% #er*er !
com.sun.security.'gss.accept {
com.sun.security.auth.module.Krb5LoginModule required
storeKey=true doNot$rompt=true useKey(ab=true
principal=+,mppser*er.e,ample.com-./AM$L..&0M+;
};
credentials fro% other places- such as the credential cache used outside Ja/a.
"n addition to authentication- .SSA+" pro/ides 9Channel ?indings: for secure
co%%unications. "n essence- it is a co%%unication channel cryptographically
&ound to the initial authentication. $he ad/antage is this can &e e6ported to
outside channels. $he co%%on e6a%ple is SS@/2 o/er a V+7- #here the .SSA+"
credentials initiating the V+7 are shared #ith the SS@/2 session to a/oid dou&le
encryption. $his could &e i%ple%ented in the )*++ protocol #here the SS, (eys
are deter%ined &y the .SSA+" negotiation- &ut there #ould &e little gain o/er the
current i%ple%entation.
SASL
Ja/a pro/ides &oth SAS, client and ser/er o&0ects to perfor% the %ost co%%on
authentication and authori1ation %echanis%s- including .SSA+". $he .SSA+" SAS,
o&0ects %a(e use of the .SSA+" infrastructure- so the sa%e configuration file #ill
&e used.
SAS, allo#s the client and ser/er to choose a %echanis% and negotiate
properties for the session. $his %eans it #ould &e possi&le for the ser/er to
accept &oth .SSA+" and +,A"7 %echanis%s- so if a client does not ha/e any
.SSA+" credentials- a +,A"7 login is still possi&le. Although this %a(es things
easier for the client- it does reduce the security of the authentication to the
#ea(est %echanis%.
SAS, o&0ects %a(e use of call&ac(s to pro/ide interaction #ith the application.
>ith .SSA+"- the client already possesses the full credentials- so no call&ac(s are
needed to o&tain the infor%ation 2such as the na%e- real%- or pass#ord3. $he
ser/er then only needs to %a(e use of the Authori1eCall&ac( to perfor% the
authori1ation after authentication ta(es place.
Since .SSA+" and Ker&eros allo# the ser/er to authenticate to the client- the SAS,
property SABVABCAD$@ should &e set to true to force the authentication. "f the
ser/er cannot authenticate to the client 2in the case of a co%pro%ised ser/er- for
e6a%ple3 the connection #ill &e ended.
Additionally- the SAS, property E'+ 2Euality of +rotection3 can &e set to one of
three le/els. $he default- is to 0ust authenticate. Additionally integrity chec(ing
and confidentiality can &e added. >ith .SSA+" these additional le/els are
perfor%ed using the channel &indings.
A %ew &uir's
$here are a fe# 5uir(s #hen #or(ing #ith this in practice. Ker&eros relies hea/ily
on encryption- #here the algorith%s used are dictated &y the KDC. Ja/a needs to
&e a&le to understand the encryption types to %a(e use of the tic(ets or (eyta&s.
Due to DS A6port Controlled "nfor%ation 2AC"3 la#s so%e cryptography algorith%s
cannot &e e6ported- and the default install of Ja/a #ill not #or( #ith those
algorith%s 2AASF24! is one of the%3. Sun pro/ides a strong Ja/a Cryptography
page 3
A6tension policy as a separate do#nload. Depending on the algorith%s used- and
the country you reside in- it %ay not &e possi&le to use Ja/a #ith Ker&eros legally.
$he %ost frustrating part a&out needing the JCA- is #hen Ja/a cannot use the
encryption type specified in a tic(et or (ey- Ja/a acts as though it could not find
any tic(et or (ey. $his gi/es /ery %isleading error %essages.
8or so%e reason- Ja/a #ill not update the credential cache of a user #ith the
o&tained tic(ed /ia SAS,G.SSA+". $his #ill not cause any significant pro&le%s-
&ut is #asteful- since each repeat authentication re5uires re5uesting a ne# tic(et
fro% the KDC #hen it could ha/e stored and reused the pre/ious tic(et. $here
%ay &e a #or(around for this- &ut it is not #ell docu%ented.
page 4