Hello All, I have some comments inline.
On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters <[email protected]> wrote: > On Wed, 7 Dec 2016, Hu, Jun (Nokia - US) wrote: > > OSPFv3 authentication (RFC4552) mandate to use manual key, the reason is >> OSPFv3 uses multicast. >> So I could see manual key IPsec could be needed in any multicast >> applications since group key management is not widely available >> For above reason, I think it should be "MAY" instead of "SHOULD NOT" >> > > Reading that RFC, it is really cracking on all sides. You even need to > use the same SPIs and ENC keys for inbound and outbound SA's. I really > don't think this is a very well thought out use case for IPsec. > > Are people actually deploying this? > > The NIST USGv6 Profile current mandates RFC4552 and as such manual keys. > How long are these static SPIs/keys used for? forever? > > I don't think we need to take those requirements into consideration. If > anything, someone needs to update RFC4552 to allow for a more modern use > of IKEv2 and multicast (RFC5374) > > The RFC4301 requires support for manual keys (section 4.5), but I hope >>> nobody really uses them. >>> >> > I have hoped that for many years. And like Transport Mode and IPCOMP, > these things refuse to die. Anyways, we are not updating 4301, so I > think this part is out of scope, but: > > The rfc7321bis provides mandatory to implement >>> algorithms for the IKEv2 use, and does not really specifically cover >>> manual keys >>> cases, but it does not really say that manual keyed SAs are out of scope >>> either >>> (like it does say for IKEv1). >>> >> > I guess 7321 should have had a note about manual keying in it, and it > does not. We can surely add a note about manual keying. > > The issue is that some of the conformance logo documents actually do >>> require >>> manual keys, and to gain those logos implementors need to add support for >>> manual keyed SAs even when nobody is really going to use them (i.e., >>> adding >>> support for manual keys for android VPN client seems little stupid). >>> >> > 7321bis should not change the requirement for manual keying. It should > only talk about algorithms. > > On the other hand if you use the rfc7321bis requirements for also manual >>> keys, >>> there is only one suggested cipher that can be used, namely ENCR_AES_CBC. >>> >>> None of the counter mode ciphers are safe to use with manual keys, and >>> for >>> example RFC4106 (AES-GCM) requires using automated key management. >>> The RFC4309 (AES-CCM) says that it "should not be used with statically >>> configured keys", and that "MUST use fress keys". RFC7634 >>> (Chacha20-poly1305) does not explictly say anything about manual keys, >>> but >>> says it gets bitstring called KEYMAT from IKE... >>> >>> If we assume rfc7431bis can be used with manual keys too, we need to add >>> some more text saying these ciphers cannot be used with manual keys. >>> >> > Anyways, I think it should be time to mark manual keys as SHOULD NOT. >>> >> > While I agree, I don't think 7321bis should do that. > > How about a new section between section 2 and 3: > > Manual Keying > > Manual Keying should not be used as it is inherently dangerous. Without > any keying protocol, it does not offer Perfect Forward Secrecy > protection. Deployments tend to never be reconfigured with fresh session > keys. It also fails to scale and keeping SPI's unique amongst many servers > is impractical. This document was written for deploying ESP/AH using IKE > (RFC7298) and assumes that keying happens using IKEv2. > > If manual keying is used anyway, ENCR_AES_CBC MUST be used, and > ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT > be used as these algorithms require IKE. > > [note the first "should not" is in lower case in purpose, so we don't > actually need to update 4301] > > I agree with the sentiment that Manual Keys should be avoided. However for the conformance logo documents it would be helpful to have RFC2119 language to point to when setting the requirements for testing. Tim Carlin UNH-IOL > Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT >>> be used, and mark it as updating RFC4301? >>> >>> Or should we have separate RFC stating that? >>> >> > draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :) > > Seriously though, I don't think writing a document like that will change > anything. And at least on Linux, the ip xfrm command allows for manual > keying and therefor assist with testing, but the IKE daemons (libreswan, > strongswan and openswan) do not support manual keying anymore. > > Paul > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
