[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: alternative to user-to-user Kerberos in KINK
This sounds like an excellent avenue to pursue.
jan
On Fri, 3 Nov 2000, Michael Thomas wrote:
>
> 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.
>
> Mike
>
> 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
> > following:
> >
> > A
> > B
> > ------
> > ------
> > 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
> > to.
> >
> > 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, ...
> >
>
--
Jan Vilhuber vilhuber@xxxxxxxxx
Cisco Systems, San Jose (408) 527-0847