> -----Original Message----- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Tuesday, July 05, 2016 8:44 AM > To: Valery Smyslov > Cc: David McGrew (mcgrew); IPsecME WG; Scott Fluhrer (sfluhrer); > p...@nohats.ca; Waltermire, David A. (Fed); Panos Kampanakis (pkampana) > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME > WG document > > [chair hat off] > > Valery Smyslov writes: > > I think it is a bit early to discuss particular approaches, before the > > WG makes a decision to adopt the document. > > Yes and no. > > It is too early to think about actual protocol decisions, but we need to know > whether current draft is suitable for protocol selections we are going to be > doing, and we need to think about what kind of compromizes we want to do. > > I.e., I think it is important to think even in this phase, whether we care > about > the identity hiding against passive attackers who can break Diffie-Hellman or > not. And do we care about identity protection against active attackers. If we > do want to protect against one of those kinds of attackers, our solutions are > going to be more complicated. > > If we do not care (i.e., keep the current level of protection in IKEv2 meaning > no identity protection against active attackers or attackers who can break > Diffie-Hellman) then our solutions are simplier. > > These requirements and compromizes are the important things we need to > decide on the WG before we can make decisions on the actual protocol > solutions. > > > Not necessary. In particular, the current draft allows to detect OOB > > key mismatch and to act gracefully in this situation. > > And I don't think it is far too complicated. > > Current draft does, but there has been other proposals which did not. > > The current draft is also very costly and allows very easy denial of service > attacks, as responder needs to linear search of all possible configured PPKs. > If > we for example use some kind of one time password system, where each > user has 1000 pre-distributed PPKs and we have 1000 users, responder > needs to do million operations every time someone sends him a packet or > same thing if we have million users configured and each have one PPK.
Actually, the current draft allows the responder to make a trade-off between identity protection and cost of lookup. In the exchange, the responder selects a "PPK Indicator Input" and the initiator responds with a value that's a function of the PPK and the PPK Indicator input that the responder selected. If the responder always selects a random PPK Indicator Input, you get identity hiding (at the cost of having the responder doing the search). If the responder always selects a fixed value, then the initiator's response is a fixed function of the PPK (and so the responder can precompute all the PPK's he knows about, and then do a simple lookup at negotiation time), you get a fast negotiation (at the cost of identity hiding). > Thats > why I do not like the current approach and I think trying to hide the identity > for the active attacker is just opening other attacks which are worse than the > attack where attactive attacker can learn the ID of the initiator... Actually, the identity weakness would be a passive attacker being able to deduce whether two negotiations used the same PPK (and if they did, they're likely from the same entity). > > Anyways I think we should work on this problem, and I think we do want to > think about the requirements for the solution we are going to do before we > can start writing actual protocol specification. And the protocol > specification > can be based on either one of the drafts, there is not that big difference in > them, and depending on the requirements things needs to be added or > removed from the drafts. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
