Hi Paul,
I regularly use SSH, which binds a public key fingerprint to a DNS name.
It's usable, and not too complicated.
We can argue why BTNS failed but I don't want to waste our time on that.
I believe some limited form of channel binding can work. Specifically, I
am thinking of post facto authentication, e.g. by reading out the
fingerprint on the phone.
Regarding audit, we can mandate that each record should say something
like "Snow White (claimed but unauthenticated identity)".
Thanks,
Yaron
On 01/11/2014 07:45 PM, Paul Wouters wrote:
On Fri, 10 Jan 2014, Valery Smyslov wrote:
1) Use of IDs
I don't think we should allow any IDs, as there could be conflicts with
other non-anonymous connections. Or possibly a way to detect which
non-anonymous IDs are accepted at the remote. I was leaning towards
mandating the ID to be "anonymous" to make it extremely clear that this
is an anonymous connection.
I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special "anonymous" ID here seems to be superfluous.
Than you should stick to that and not send any IDs whatsoever.
to make errors in code. Second, as Yaron pointed out, IDs
may still be useful for upper level and sometimes even
could be verified via out-of-band means.
I am strongly against channel bindings, connection latching, or connection
reconfiguration-promotions. Nice good complicated ideas, but they have
failed with BTNS already. If you want access to a non-anonymously shared
resource, setup a proper authenticated IPsec connection.
So, I think that it's better to follow Occam's razor principle here
and not to add new ID type, as all that it could tell to the peer
is already told by using NULL Auth method.
Ocam's razor would tell you not to send IDs if you don't plan to use
them or have the other end use them.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
