Paul Wouters writes: > On Mon, 19 Jan 2015, Tero Kivinen wrote: > > There are valid cases where we would like to use the ID, for example > > we might want to assign the same ID same IP-address every time, just > > to make things easier. > > Of course that's just a band-aid for the ill advised idea of handing out > IP addresses to strangers :)
Assigning IP address to clients makes things easier, especially if the client is behind NAT. If client is behind NAT it will have non-routeable, perhaps overlapping addresses, thus using the real client address is hard, and the server will most likely need to do internal NAT for the address (specific to each Child SA) before it is given to the IP stack of the server. Giving address to the client makes things bit easier, as this is standard, widely used method of doing this, and then server can use this address it allocated from its own address pool without any problems, as it can ensure that there are no overlaps, and those addresses in the address pool are so that they will be routed properly. > > This does not mean we trust the ID in any way, > > it would be used just in same way as DHCP client id is used, it is > > just conveniency feature, not security feature. > > > > Another use case for it is to audit it in the logs, or show it to > > adminstrators. > > If we say SHOULD, that would conflict with your use cases. I don't want > to give advise in a document only to have common practise ignore that > advise. If your use cases are valid then we should address it > differently. Yes, MAY is another possibility, but I think actually SHOULD is good compromize. Not everybody wants to use ID for anything, and if you really do unauthenticated, and anonymous connections only, there is no point of using ID. If you do unauthenticated, but not necessarily anonymous (in a sense that clients can claim to be same person than before, or give their identification information, even when they cannot proof it) then using ID has valid points. I myself claim that there are use cases where clients might have valid use cases for giving some kind of ID, even when they do not authenticate the ID. > It seems to be that what you want is something that is neither ID_NONE > nor any of the currently defined ID types. Perhaps a new ID Type should > be introduced for your use cases? ID_SESSION ? No. I do not want that. I want to use currently defined IDs. For example I might configure my client to use ID of [email protected] when I am connecting to the forum, even when I do not authenticate that ID anyway to the server. I myself usually do not try to be anonymous, but I do see value of having encryption, even when it would be unauthenticated. The forum adminstrator might then log that information, and might even contact me using that completely untrusted information, just because it happens to be there. This is similar to many other information I give to those stupid registration pages, some of those are true, quite often they are just "none", "none", etc as I see no reason to give some information to them just because they ask them. I do usually give my real name, and quite often also real email address... I understand that not everybody want to do that, and I agree that there are some uses cases where you do not want to give any identity information, but I do want this document to remove possibility for giving that information... > > I.e. in some environments the users do not have reason to lie for > > their ID, but they still might not want to do authentication. Yes > > attacker can fake the ID, and there is nothing we can do for it, but > > when the user contacts the admin and wants to complain something, it > > much easier if he can say that I use ID [email protected], and then > > admin can check out the logs or mangement information for that ID. > > Honestly, in those use cases asking them for whatsmyipaddress.com is > going to accomplish the same (or "show IP" if on a LAN) Not really, as the IP-addresses used changes quite often. Especially on mobile devices roaming around the world... Yes, my home-ip happens to be stable, but my laptop IP isn't, so I have no idea what IP I used last week on my laptop when in IEEE meeting, or in the hotel room. If the issue happens just now, then show IP might work, if it happened last week that does not help. The configured ID will help. > > Also how are you going to validate that the server actually follows > > that MUST? How do you verify form outside that the implementation > > actually ignores the ID field? > > Is there a rule that says you cannot say MUST if you cannot confirm > compliance? No, but when you receive customer request to provide you the line numbers in your source where you ignore that ID, then it gets fun. We did get customer asking us where we implement "MUST NOT send certain packets", i.e. what are the exact code lines where we do that "MUST NOT"... (or something like that). I think we responded that all of the lines in our source code implement that, as none of the lines send those packets :-) Also of course we should be able to provide matrix that we have two independent implementations do implement that MUST... > > I would recommend changing that text to either say that SHOULD, or to > > change it to say where it it is ignored, i.e "MUST be ignored for > > trust and policy checking", or something similar. > > Works for me. If I can also add a "SHOULD NOT be sent when anonimity is > a concern". That works. > > On the other hand same section says that ID_NULL SHOULD only be used > > with NULL authentication method. In which scenarios do you think > > ID_NULL can be used when using normal authentication? I.e. which is > > the exception for the SHOULD? > > I'm thinking this was mostly an editing mistake. We did want to give you > your logging Id option. I think perhaps we changed the wrong MUST to > SHOULD. Ok. > > One such case might be when using Raw public key authentication, i.e. > > in which case the ID is not really in the ID payload, but the public > > key is the identity instead. If this is the reason why you say SHOULD, > > then we should mention it here. > > I had not thought about that, but it is a good point. Will do. Ok. > > I.e. device creates anonymous IKE SA with server, then device is > > restarted, and it creates new IKE SA and now it will send > > INITIAL_CONTACT as it does not have any SAs with server. Most likely > > those connections have same IP-address, thus to clean up state, it is > > enough to just do liveness check for old IKE SA from the same > > IP-address. We cannot just remove it as the IP-address might be the > > address of the NAT box. > > I'd say just always do that check, and ignore INITIAL_CONTACT. Thats fine. Initial contact is not that important in IKEv2 anymore, as we do have other ways of cleaning up state. > > Also if the device sent some other ID than ID_NULL, we could > > Please don't make any decisions based on IDs of unauthenticated IKE SA's. > You keep saying "only for logging" and keep trying to be smart and > use it for other things.. Keep it simple, "nothing but logging of the > ID". That's my compromise :) I was not saying only for logging. I was saying there are uses for it, and one of those uses is for example logging. There are other uses for it, and matching pervious connections is one of them. That is not trust or policy decision, it is just decision whether to do liveness check or not for some specific IKE SA, and that will be something that will help the server to handle its resources... Again we are talking about unauthenticated connections, not necessarily anonymous connections. > > Btw, this INITIAL_CONTACT cleanup might be one reason why people might > > have good reasons to use unique valid IDs (perhaps random KEY_ID > > created when software is installed, or once per week or something like > > that). > > unfortunately, the nice user that causes a few lingering SA's is not a > problem at all. It's a few bytes in the kernel and IKE daemon. It's > the malicious clients that matter, and they can tweak using or not > using INITIAL_CONTACT and unverifiable IDs. So in my opinion, this > adds complexity and optimises only for the case that does not need > optimising and fails to be useful for the actual malicious case. It does not really add complexity as the code is already there. That is what is done for normal authenticated initial contacts. The only thing we want to do there is not to delete it immediately, but instead trigger liveness check instead. Also most of the time you are NOT under attack, so maintaining resources during that time is also nice... Telechat in 2 minutes, need to stop now... I'll be back... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
