On Jun 4, 2014, at 11:03 PM, Michael Richardson <[email protected]> wrote:
> > Paul Wouters <[email protected]> wrote: >>> Valery Smyslov <[email protected]> wrote: >> Paul ps. i also still >>> prefer AUTH_NONE over "NULL AUTH", as to me NULL >> looks more like an >>> error while "none" conveys intent. >>> >>>> I remember it. However I'm still waiting for other's opinions on >>> this. > Naming is not a problem. >>> >>> I prefer AUTH_NONE over "NULL AUTH". Still, that doesn't convey >>> enough intent; AUTH_DIDNTWANTTO, or something like that might say it >>> better, but that's a mouthful, so I can live with AUTH_NONE if we >>> can't do better. > >> AUTH_ANON ? Although I think AUTH_NONE is more in line with how we name >> things. > > I don't agree that it is anonymous. It says that the identity was not > authenticated, it didn't say that no identity was provided. Section 2.2 says that “As peer identity is meaningless in this case, Identification Data SHOULD be omited from ID Payload”([1]), and even if sent, it MUST be ignored by IKE. So it’s really not provided. > Clearly: the identity can't be trusted and can't be used in anyway. > So, given that, how does one look up acceptable TSx in the PAD? That’s a good question. What prevents a random attacker from sending a TSr covering IP address 8.8.8.8, and getting a whole bunch of DNS queries. That’s easier than bugging the ISP or break the wifi password. > I think that the opportunistic encryption use case given can not make any > sense without reference to the PAD. I think that’s the hard part of any opportunistic IPsec. It’s not always better than nothing, because you might be making it easier for Eve. Yoav [1] sic - “omitted” should have two t's _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
