Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey
Support this draft to go on to IETF review. I have read this draft and feel that it is useful to let IKEv2 support more types of raw public keys, such as ECC. The certificate encoding has used a new format and obsoleted the old RSA public key format "11". And if such an old encoding is received, it MUST NOT be considered as a fatal error. One typo found: at the last sentence in Sec 3. "needs to followed" should be "needs to be followed". BR Yang == Yang Cui, Ph.D. Huawei Technologies cuiy...@huawei.com > -邮件原件- > 发件人: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 代表 Yaron > Sheffer > 发送时间: 2013年4月22日 15:29 > 收件人: Paul Hoffman; IPsecme WG > 主题: Re: [IPsec] STRONG NUDGE: WG Last Call on > draft-ietf-ipsecme-oob-pubkey > > We have still not heard any additional responses for this last call. If > you think this draft is useful, please say so on the list. If you think > it needs to be fixed, please send your comments. > > We are extending this LC until Friday of this week. > > Thanks, > Yaron > > On 2013-04-17 18:18, Paul Hoffman wrote: > > We have gotten exactly one response to this, even though there were lots of > people who said they thought this was a valuable addition to IKEv2. Please > comment before Monday so we don't have to abandon the work. > > > > --Paul Hoffman > > > > On Apr 8, 2013, at 2:43 PM, Paul Hoffman wrote: > > > >> Greetings again. This begins the WG Last Call on > draft-ietf-ipsecme-oob-pubkey, "More Raw Public Keys for IKEv2". You can find > the current draft at http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey > >> > >> This document generated a fair amount of interest early, but we have not > had much discussion since. Yaron and I would *really* like to have at least > five > WG members review the document and say on the list whether or not they > think it is ready in its current state to move to IETF review. If you read it > and > feel it is not ready for any reason, please also say that in your message to > the > list. > >> > >> Again, participating in WG Last Calls is a great opportunity for those who > are less active in the WG but who want to contribute to the IETF to make a > difference. > >> > >> The WG Last Call should end in two weeks, on April 22. Please review the > document before then. Thanks in advance! > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02
I am afraid that only multi-paths cannot enhance the security. As Tero commented, if one can decrypt one path, then it is a successful security breach already. I think the point is that what is the definition of "insecure network", and the definition of the "security" here. From a cryptographic point of view, it may be helpful to enhance the protocol in this way. Such as, encode the original flow into pieces, with an All-or-Nothing-Transform (AONT), which does NOT require a secret key and has a property that it is hard to invert unless all of the output is known. (OAEP is an example, in the random oracle model) Then, encapsulate the encoded flow into multi-path IPsec tunnels as proposed. This time, the security will be definitely enhanced since the attacker will not get anything unless it breaks confidentiality of all sub-tunnels. 发件人: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] 代表 Tero Kivinen [kivi...@iki.fi] 发送时间: 2012年11月4日 10:57 到: vzhang2...@yahoo.com; Tina TSOU; Will Liu (Shucheng); ipsec@ietf.org 主题: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02 In section 4 this draft claims: -- The method enhances the security service by spreading the traffic onto multiple paths. -- I do not think the multiple paths really enhances the security. Also as the sequence number in sending and receive window handling is different (it is shared with all sub-SAs) this feature must be negotiated between the peers. The claim: -- For example, it makes it harder for the attacker to intercept all the packets if different routes are used. -- If attacker can intercept and decrypt one path, that is quite often already big enough problem that security is completely lost. Also -- Even with the same route used, it is harder for the attacker to know which set of SAs are clustered SA, thus harder to decrypt the intercepted packets. -- This kind of things are usually very easy to see from traffic analysis. Especially if the packets are round robined over the all sub-SAs. Also as the SPI and sequence numbers are in clear, and as sequence number counter is shared between all sub-SAs it is trivial to see which packets belong to the same clustered SA set. Also using different keys to encrypt the different sub-SAs will not add that much to the security. If the underlaying crypto algorithm has 2^128 bits of security, splitting the data over for example 4 sub-SAs will simply add 2 more bits of security. On the other hand it is usually much better for attacker to attack the IKEv2 negotiation itself (the Diffie-Hellman etc), as those most likely have less security than the symmetric crypto used to protect the data, and if that can be broken then that will also reveal all sub-SA keys. In section 6 there is text saying: -- SA cluster provides the option to perform the different cryptographic transformation on the different packet. -- which actually lowers the security. If one sub-SA uses DES and another uses 3DES, the overall security is lowered to the level of DES... Even if both algorithms are supposed to have same strength (AES, CAMELLIA etc) that does not mean that they in practice have exactly same security. In this case attacker will attack the weaker algorithm and again gains benefits over than if same stronger algorithm was used on all of the data. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt
Hi, all > So if any of you are interested, and are willing to review, please let us > know. I would like to review this draft. Cheers, Yang == Yang Cui, Ph.D. Huawei Technologies cuiy...@huawei.com > -邮件原件- > 发件人: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 代表 Yoav > Nir > 发送时间: 2012年5月3日 3:33 > 收件人: IPsecme WG > 抄送: ho...@ietf.org > 主题: Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt > > Hi again. > > The response has so far been underwhelming. As I said in my previous > message, I'm perfectly willing to go the individual route, but I think this > would > be a shame. The protocol extension described can have applications in both > remote access VPN (opening multiple tunnels with multiple gateways) and in > seamless roaming between remote access VPN and local area wireless > networks. > > I also think that it touches a lot of different areas, and would benefit from > the input of people better versed than me in the needs of cellular providers > and AAA. > > I am CC-ing the HOKEY mailing list (as I should have done earlier) because > this > draft actually adapts IKE to work with their protocol, and they may be willing > to review and contribute, even if this is IPsecME work. > > So if any of you are interested, and are willing to review, please let us > know. > > Yoav & Qin > > On Apr 12, 2012, at 10:31 PM, Paul Hoffman wrote: > > > On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote: > > > >> We would like this working group to accept this, and have it added to > charter. Of course, if it gets accepted, we volunteer to be authors. If it is > not > accepted, we will try to progress it as an individual submission, but we > believe that this changes IKE enough that it should come from the working > group. > > > > > > Statements of interest and disinterest on this document are welcome. If > you prefer to make such a statement off-list please send it to me or Yaron. > > > > A statement of interest that include a promise to review in WG LC count for > more than a bare statement of interest. > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
