In section 2.2. it still says that ID presented MUST be ignored. I think this needs to be changed to SHOULD.
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. 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. 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. 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? 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. 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? 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. The section 2.3, I do not think there is ever reason to do liveness check for all other IKE SAs using null authentication. There is already normal inactivity based liveness checks, so that will take care of the SAs already, there is nothing we need to do when we receive INITIAL_CONTACT for some other IP address. What we can do that if we do receive INITIAL_CONTACT from same IP-address we already have IKE SA, we could do liveness check for that SA, as that is the most common case. 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. Also if the device sent some other ID than ID_NULL, we could again do liveness check for those IKE SAs which have same ID than the new connection coming in, but of course you would want to rate limit those just in case someone makes implementation where everybody uses "[email protected]" or similar as their ID, so everybody has exactly same ID (doing that would be stupid, but that has never stopped people to do things). 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). In security considerations section there is text: Un-authenticated IKE sessions MUST only attempted when authenticated IKE sessions are not possible for the remote host and the only alternative would be to send plaintext. I assume that s/MUST only attempted/MUST only be attempted/ but also I do not think we cannot use un-authenticated IKE session even when there was 3rot13 method to "encrypt" the packet. In your text we cannot replace 3rot13 method with Un-authenticated IKE sessions as it is not plaintext (you can also replace 3rot13 with other weak cipher for example 40-bit RC4, or single DES). Also limiting un-authenticated IKE sessions this way really restricts the use cases for this. I would rather says that "If authenticated IKE sessions are possible between the hosts, then un-authenticated IKE MUST NOT be used". But even that will restrict some use cases. For example some forum site might want to restrict posting of new comments to authenticated users, but would still want to allow reading of entries without doing authentication. In such cases the client can be configured to be able to do both. In normal case the user will always do un-authenticated connection to read entries, and when he decides to post a reply or new comment, the software would automatically create new authenticated IKE SA and do the actual post through that, even when still at the same time keep the un-authenticated connection for reading... Btw, in such cases the connections might use per TCP-flow Child SAs... You repeat the ID processing rules in the security section, but the MUST is different, as here you do have the logging exception (which you did not have in section 2.2). But there might also be other uses in addition to the logging for the ID, for example the INITIAL_CONTACT notification matching, i.e. which peers to check for liveness when INITIAL_CONTACT is received. You also claim that using ID type other than ID_NULL will compromise the clients anonymity. I do not agree on this statement. Using pseudonyms, or completely random ID for each connection will not compromise anonymity, but will allow certain use cases. In some cases there might be reasons to allow matching old and new sessions to same client (for example INITIAL_CONTACT) but even that does not compromise the anonymity. Even if you know that same ID is used, and it might be same user than last time, that does not mean that you know who the user is. Section 3.1 asks for implemntations to "audit implementations for any assumptions". I think better wording is needed, I do not want to provide our customers a audit records for this kind of things (and I know some of our customers would be reading this text in such way that we must provide those audit records). Perhaps the text should say that implemenations should verify that their assumptions are still valid or something like that. Or just warn implementors that their assumptions might not be valid anymore... In section 3.3 you only say that un-authenticated IKE peers MUST NOT be able to replace the IPsec SAs of an authenticated IKE peer, but not that authenticated IKE peer cannot steal un-authenticated, i.e. replace them IPsec SAs. Is this intentional? I.e why would there ever be use case where any two different users should be allowed to steal other users IPsec SAs (i.e. replace / overwrite them)? I would assume that if user1 has Child SA, then user2 should not be able to create Child SA that steals user1's traffic. I think this should be true even if user1 is authenticated and user2 is not, or vice versa. It should also be true even if both user1 and user2 are un-authenticated (i.e. all un-authenticated users are by definition different users). There are use cases where user1 wants to replace Child SAs created by same user1, i.e. when you reconnect after crash, or you have multiple devices using same resource (i.e. moving video stream from your mobile phone to your laptop by just connecting from your laptop and creating new Child SA with same traffic selectors and disconnecting your mobile phone, so all traffic will now go to the laptop (which have requested same internal address associated with the user from the server). So I would think the section 3.3 should be formatted better. Section 3.4 should most likely also mention RFC5739 as it allows assigning full /64 address block to client, and with that you might use wider traffic selectors. I think we need separate section for the traffic selectors. Now some of that is in the section 3.3 (not replacing IPsec SA), and some are in 3.4. The title of "Network topology changes" does not really describe the problem with traffic selectors. Moving all text related to it to separate subsection might make things easier. Also what error is used when client tries to use traffic selectors which are already in use, or which are not allowed for it (i.e. trying to steal 8.8.8.8)? For stealing attempts the TS_UNACCEPTABLE would be correct, as servers policy should not allow such traffic selectors. Or SINGLE_PAIR_REQUIRED is also possible if there is no trigger packet information. If you try to reuse traffic selectors in use, I think the TS_UNACCEPTABLE is ok for that too, as this could also be considered similar policy error as described in the rfc7296: o If the responder's policy does not allow it to accept any part of the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE Notify message. Note, that we do want to put policy blocks for all addresses given to the client, not only those which are in use now. I.e. if IP A and B are given to client, both of them should be blocked from everybody else even if only one of them is in use. Same thing with prefix given by RFC5739. In general I think we still need more work on this draft, especially in the security considerations section, and actually moving some text away from there to the actual body would be good. I.e. adding new section between 2.2 and 2.3 about the traffic selectors, and moving discussion about the traffic selectors and what kind of policy checks to do for those, and what kind of use cases there might be is needed, and the security considerations section should have more about the attacks, and their counter measures. I.e. the first section would say that server could be configured to only allow IP-IP transport mode connection, or always give client a address using configuration mode, and limit client end to it (or to /64 given by RFC5739), and also perhaps talk about per flow SAs etc. The second part should talk about the address stealing and policy checks on traffic selectors. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
