alternative to user-to-user Kerberos in KINK

[Michael Thomas <mat@xxxxxxxxx>]

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