Hi Paul,
Quoting from the abstract: "This method may be used to preserve
anonymity or in situations, where no trust relationship exists between
the parties." You seem to assume that all clients want to be anonymous.
IMHO "unauthenticated" does not necessarily imply "anonymous". When I
talk to someone on the plane and they tell me their name, they are not
authenticated and they may well be lying. But in general, they are not
anonymous either.
Thanks,
Yaron
On 03/04/2014 12:57 AM, Paul Wouters wrote:
On Mon, 3 Mar 2014, Tero Kivinen wrote:
It would be better to say that if you are sending empty ID payload,
you msut use ID_KEY_ID type which already allows any data, including
empty.
That could work, if we really don't want to allow this document to
change the ID payload from mandatory to optional (which I would prefer)
Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
ignored", and I think that is again bad idea. I think logging and
auditing the ID for problem solving purposes is good idea even if it
does not have any meaning for the authentication. I.e. at least then I
can contact helpdesk and say that my NULL authentication connection to
server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
from your logs...
I disagree strongly. The point here is that the client is anonymous. We
should not add things that can be traced to a user. Someone will badly
abuse this "feature" like you are suggesting for "diagnostics" and
inadvertly compromise the client's anonimity.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
