[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: alternative to user-to-user Kerberos in KINK
Mike,
As per my previous email, I listed what I consider to be problems associated
with a server obtaining tickets for a large number of its clients. While I
would support a change to PKINIT that allows automatic generation of client
keys that are saved in the KDC database, I don't believe that it addresses
this issue.
Sasha.
> -----Original Message-----
> From: Michael Thomas [mailto:mat@xxxxxxxxx]
> Sent: Friday, November 03, 2000 11:45 AM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'ietf-kink@xxxxxxxx'
> Subject: 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.
>
> 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, ...
> >
>