use of authorization-data

[Sam Hartman]

>>>>> "Frank" == Frank Balluffi <frank.balluffi at db.com> writes:

    Frank> I see that it is possible to put application-defined data
    Frank> in the enc-authorization-data field of a request to a TGS
    Frank> and the authorization-data field of a ticket. Suppose I
    Frank> have a password-based application service that would be
    Frank> difficult to Kerberize, I have two questions: 1. In theory,
    Frank> is it possible to embed a user ID and password into a
    Frank> ticket and send it to a Kerberized proxy that logs the user
    Frank> into the password-based application service on behalf of
    Frank> the user?

Yes, but why bother?  The client needs the password and ID as well as
the Kerberos principal and key.  Why not just not Kerberize the
application or use an SSL proxy or something.  What do you get by
sticking this information in the ticket other than potentially
exposing it to other services if you are not very careful?

    Frank> 2. In practice, are there any gotchas? For example, would
    Frank> one need to modify kinit? Does the MIT TGS support this?

One issue is that if you are using a Microsoft KDC with RC4 tickets,
you may run into an issue as microsoft has changed one of the key
usage numbers between Windows 2000 and .net server.

Another issue is that  if you put the password in the TGT then any application service getting tickets based off that TGT can read the password.

I just don't see the point of putting this information in the ticket
rather than in the protocol between the client and the proxy.

Yes, you would have to modify kinit to make this work.