I apologize for the cross-posting but I believe that in order for this proposal receive adequate feedback that it must be discussed among both the MIT Kerberos
administrator and MIT Kerberos Developer communities.

In the current implementation of the MIT KDC there are two principal policy
flags that interact in what I believe is an undesirable way when applied to
service principals. Copying from the Kerberos v5 System Administrator's Guide:

*{-|+}allow_svr*
   The “-allow_svr” flag prohibits the issuance of service tickets for
   this principal. “+allow_svr” clears this flag. In effect, “-allow_svr”
sets the KRB5_KDB_DISALLOW_SVR flag on the principal in the database.
*{-|+}allow_tix*
   The “-allow_tix” option forbids the issuance of any tickets for this
   principal. “+allow_tix” clears this flag. The default is “+allow_tix”.
   In effect, “-allow_tix” sets the KRB5_KDB_DISALLOW_ALL_TIX flag on
the principal in the database. When a TGS or AS request is received by the KDC, under the current implementation the KDC will examine the client principal to determine whether or not +allow_tix is set. If not, it will reject the request.

It also naturally checks the service principal to determine whether or not +allow_svr is set.
If not, it will reject the request.

However, the KDC will also check the service principal to determine it it is +allow_tix
or not.  If it is not, then the KDC will also reject the request.

I believe that the meaning of allow_tix should be altered such that it only applies to the client in a TGS or AS request. This would permit -allow_tix to be applied to a service principal and ensure that no client ticket requests can be satisfied for that service principal while at the same time permitting other principals to obtain service tickets. Organizations that wish to disable the issuance of service tickets for the service principal
would apply -allow_svr to the principal in addition to -allow_tix.

I believe that making this change would permit a more robust security policy to be applied to service principals without requiring the additional of new flags that would have overlapping
and conflicting meaning with the existing flags.

Let the discussion begin.

Jeffrey Altman
Secure Endpoints Inc.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to