14 May 2012 07:38
Feedback on RFC 4423
Ganesh and Sashi Prasad <g.c.prasad <at> gmail.com>
2012-05-14 05:38:19 GMT
2012-05-14 05:38:19 GMT
Hi,
I'm writing to express my appreciation for the wonderful work you have done in explaining the need for a conceptual layer (HIP) to decouple the issues of host identity and host location. I'm also writing to warn of another potential source of coupling in the RFC 4423 proposal.
From my own experience implementing Identity and Access Management systems (http://bit.ly/FR6REH), I have come to realise that identifiers and identity credentials are two different concepts, and that conflating the two can lead to problems. To be fair, you too have recognised that the two are different, but you are still proposing that verifiable credentials be used in place of plain identifiers for reasons of security.
"In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As will be specified in the Host Identity Protocol specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks."
While I agree that a secure implementation of HIP is non-negotiable, we need to conceptually separate the host identifier from the mechanisms we use to reliably assert it. I would argue that a public key is only one of potentially several mechanisms that could be used, and we should not enshrine one such mechanism in the HIP protocol to the exclusion of others. Signed SAML2 assertions may be another valid way to assert identity in an untrusted environment. Within a trusted environment, the raw and meaning-free identifier may be used by itself without impact. I am a big fan of random UUIDs as meaning-free identifiers in a wide variety of contexts, and I would be happy to see a bit more design into this crucial aspect of your excellent proposal.
Thanks and regards,
Ganesh
I'm writing to express my appreciation for the wonderful work you have done in explaining the need for a conceptual layer (HIP) to decouple the issues of host identity and host location. I'm also writing to warn of another potential source of coupling in the RFC 4423 proposal.
From my own experience implementing Identity and Access Management systems (http://bit.ly/FR6REH), I have come to realise that identifiers and identity credentials are two different concepts, and that conflating the two can lead to problems. To be fair, you too have recognised that the two are different, but you are still proposing that verifiable credentials be used in place of plain identifiers for reasons of security.
"In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. However, in the authors' opinion, a public key of a 'public key pair' makes the best Host Identifier. As will be specified in the Host Identity Protocol specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks."
While I agree that a secure implementation of HIP is non-negotiable, we need to conceptually separate the host identifier from the mechanisms we use to reliably assert it. I would argue that a public key is only one of potentially several mechanisms that could be used, and we should not enshrine one such mechanism in the HIP protocol to the exclusion of others. Signed SAML2 assertions may be another valid way to assert identity in an untrusted environment. Within a trusted environment, the raw and meaning-free identifier may be used by itself without impact. I am a big fan of random UUIDs as meaning-free identifiers in a wide variety of contexts, and I would be happy to see a bit more design into this crucial aspect of your excellent proposal.
Thanks and regards,
Ganesh
_______________________________________________ Hipsec mailing list Hipsec <at> ietf.org https://www.ietf.org/mailman/listinfo/hipsec
RSS Feed