Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

[Tero Kivinen]

Valery Smyslov writes:
> my comments mostly are addressed, thanks.
> The one still unaddressed is a strange comment "?SHOULD" in the last table
> (Section 4.2). What does it mean?

I think that is leftover from our internal discussions, i.e. whether
we should mark that ecdsa-with-sha512 as SHOULD instead of MAY.

I think MAY is fine, so unless people think we should pick that too
with SHOULD, I will remove that in next version. I do not think we
need to do it now, we can do the WGLC with the draft we have now, and
remove it after that.

Other thing I want people to think is whether we should say something
else about the AES key sizes, i.e. we now say MUST for 128-bit, MAY
for 256-bit and "192-bit keys can safely be ignored." One proposal
that was done was to change that MUST for 128-bit, SHOULD for 256-bit,
and perhaps even SHOULD NOT for 192-bit.
-- 
kivi...@iki.fi

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

[Valery Smyslov]

Hi,

my comments mostly are addressed, thanks.
The one still unaddressed is a strange comment "?SHOULD" in the last table
(Section 4.2). What does it mean?

Regards,
Valery.

-Original Message- 
From: Tero Kivinen

Sent: Wednesday, April 6, 2016 3:06 PM
To: internet-dra...@ietf.org
Cc: ipsec@ietf.org ; i-d-annou...@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

internet-dra...@ietf.org writes:

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.


This version includes the pre-shared keys (or "Shared Key Message
Integrity Code") in the authentication method table, as it specified
in the RFC7296 as mandatory to implement, so we want to say it MUST
here too. While I was doing that change, I noticed that we actually
update the RFC7296, as the 7296 section 4 has text saying that RSA
with key lengths of 1024 or 2048 are mandatory. In our section 4.1.1
we actually say that RSA key lengths with less than 2048 bits are
SHOULD NOT, so our recommendation are different than what is in the
RFC7296. After quick verify from our WG chair, I marked this document
as updating the RFC7296 (and added the missing fact that is obsoletes
rfc4307). The fact that this updates RFC7296 was also added in the
introduction.

In addition to those changes, this contains some fixes for some typos
etc (especially in the section 5 algoritms for IoT).

With these changes, I think this document is ready for the WGLC.

Title   : Algorithm Implementation Requirements and Usage 
Guidance for IKEv2

Authors : Yoav Nir
  Tero Kivinen
  Paul Wouters
  Daniel Migault
Filename: draft-ietf-ipsecme-rfc4307bis-06.txt
Pages   : 16
Date: 2016-04-06

Abstract:
   The IPsec series of protocols makes use of various cryptographic
   algorithms in order to provide security services.  The Internet Key
   Exchange (IKE) protocol is used to negotiate the IPsec Security
   Association (IPsec SA) parameters, such as which algorithms should be
   used.  To ensure interoperability between different implementations,
   it is necessary to specify a set of algorithm implementation
   requirements and usage guidance to ensure that there is at least one
   algorithm that all implementations support.  This document defines
   the current algorithm implementation requirements and usage guidance
   for IKEv2.  This document does not update the algorithms used for
   packet encryption using IPsec Encapsulated Security Payload (ESP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06


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


--
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] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

[Tero Kivinen]

internet-dra...@ietf.org writes:
> 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.

This version includes the pre-shared keys (or "Shared Key Message
Integrity Code") in the authentication method table, as it specified
in the RFC7296 as mandatory to implement, so we want to say it MUST
here too. While I was doing that change, I noticed that we actually
update the RFC7296, as the 7296 section 4 has text saying that RSA
with key lengths of 1024 or 2048 are mandatory. In our section 4.1.1
we actually say that RSA key lengths with less than 2048 bits are
SHOULD NOT, so our recommendation are different than what is in the
RFC7296. After quick verify from our WG chair, I marked this document
as updating the RFC7296 (and added the missing fact that is obsoletes
rfc4307). The fact that this updates RFC7296 was also added in the
introduction.

In addition to those changes, this contains some fixes for some typos
etc (especially in the section 5 algoritms for IoT).

With these changes, I think this document is ready for the WGLC.

> Title   : Algorithm Implementation Requirements and Usage 
> Guidance for IKEv2
> Authors : Yoav Nir
>   Tero Kivinen
>   Paul Wouters
>   Daniel Migault
>   Filename: draft-ietf-ipsecme-rfc4307bis-06.txt
>   Pages   : 16
>   Date: 2016-04-06
> 
> Abstract:
>The IPsec series of protocols makes use of various cryptographic
>algorithms in order to provide security services.  The Internet Key
>Exchange (IKE) protocol is used to negotiate the IPsec Security
>Association (IPsec SA) parameters, such as which algorithms should be
>used.  To ensure interoperability between different implementations,
>it is necessary to specify a set of algorithm implementation
>requirements and usage guidance to ensure that there is at least one
>algorithm that all implementations support.  This document defines
>the current algorithm implementation requirements and usage guidance
>for IKEv2.  This document does not update the algorithms used for
>packet encryption using IPsec Encapsulated Security Payload (ESP).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06
> 
> 
> 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

-- 
kivi...@iki.fi

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

[IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

[internet-drafts]

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   : Algorithm Implementation Requirements and Usage 
Guidance for IKEv2
Authors : Yoav Nir
  Tero Kivinen
  Paul Wouters
  Daniel Migault
Filename: draft-ietf-ipsecme-rfc4307bis-06.txt
Pages   : 16
Date: 2016-04-06

Abstract:
   The IPsec series of protocols makes use of various cryptographic
   algorithms in order to provide security services.  The Internet Key
   Exchange (IKE) protocol is used to negotiate the IPsec Security
   Association (IPsec SA) parameters, such as which algorithms should be
   used.  To ensure interoperability between different implementations,
   it is necessary to specify a set of algorithm implementation
   requirements and usage guidance to ensure that there is at least one
   algorithm that all implementations support.  This document defines
   the current algorithm implementation requirements and usage guidance
   for IKEv2.  This document does not update the algorithms used for
   packet encryption using IPsec Encapsulated Security Payload (ESP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06


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

Re: [IPsec] Next steps on TCP Encapsulation for IKEv2

[Tommy Pauly]

Hi Yoav,

Thanks for the feedback. While I see the advantage of adding the magic value at 
the start of the non-TLS TCP stream, especially over port 443, this seems to 
require the document to even more explicitly discuss TLS. If implementations do 
end up using TLS, as I believe many will in practice, then presumably they 
would not include this magic byte at the beginning of their stream over TLS. 
This means that the inner protocol diverges depending on which set of protocols 
are being used for the stream. I would prefer that these be consistent if 
possible.

Thoughts?

Tommy

> On Apr 5, 2016, at 1:14 PM, Yoav Nir  wrote:
> 
> Hi, Tommy.
> 
> The changes look fine, although I’m still not convinced we even need the TLS. 
> But that’s for another thread.
> 
> We foresee that most TCP encapsulation is likely to be in on port 443. I 
> think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from 
> other types of traffic on the same port.
> 
> I propose we add a magic value at the start of a non-TLS TCP stream, 
> something very different from (0x16, 0x03, 0x01, 0x00).
> 
> Yoav
> 
> 
>> On 5 Apr 2016, at 12:27 PM, Tommy Pauly > > wrote:
>> 
>> Hello,
>> 
>> At our meeting yesterday, we agreed that we want one more revision of 
>> draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group 
>> adoption to clear up a few concerns.
>> 
>> Here are the changes we’re planning:
>> 
>> 1. Reconcile the length field size with 3GPP’s recommendation (sent out by 
>> Tero) to promote interoperability if any devices have already implemented 
>> 3GPP’s suggestions. This would mean changing the length field from 32 bits 
>> to 16 bits.
>> 
>> 2. Address the concerns around including too many direct references to use 
>> of TLS and port 443 in the body of the standards track document. The current 
>> plan here would be to make all direct references to TLS in the body of the 
>> document be more generic regarding any protocols over TCP that are added to 
>> encapsulate the IKE session, and point to an appendix that explains the 
>> caveats regarding TLS. The main point to communicate is that TLS should not 
>> influence the framing of IKE or ESP packets on the stream, and that the 
>> encryption and authentication properties of TLS do not influence the IKE 
>> session at all. Valery, I believe this should address your concerns.
>> 
>> Please reply with your feedback if you think these changes are good ideas, 
>> and if there are any other remaining points that should be changed before we 
>> move ahead.
>> 
>> After this, the plan would be to ask for working group adoption of the 
>> document if there are no other objections, and to in parallel start an 
>> informational document (perhaps a draft, perhaps outside of IETF) to 
>> describe the practical strategies for using TLS to encapsulate the tunnel, 
>> and more detail on proxy interactions.
>> 
>> Thanks,
>> Tommy Pauly
>> ___
>> 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