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

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Nov 2012 17:22:29 +0200

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.
-- 
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Nov 2012 17:39:39 +0000

Hi Tero,

Thanks for the comments.
Response In-line [Uma]:

====

-- [Snip]

[Uma]: Agree. I missed this part.

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.

[Uma]: As I indicated in the meeting we will change the text to reflect this.  

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.

[Uma]: Absolutely. We thought this and you mentioned this quite correct here. Thank you.