[karp] Comments to draft-chunduri-karp-kmp-router-fingerprints-01.txt

[Tero Kivinen <[e-mail]>]

In section 3.1 the draft says:

	   [RFC4301] supports X.509 certificate or pre-shared secret
   authentication data types.  So, it is necessary (and one more reason)
   to encode the raw public keys as X.509 certificates before sending
   the same in CERT payload.  

RFC4301 PAD does not forbid using other formats of authentication
than what is already there in the RFC4301. The RFC4301 lists the X.509
certificate and pre-shared secret as authentication information, but
also says (RFC4301 section 4.4.3.2):

   This document does not mandate support for any other authentication
   methods, although such methods MAY be employed.

I.e. it is completely possible to use just raw public keys, and store
the actual fingerprint of public key to the PAD and use that when
verifying the other ends authentication credentials. I would actually
assume all implementations supporting raw public keys does something
like that already.

I.e. the pad contains that other peer should authenticate himself
using the public key that has hash of xxxx, and when the peer connects
and identifies itself through ID payload and sends raw public key
inside the certificate payload, the implementation will calculate hash
of that public key and verify that it matches the one stored on the
PAD. If they match, then peer is authenticated.

BTW, to revoke the compromized key you simply need to remove the hash
from the PAD, which do require you to update the PAD of all possible
routers where this one router was talking to. Quite often those
configurations are already pushed to routers by some kind of
managament tool, so it is completly possibly to do this kind of things
quite easily.
-- 
[e-mail]