Re: [IPsec] Quantum Resistant IKEv2

[Yoav Nir]

> On 8 Dec 2016, at 1:43, Michael Richardson  wrote:
> 
> 
> Scott Fluhrer (sfluhrer)  wrote:
>> o There is the option listed in the draft, where we modify both the
>> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies
> 
> I read through the three options, and I have difficulty picking.

Me too. I’m not too worried about information in the IKE SA, so I wouldn’t 
disqualify Dan’t on that basis.

>> o Valery Smyslov gave a suggestion that we instead stir in the PPK
>> into the initial SK_d; as all keying material is generated based on
>> that, this would also mean that IPsec SAs and any child IKE SAs are
>> also protected. This also means that an implementation would not need
>> to remember the PPK after the initial negotiation. The only downside I
>> can see is that we would have to be a bit careful about when we update
>> the SK_d (obviously, before we actually use it).
> 
> If we can make this work, it seems like the best, as it means we can forget
> more things sooner.

I’m guessing this would be something along these lines:

OLD:
   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )

NEW:
   {SK_proto_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )n

   SK_d = prf(PPK, SK_proto_d}

So assuming this works and is secure, it seems like an easy change.

>> o Would this idea of pseudonyms actually give any real identity
>> protection? Wouldn’t that assume that several initiators use the same
>> PPK (so they could use the same pseudonym)? Is that the sort of thing
>> we should be encouraging?
> 
> I need to think about this.
> 
> It only matters to "road warriors", i.e. remote access situations where the
> end user can move around.  This includes many more site to site VPNs these
> days due to CGN and just poor network architecture, such as the Cloud
> operators' baked in NAT44.
> 
> I'm concerned that we would wind up with a new Group PSK like we had with 
> IKEv1.

Pseudonyms are not too difficult on the protocol level, but managing them makes 
products and configuration very difficult. So you’re giving groups of people 
the same pseudonym and the same PPK? How do you group people together? With 
non-careful grouping of users you can make it worse than exposing real names 
(not “ynir”, but “RND_ACCESS_GROUP”, which is more useful to an attacker). And 
that is the kind of exposure that we can’t fix in protocol - we’re trusting 
administrators to balance convenience, privacy and corporate information 
security. I think they’ll all choose a single PPK and single pseudonym for 
everybody.

>> o Would we be happy with always negotiating a child SA (as none of the
>> three proposals for stirring in the PPK attempt to protect the initial
>> IKE SA)?
> 
> I wonder if this might be simpler and more reliable to just always do it, and
> specify it up front.

Simple, yes. Reliable, yes. Necessary? IDK

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] RFC4301, rfc7321bis and Manual keys

[Michael Richardson]

Russ Housley  wrote:
> I can see that manual keys are helpful for debugging, but otherwise I
> think they SHOULD NOT be used.

Exactly. I would like to have a SHOULD provide an interface (without which, I
can't determine why I can't interoperate with product FOO), but I agree with
Tero, I really don't want logos/etc. to be dependant on it.

>> Perhaps we should add note to the rfc7431bis that manual keys SHOULD
>> NOT be used, and mark it as updating RFC4301?

Yes.

>> Or should we have separate RFC stating that?
>>
>> I do not want to change it to MUST NOT as that would require people to
>> remove parts of their implementations to stay complient, but on the
>> other hand I do not want people to wasting their time to implenting
>> interface to configure manual keys when nobody is going to use them.

I would like people to document an interface, but I have no desire to expose
it to users.  In your Android example, I'm perfectly happy with having a
shell and a netlink/pfkey socket as the "interface".

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] RFC4301, rfc7321bis and Manual keys

[Paul.Koning]

On Dec 7, 2016, at 5:00 PM, Timothy Carlin 
> wrote:

Hello  All,

I have some comments inline.

On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters 
> wrote:
...

Are people actually deploying this?


The NIST USGv6 Profile current mandates RFC4552 and as such manual keys.

Yes, that's PRECISELY the issue.  Presumably NIST put it into the profile 
because manual keys are mentioned in the RFC, not realizing how bad an error 
that is.


...

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.

That is the main reason I argued for MUST NOT.

By way of illustration: in an IPSec-enabled product I work on, we implemented 
manual keying only to be able to pass the USGv6 tests.  The manual states that 
the feature [sic] exists only for that reason and that manual keys should never 
be used.  When we submitted the product for Common Criteria evaluation, the 
evaluators told us we needed to strengthen that statement, so it now says that 
manual keys "exist only because of certification requirements and must never be 
used".

This is clearly absurd.  A feature in a security protocol that has always  been 
known to be a hazard to security needs to be removed.  It's been far too long 
already.

paul


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Quantum Resistant IKEv2

[Michael Richardson]

Scott Fluhrer (sfluhrer)  wrote:
> o There is the option listed in the draft, where we modify both the
> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies

I read through the three options, and I have difficulty picking.

...
> o Valery Smyslov gave a suggestion that we instead stir in the PPK
> into the initial SK_d; as all keying material is generated based on
> that, this would also mean that IPsec SAs and any child IKE SAs are
> also protected. This also means that an implementation would not need
> to remember the PPK after the initial negotiation. The only downside I
> can see is that we would have to be a bit careful about when we update
> the SK_d (obviously, before we actually use it).

If we can make this work, it seems like the best, as it means we can forget
more things sooner.

> o Would this idea of pseudonyms actually give any real identity
> protection? Wouldn’t that assume that several initiators use the same
> PPK (so they could use the same pseudonym)? Is that the sort of thing
> we should be encouraging?

I need to think about this.

It only matters to "road warriors", i.e. remote access situations where the
end user can move around.  This includes many more site to site VPNs these
days due to CGN and just poor network architecture, such as the Cloud
operators' baked in NAT44.

I'm concerned that we would wind up with a new Group PSK like we had with IKEv1.

> o Would we be happy with always negotiating a child SA (as none of the
> three proposals for stirring in the PPK attempt to protect the initial
> IKE SA)?

I wonder if this might be simpler and more reliable to just always do it, and
specify it up front.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt

[Tommy Pauly]

Thanks for confirming! I appreciate all of your help in cleaning this part up!

Tommy

> On Dec 7, 2016, at 11:52 AM, Hu, Jun (Nokia - US)  wrote:
> 
> Looks good to me
> 
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
>> Sent: Sunday, December 04, 2016 3:07 PM
>> To: IPsecME WG 
>> Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt
>> 
>> Hello all,
>> 
>> I've updated the TCP Encapsulation draft with new recommendations around
>> handling the mapping between IKE SAs and TCP Connections based on the
>> conversation at the Seoul meeting. The relevant new text in section 6 is:
>> 
>> 
>> An initiator SHOULD only open one TCP connection per IKE SA, over
>>   which it sends all of the corresponding IKE and ESP messages.  This
>>   helps ensure that any firewall or NAT mappings allocated for the TCP
>>   connection apply to all of the traffic associated with the IKE SA
>>   equally.
>> 
>>   A responder SHOULD at any given time send packets for an IKE SA and
>>   its Child SAs over only one TCP connection.  It should choose the TCP
>>   connection on which it last received a valid and decryptable IKE or
>>   ESP message.  Since a connection may be broken and a new connection
>>   re-established by the initiator without the responder being aware, a
>>   responder SHOULD accept receiving IKE and ESP messages on a new
>>   connection.  It will then use that connection for all subsequent
>>   responses.  A responder MAY close a TCP connection that it perceives
>>   as idle and extraneous (one previously used for IKE and ESP messages
>>   that has been replaced by a new connection).
>> 
>>   Multiple IKE SAs SHOULD NOT share a single TCP connection.
>> 
>> Please respond to indicate your thoughts on this!
>> 
>> Thanks,
>> Tommy
>> 
>> 
>>> On Dec 4, 2016, at 3:04 PM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the IP Security Maintenance and Extensions of 
>>> the
>> IETF.
>>> 
>>>   Title   : TCP Encapsulation of IKE and IPsec Packets
>>>   Authors : Tommy Pauly
>>> Samy Touati
>>> Ravi Mantha
>>> Filename: draft-ietf-ipsecme-tcp-encaps-04.txt
>>> Pages   : 21
>>> Date: 2016-12-04
>>> 
>>> Abstract:
>>>  This document describes a method to transport IKE and IPsec packets
>>>  over a TCP connection for traversing network middleboxes that may
>>>  block IKE negotiation over UDP.  This method, referred to as TCP
>>>  encapsulation, involves sending both IKE packets for tunnel
>>>  establishment as well as tunneled packets using ESP over a TCP
>>>  connection.  This method is intended to be used as a fallback option
>>>  when IKE cannot be negotiated over UDP.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at 
>>> tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] RFC4301, rfc7321bis and Manual keys

[Hu, Jun (Nokia - US)]

> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Wednesday, December 07, 2016 1:42 PM
> To: Hu, Jun (Nokia - US) 
> Cc: Tero Kivinen ; ipsec@ietf.org
> Subject: Re: [IPsec] RFC4301, rfc7321bis and Manual keys
> 
> 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?
> 
> 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)
> 
[HJ] OSPFv3 has been implemented on almost all IPv6 capable enterprise/carrier 
level  routers for long time, and as only standard auth method, RFC4552 was 
also implemented along with OSPFv3;
So I think I could say RFC4552 has been already deployed widely for long time,
We can't ignore this just because manual key is less secure; in fact using 
IKEv2 and RFC5374 is almost impractical for a IGP routing protocol, because 
when deployed, OSPFv3 is an part of network routing infrastructure; adding 
IKEv2 and RFC5374 not only add lots additional complexity to the routing plane 
(it gona be a non-starter already for many people), but also using RFC5374 
require to use a central key server, it means the key server need to be 
reachable before OSPFv3 is up and running, which might not be feasible; 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] RFC4301, rfc7321bis and Manual keys

[Timothy Carlin]

Hello  All,

I have some comments inline.

On Wed, Dec 7, 2016 at 4:41 PM, Paul Wouters  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
> 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] RFC4301, rfc7321bis and Manual keys

[Paul Wouters]

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?

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]


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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt

[Hu, Jun (Nokia - US)]

Looks good to me

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
> Sent: Sunday, December 04, 2016 3:07 PM
> To: IPsecME WG 
> Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt
> 
> Hello all,
> 
> I've updated the TCP Encapsulation draft with new recommendations around
> handling the mapping between IKE SAs and TCP Connections based on the
> conversation at the Seoul meeting. The relevant new text in section 6 is:
> 
> 
> An initiator SHOULD only open one TCP connection per IKE SA, over
>which it sends all of the corresponding IKE and ESP messages.  This
>helps ensure that any firewall or NAT mappings allocated for the TCP
>connection apply to all of the traffic associated with the IKE SA
>equally.
> 
>A responder SHOULD at any given time send packets for an IKE SA and
>its Child SAs over only one TCP connection.  It should choose the TCP
>connection on which it last received a valid and decryptable IKE or
>ESP message.  Since a connection may be broken and a new connection
>re-established by the initiator without the responder being aware, a
>responder SHOULD accept receiving IKE and ESP messages on a new
>connection.  It will then use that connection for all subsequent
>responses.  A responder MAY close a TCP connection that it perceives
>as idle and extraneous (one previously used for IKE and ESP messages
>that has been replaced by a new connection).
> 
>Multiple IKE SAs SHOULD NOT share a single TCP connection.
> 
> Please respond to indicate your thoughts on this!
> 
> Thanks,
> Tommy
> 
> 
> > On Dec 4, 2016, at 3:04 PM, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the IP Security Maintenance and Extensions of 
> > the
> IETF.
> >
> >Title   : TCP Encapsulation of IKE and IPsec Packets
> >Authors : Tommy Pauly
> >  Samy Touati
> >  Ravi Mantha
> > Filename: draft-ietf-ipsecme-tcp-encaps-04.txt
> > Pages   : 21
> > Date: 2016-12-04
> >
> > Abstract:
> >   This document describes a method to transport IKE and IPsec packets
> >   over a TCP connection for traversing network middleboxes that may
> >   block IKE negotiation over UDP.  This method, referred to as TCP
> >   encapsulation, involves sending both IKE packets for tunnel
> >   establishment as well as tunneled packets using ESP over a TCP
> >   connection.  This method is intended to be used as a fallback option
> >   when IKE cannot be negotiated over UDP.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > 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] RFC4301, rfc7321bis and Manual keys

[Hu, Jun (Nokia - US)]

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"

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
> Sent: Wednesday, December 07, 2016 8:11 AM
> To: ipsec@ietf.org
> Subject: [IPsec] RFC4301, rfc7321bis and Manual keys
> 
> The RFC4301 requires support for manual keys (section 4.5), but I hope
> nobody really uses them. 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).
> 
> 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).
> 
> 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.
> We had it in 4301 as MUST to implement as we assumed that it could be used
> to fill in keying material from other source than IKE to the IPsec 
> architecture. I
> do not think that is really happening, I think those other automated key
> management systems will also generate dynamic keys, and are feeding them in
> using similar APIs we have for IKEv2. Also manual keys were useful when doing
> initial IPsec testing in interops, but I have not used them for that purposes 
> in
> last decade or so...
> 
> 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?
> 
> I do not want to change it to MUST NOT as that would require people to
> remove parts of their implementations to stay complient, but on the other
> hand I do not want people to wasting their time to implenting interface to
> configure manual keys when nobody is going to use them.
> --
> 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] RFC4301, rfc7321bis and Manual keys

[Russ Housley]

I can see that manual keys are helpful for debugging, but otherwise I think 
they SHOULD NOT be used.

Russ


On Dec 7, 2016, at 11:11 AM, Tero Kivinen  wrote:

> The RFC4301 requires support for manual keys (section 4.5), but I hope
> nobody really uses them. 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). 
> 
> 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).
> 
> 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.
> We had it in 4301 as MUST to implement as we assumed that it could be
> used to fill in keying material from other source than IKE to the
> IPsec architecture. I do not think that is really happening, I think
> those other automated key management systems will also generate
> dynamic keys, and are feeding them in using similar APIs we have for
> IKEv2. Also manual keys were useful when doing initial IPsec testing
> in interops, but I have not used them for that purposes in last
> decade or so...
> 
> 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?
> 
> I do not want to change it to MUST NOT as that would require people to
> remove parts of their implementations to stay complient, but on the
> other hand I do not want people to wasting their time to implenting
> interface to configure manual keys when nobody is going to use them.
> -- 
> 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

[IPsec] RFC4301, rfc7321bis and Manual keys

[Tero Kivinen]

The RFC4301 requires support for manual keys (section 4.5), but I hope
nobody really uses them. 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). 

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).

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.
We had it in 4301 as MUST to implement as we assumed that it could be
used to fill in keying material from other source than IKE to the
IPsec architecture. I do not think that is really happening, I think
those other automated key management systems will also generate
dynamic keys, and are feeding them in using similar APIs we have for
IKEv2. Also manual keys were useful when doing initial IPsec testing
in interops, but I have not used them for that purposes in last
decade or so...

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?

I do not want to change it to MUST NOT as that would require people to
remove parts of their implementations to stay complient, but on the
other hand I do not want people to wasting their time to implenting
interface to configure manual keys when nobody is going to use them.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec