On 13-jun-2006, at 9:22, marcelo bagnulo braun wrote:
I think a better way to handle this would be to introduce an alternative security mechanism, such as in the form of regular X. 509 certificates that are already widely used for SSL today. (The fact that this allows people to get around HBA patent claims is a nice bonus.)
I am not sure i understand this...
how would the trust chain between the ULID and the locators would work? through the FQDN? how do we bind the fqdn to the identifier? is this in the certificate? do we need a global PKI?
Unless I'm mistaken, if you go to an HTTPS website, what happens is that your browser gets a certificate from the server that proves that the holder of the certificate has a certain identity, such as www.example.com. The browser checks whether the server has the private key for the certificate by sending it a challenge and checks if the identity in question matches the URL, which, I imagine, requires some DNS lookups.
shim6 security could work much the same way by tying a certificate to a ULID, either with or without the intermediate step of an FQDN. Such a certificate allows a host to prove that it holds a certain identity, irrespective of the address it's actually using. Once you know who you're talking with you can mostly believe them when they say what their locators are, you just need to send a packet to those locators to make sure the same host is present there to avoid the possibility of someone dumping shim6 traffic on an unrelated third party.
As for the PKI, yes, you need some kind of infrastructure, but it's already there so I don't see the problem, especially for enterprises and content hosters. Most home users don't have a certificate, but they can still use HBA. (Note that in the above scenario only one side (usually the server) needs a certificate.)