Kerberos Feature Request

Henry B. Hotz hotz at
Wed Feb 11 14:04:52 EST 2004

Yes, the user can *add* authorization data, but that data can only 
subtract from your authorizations.  If you want data that adds to 
your authorizations then it must be added by the KDC (and signed by a 
key you don't know).  It's the latter that I've been talking about.

At 12:49 PM -0500 2/11/04, Derek Atkins wrote:
>Daniel Kouril <kouril at> writes:
>>  Henry B. Hotz wrote:
>>>  I'm not sure if we're on the same wavelength or not.  Let me try again:
>>>  I think there should be a standard way to fill in PAC data from
>>>  outside the KDC.
>>  I'm not sure if I'm not missing something but could you tell me why
>>  KDC should do that? If I'm not mistaken, the user can put into the
>>  AS-REQ message any authorization data she wants and the KDC just copy
>>  them to the ticket, am I right? If so, then the client can propagate
>>  to the ticket all authorization data she needs without any
>>  intervention of KDC. I think this is very useful solution in a world
>>  of multiple authorization mechanisms, which can use very different
>>  formats of representations of the authorization attributes. It also
>>  allows users to build authorization data according their current needs.
>Cool, I can assert "this user is god and should have full access to
>all services" into the PAC data and the KDC will just pass it along..
>Seriously, there needs to be an "Authorization Service" (AuthN) that
>sits along-side the "Authentication Service" (AuthZ).  I'm not saying
>whether or not these services are combined or separate, but the AuthZ
>service needs to be just as secure as the AuthN service.  You can't
>just ask the user to present the AuthZ data to the KDC to be signed.
>>  cheers,
>>  --
>  > Daniel

At 1:12 PM -0500 2/11/04, Derek Atkins wrote:
>Er, I did this backwards..
>   AuthN == Authentication
>   AuthZ == Authorization
>Sorry for the confusion.

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list