[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: alternative to user-to-user Kerberos in KINK
Mike,
DoS attacks are always possible - it is just a matter of degree. As I
described them in my previous email, I don't see those denial of service
attacks as serious.
A few roundtrips for a single connection is certainly no problem, when you
have 100,000 of them to a single server in a real-time application, it is a
real issue. The protocol will work either way, but I would not want to for
example downgrade the scalability of PacketCable architecture by using your
proposed approach.
Sasha.
> -----Original Message-----
> From: Michael Thomas [mailto:mat@xxxxxxxxx]
> Sent: Friday, November 03, 2000 12:24 PM
> To: Medvinsky, Sasha (SD-EX)
> Cc: 'Michael Thomas'; 'ietf-kink@xxxxxxxx'
> Subject: RE: alternative to user-to-user Kerberos in KINK
>
>
> Medvinsky, Sasha (SD-EX) writes:
> > 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.
>
> It would either eliminate or mitigate the need for U-U.
>
> The only other argument I see is the potential need for
> a server to get tickets for the clients in a failover
> situations, etc. IPsec keying is fundamentally a peer
> to peer protocol. In my opinion adding a mode
> which is vulnerable to DoS attacks (and worse,
> third party DoS attacks) to preserve a client
> server architecture is not a worthwhile
> tradeoff to save what amounts to disk space
> for a large ticket cache. Also: a server only
> needs to obtain tickets for clients if there
> does not exist an SA *and* it has a reason to
> talk to the client. Until then, the
> non-existence of the SA is not hurting much
> more than a possible extra round trip or two in
> exceptional conditions, assuming that the
> client does not key the SA itself.
>
> Mike
>
>
>
> >
> > 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, ...
> > > >
> > >
> >
>