[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
alternative to user-to-user Kerberos in KINK
After talking to Matt Hur about this and thinking
about this for a long time, I think the better
part of valor here may, in fact, be avoidance.
Taking a giant step backward, the root of all of
the trouble here is that KINK is, in fact, a peer
to peer protocol where PKinit expects a client
server relationship. The main problem is that
PKinit authenticated clients do not share a
symmetric key at the KDC so the KDC cannot issue a
service ticket directly thus bringing on the
issues related to user-user mode. If the PKinit
client did share a key with the KDC, the KINK peer
would just obtain a normal service ticket and that
would be that.
Therefore, I think that I agree with Matt's
contention that a much better strategy for use of
PKinit would be to use PKinit as an enrollment
strategy into a kerberos realm rather than an
authentication strategy, per se. Ie, a client
authenticates to the KDC using a cert but the KDC
then enrolls it with a symmetric key and saves
that key in its principal database. I haven't
looked at this exhaustively, but I think that this
strategy could be implemented using either no or
minimal changes to PKinit -- the obvious thing to
do is use the session key from the TGT from the
PKinit AS-REQ as the symmetric key.
My proposal is that we deal with this problem as a
PKinit issue rather than a KINK issue because this
is a generic problem with PKinit -- KINK is just
the first to stumble upon the implications of
using PKinit in a peer to peer application. The
advantage here is that we could avoid *all*
unauthenticated requests which from a DoS
standpoint seems like a much better idea.
Medvinsky, Sasha (SD-EX) writes:
> The user-to-user Kerberos mode in KINK is intended to address the situation
> with PKINIT clients that do not have symmetric client keys registered with
> the KDC and therefore a Kerberized server cannot get a standard ticket for
> such a client. But the server still has to obtain user-to-user tickets for
> clients, which brings up the following issues:
> 1) Under some architecures, such as VoIP, fast failover time from a
> primary to a backup application server is critical. With the current
> protocol, the backup server would have to go to the KDC and get user-to-user
> tickets for all of the clients with which it needs to establish IPSec SAs.
> This adds to the recovery time and adds additional performance/reliability
> requirements to the KDC. The number of clients per server can be large -
> 100,000 clients / Call Server is possible in the PacketCable architecture.
> It is possible for the server to save user-to-user tickets and
> corresponding session keys into some shared database, which is undesirable
> in terms of complexity as well as security.
> 2) Load balancing between multiple Call Servers is sometimes used in
> the VoIP architecture - support for it is mandatory in the PacketCable
> standard. The user-to-user tickets again either add to the rekeying time
> (which delays the switch-over time for a client between servers) or adds the
> complication of a shared database of user-to-user tickets.
> 3) A standard Kerberized server that doesn't support the
> user-to-user tickets is a lot simpler to implement. It would implement a
> very small percentage of the Kerberos protocol - just the AP Req/AP
> Rep/KRB-ERROR messages. With the user-to-user mode, the server needs the
> complete Kerberos client implementation and in addition may need to support
> a very large ticket cache for user-to-user tickets.
> 4) Setting per-user policy is awkward for user-to-user requests.
> Normally, the user policy is associated with the client, but in this case
> the client is the server. Kerberos allows a user to pass authorization data
> in a TGS Request (which may be insecure, depending on the content of that
> authorization data), which would not be possible if it is the server getting
> a ticket for the client.
> 5) Setting per-user policy in a cross-realm case is even more
> awkward. The server's GetTGT request would most likely contain the server's
> realm name (as the server may not know the client's realm). This means that
> the response to the GetTGT will contain a cross-realm TGT for the client.
> So, the server's KDC will wind up issuing a server a user-to-user ticket for
> a client principal that is not even in that KDC's realm.
> There are alternative methods for handling PKINIT clients that address most
> of the above issues. What I propose, is the following modification to the
> protocol. The GetTGT message flow in section 4.2 can be replaced with the
> 1 AuthenticateRequest+ServerPrincipalName--------------->
> 2 <------------------------------------AuthenticateReply+AP_REQ
> 3 CREATE+ISAKMP (keyed cksum with sess key)-------->
> 4 <------------REPLY+ISAKMP(keyed cksum with sess key)
> In the above flows, there needs to be a way to tie flows 2 and 3 together -
> for example the client timestamp inside AP_REQ can be repeated in flow 3.
> In addition, there is already an XID in the header for this key management
> session. (It is also possible to include the AP_REP in flow 3.)
> In the above flows, the AuthenticateRequest is not authenticated, just like
> the GetTGT message. There is the denial of service argument against the
> above flow since anyone can send the AuthenticateRequest. If C impersonates
> A and sends the AuthenticateRequest, B will have to reply, but A will reject
> the reply because the XID (session ID in the header) will not match anything
> that A sent out. The denial of service arguments are:
> a) denial of service on the KDC - B may need to get a ticket for A
> if it doesn't have it already. But, even if KDC receives an invalid
> TGS_REQ, it still has to decrypt it to see that it is invalid. I don't
> think that the extra work of issuing a ticket is a major problem. Also,
> clients should cache the tickets, and the number of servers in the KDC
> database is probably not that big. Also, the clients should excersize
> access control and know ahead of time which servers they should be talking
> b) denial of service on the clients - this is similar to (a), except
> that the client's ticket cache is filled up. This is really the same case
> as (a), because when the client's ticket cache is filled up it can remove
> one of the entries. It just means that if the client gets a request that
> needs the removed ticket, the client will request it from the KDC again.
> Also, with the current KINK protocol, similar denial of service attacks are
> possible. In that protocol, the GetTGT message only specifies the realm.
> If the server doesn't know the client's name, it might get the wrong client
> TGT and get a user-to-user ticket for a wrong client. If the server then
> finds out that the resulting user-to-user ticket is not accepted by the
> legitimate client, it will probably retry with another GetTGT message that
> could also result in a wrong TGT (inserted by an adversary) and then a wrong
> user-to-user ticket, ...