[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: alternative to user-to-user Kerberos in KINK



Medvinsky, Sasha (SD-EX) writes:
 > 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.

   I would say that any scenario which explicitly allows for
   a third party DoS attack against a KDC is pretty suspect.
   With the wakeup method you propose, the attacker merely
   spoofs the address of the peer and attaches an appropriate
   number of bits to resemble a ticket. Computationally, this
   is trivial. However, the receiver would then have to
   create an TGS-REQ with the two tickets and send the 
   request to the KDC. This is computationally expensive.
   The KDC would then have to decrypt the request and
   act on it which is computationally expensive.

   In the U-U scenario, the burden of creating the
   TGS-REQ lies on the attacker. The GetTGT
   response is not authenticated so it costs the
   receiver little. The cost at the KDC is the
   same. However, there is little profit in
   involving the U-U peer if the attacker doesn't already
   have a legitimate TGT: the attacker could just
   as easily have spoofed the entire U-U TGS-REQ
   to cause a direct DoS attack on the KDC. Also: the
   attack originates from its _source_ rather than
   an uninterested third party as in above.

   Thus the CPU burden scorecard is:

            U-U   Wakeup
attacker    low   low
peer        low   high
kdc         high  high

   And this does not take into account the harm
   of an attacker with a legitimate TGT flooding
   the ticket cache of a peer which is also not
   a problem with the U-U approach.

 > 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.

   There are other ways to deal with this which 
   don't need to involve the protocol itself. 
   I don't favor building in a zombie attack into
   the protocol when other options are viable.

		Mike

 > 
 > 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, ...
 > >  > >  > 
 > >  > > 
 > >  > 
 > > 
 >