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

Re: Bellovin's and Ahar's attacks

Ted,

I have not responded immediately to your message, since I knew a proper reply
would take some time and I needed to get some other things done. However,
I think I can now respond to your question. Specifically, you suggest :
 
>  To prevent the UDP attack of another user binding to the same UDP socket
>  and playing back the exact same packet, we'd also need per-user keying.

And then you ask :

>  But it seems to me that protecting against these attacks is doable.
>  What am I missing?
>  

My concern with per-user keying has stemmed from my inability to see how it
will work in practice. Let me take more than the usual space to suggest where
I see problems.

Consider the admind daemon that is used in Solaris for system administration.
This is the server that answers admintool requests. It is used for many
purposes, but the one of interest in this discussion is managing user accounts.
Specifically, you can install new users or modify their account information,
including their passwords. While not true now, I think we can agree that
when modifying a password entry in a table or database, the hashed passwd should
not be transmitted in the clear. Doing so allows an intruder to execute
a dictionary attack by simply sniffing the admind traffic. Consequently, there
is at least one requirement that admind support encrypted traffic.

Since IPSP supports encryption, it would be advantageous to use its services
in support of admind. However, admind is fired up by inetd. So, it is inetd
that listens waiting for requests. inetd registers admind's RPC program number
with rpcbind, and services admintool requests.  When one arrives, it
forks admind to handle it. There is also a provision for keeping up admind
for a few minutes after a request for better efficiency. Finally, admind uses
UDP.

So, how can admind use IP encryption services? Here are a few questions that
have been bothering me :

 o  How is inetd contacted by the key management software? Normally, inetd
    is sitting in a select call, waiting for activity on one of its file
    descriptors. Does there have to be a fd for communications with the
    key management software? If so, assuming that admind isn't the only
    inetd forked app that wants to use encryption, how does the key
    management software communicate with inetd and tell it which fd to
    "instrument" with a user's key?

 o  How does the key management software know whether admind is already
    running? Of course, it can do a ps and look for its name, but how
    will it know what name to look for and how can it be sure that between
    the time it gets and processes the ps information, admind isn't started
    by inetd? How will admind be programmed so that it can talk with the
    key management software in the same way that inetd does? Recall that
    one reason for inetd is to simplify the daemons it forks.

 o  Good cryptographic practice requires periodically changing keys
    based on how long they have been in existence as well as how much
    data they have encrypted. How will the key management software acquire
    these statistics? If it needs to expire a key that is currently
    "attached to" a port, how will the process that owns the port
    be contacted and instructed to exchange the key for another? How will
    the key management software know which processes to contact (after all,
    more than one process could be using a per-user key)?

 o  What system chooses the user whose key will be used? There are two cases.
    If the client is the one that wants encrypted traffic, it will initiate
    the key management exchange. What user does it select? If it uses the
    uid of the process (limiting ourselves to Unix systems for the moment),
    how is that mapped into a user-identifier that the destination understands?
    If the server is the one requiring encrypted traffic, it will initiate
    the key management exchange. What user identifier will it use to
    identify the per-user key?

This is just the beginning. I am fairly confident that once answers to these
questions are developed, they will generate other questions. I really feel
nervous about standardizing something that has no publically available worked
example. Ran has promised to provide us with code that does per-user keying.
Hopefully, this will happen fairly soon so that confidence can be built that
this objective is achievable.

Dan