[chord] new auth type patch

[Michael Walfish]

Hello,

This patches against the latest version of the CVS repository as seen by
Chord developers (not as seen by anoncvs users). (BTW, the difference
between the two is why I didn't see Benjie's fix despite having checked
the anonymous repository moments before e-mailing the list. So sorry for
the spam, and thank you Benjie for helping me out!)

Anyway, the attached will implement a new authentication type, as
described in my previous mail. The changes are:

o the addition of a new type called DHASH_KEYNONCEHASH
   -- in this type, ChordID = hash(pubkey, nonce); the user selects 
      the 32-byte nonce arbitrarily
   -- the signature that goes in the backing store is taken over a 
      concatenation of the actual payload and the nonce. this binds the
      nonce to the payload and prevents an adversary from doing replay
      attacks

o testing code in devel/test_types.C of the same flavor as the existing 
code
   -- I took the liberty of adding an extra test, namely a query on a 
      block that doesn't exist

o exposing, through the dhashclient interface, the ability to add NOAUTH 
  blocks. I've been testing the NOAUTH code path, and it seems fine. I can
  understand if you don't want to handle NOAUTH blocks, but then the 
  server should reject them too. If there is still a code path for the
  server to store them, then I'm hoping it's not a problem to explicitly 
  present the interface to clients. If it is a problem, please let me know, 
  and I'll simply maintain a separate patch

o the only semi-substantive implementation changes are:
  
  a) the addition of a keynonce_db meant that there had to be two key_mgr
  timers. so rather than write all the existing code again, it seemed
  better to factor out most of the code and ship around state (like which
  type of callback, DHASH_KEYNONCEHASH or DHASH_KEYHASH, is taking place)
   [Note: it seemed at first blush like having this new auth type in the
   same database as the DHASH_KEYHASH blocks would make sense. The problem
   is that the key_mgr iterates over its database, pulling out blocks, and
   since the blocks are no longer self-documenting, it is difficult to tell
   which block type one is dealing with without separating them.  The
   semantics are basically: a database is associated with a verification
   method, which is a bit hoopty, I agree, but I didn't see a way around
   that without making bigger changes, like storing the block type inside
   the DB.]

  b) the dhash_impl::store() functionality is almost exactly the same for
  the new auth type and the existing DHASH_KEYHASH, so it made sense to
  factor that code out. Benjie's recent additions use almost exactly the
  same code, too, so I applied the factoring to his additions as well.


To apply the patch, cd into the sfsnet directory and do:
    % patch -Np1 < patch-name

(Or if you'd prefer that I directly commit the changes, please let me
know.)

Questions? Comments? Public beheadings?

-Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nonce_auth_type.patch.gz
Type: application/x-gzip
Size: 10227 bytes
Desc: 
Url : https://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20030722/ea225510/nonce_auth_type.patch-0001.bin