Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

[Paul Hoffman]

On 11 Dec 2019, at 11:11, Yoav Nir wrote:


Hi, Paul


On 11 Dec 2019, at 20:03, Paul Hoffman  wrote:

On 11 Dec 2019, at 8:23, Salz, Rich wrote:

We are seeing a flurry of these kind of “post quantum 
protection” things.


This is the only one I have seen that is a method, not a new key 
exchange algorithm. It is understandable that you could have missed 
this from the title which misstates the topic. A much better title 
would be "Mixing Preshared Keys in IKEv2 for Postquantum Resistance".


Should we consider this a last call comment?


Yes, please do.

--Paul Hoffman

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

Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

[Paul Hoffman]

On 11 Dec 2019, at 8:23, Salz, Rich wrote:

We are seeing a flurry of these kind of “post quantum protection” 
things.


This is the only one I have seen that is a method, not a new key 
exchange algorithm. It is understandable that you could have missed this 
from the title which misstates the topic. A much better title would be 
"Mixing Preshared Keys in IKEv2 for Postquantum Resistance".



This is premature.


Disagree. The method described in the document has been well-discussed 
in the IPsecME for years, getting good cryptographic review.



The co-chair of the CFRG, Kenny Paterson, said so awhile back.


I don't think that's what he said in the slides you posted, but I've 
Cc'd him so he can reply. The slides are about picking new post-quantum 
algorithms; what is described in the draft is a method for mixing in 
preshared secrets with current algorithms.


--Paul Hoffman

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

Re: [IPsec] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

[Paul Hoffman]

I'm glad to see this document finally make it towards standardization. 
Just a minor editorial note: capitalizing "Quantum Computers" is 
incorrect and should be fixed before it goes to the RFC Editor.


--Paul Hoffman

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

Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns

[Paul Hoffman]

On Jan 22, 2018, at 8:45 AM, Paul Wouters <p...@nohats.ca> wrote:
> I'm trying not to define any DNS terms in this document and stay out of
> any character/domain/hostname discussion. How about:
> 
>   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed
>   to another (DNS) program for processing. As with any network input, the
>   content should be considered untrusted and handled accordingly.

Yep, that works for me. With that and the other change you said was fine, I 
think this is quite ready for IETF Last Call.

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

Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns

[Paul Hoffman]

On Jan 21, 2018, at 7:20 PM, Paul Wouters <p...@nohats.ca> wrote:
>> - Section 6 says:
>>  The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
>>  passed to another (DNS) program for processing.  The content MUST be
>>  verified and sanitized before passing it to other software.  For
>>  example, domain names are limited to alphanumeric characters and the
>>  minus ("-") and underscore ("_") symbol and if other other characters
>>  are present, the entire payload could be ignored and not passed to
>>  DNS software, or the malicious characters could be filtered out
>>  before passing the payload to DNS software.
>> That is not correct. *Host* names are limited, but domain names are not. 
>> Domain names can have any octet in them. This is a common misunderstanding 
>> in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this 
>> paragraph be changed to:
> 
> That somewhat contradicts 7719 in which document you state:
> 
>   Note that any label in a
>   domain name can contain any octet value; hostnames are generally
>   considered to be domain names where every label follows the rules
>   in the "preferred name syntax"

There is no contradiction between what I say above and that.

> So a hostname - if FQDN - could have a leftmost label with other stuff
> in it, but everything to the right of the zone cut would have to be
> compliant to the restrive set. And we were talking about domain names,
> and not hostnames.

Nonono. Nothing in the definition of domain name or hostname has anything to do 
with label position.

> 
>>  The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
>>  passed to another (DNS) program for processing.  Some DNS programs
>>  only handle domain names in host name format, although many are
>>  inconsistent about this.
> 
> I would prefer to keep the focus on the security part. If there are
> weird characters, don't blindly pass those along.

If you're talking about domain names, there are no "weird characters": they are 
just blobs of octets.

> Whether something
> is a legit hostname or domainname is not very relevant to the IKE
> or IPsec layer. Whoever _receives_ the information can determine
> that part. We are mostly concerned about passing foo`cat /etc/passswd`.com

...which is a valid domain name (assuming an ASCII or UTF-8 encoding for the 
octets).

> 
> So how about:
> 
>   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
>   passed to another (DNS) program for processing.  The content MUST be
>   verified to not contain any malicious characters, before it is
>   passed to other programs for DNS processing. If it contains malicious
>   characters, the payload should be ignored or sanitized. Whether a
>   specific combination of non-malicious characters constitute a valid
>   DNS domain name is best left to be decided by the DNS software that
>   receives the contents of these payloads.
> 

Unless you can define "malicious", I would disagree. In fact, unless you can 
define "character", you will also have a problem (some encodings of characters 
take up multiple octets).

If you really want to go down this path, you must say something like "domain 
names where each label consist only of octets which map to the ASCII encoding 
of the following values: A to Z, a to z, 0 to 9, "-", and "_". 

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

[IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns

[Paul Hoffman]

Greetings. This document is still listed as in WG Last Call, although I haven't 
seen anything in the archive about that Last Call closing.

The document seems mostly fine, and it certainly seems like a useful IPsec 
extension. I have only two concerns:

- Section 5 says:
   An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing
   domains that are designated Special Use Domain Names in [RFC6761],
   such as "local", "localhost", "invalid", etc.  Although it may
   explicitly wish to support some Special Use Domain Names.
There is no way that an implementation can easily follow what is in the IANA 
registry for Special Use Domain names. Further, given that that the names are 
going to be internal, there isn't a good reason to prevent them from being used 
beyond the normal "don't make up names that someone else might be using" 
argument. The second sentence (fragment) doesn't give enough detail to help an 
implementer. I think that this whole paragraph can be safely removed.

- Section 6 says:
   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  The content MUST be
   verified and sanitized before passing it to other software.  For
   example, domain names are limited to alphanumeric characters and the
   minus ("-") and underscore ("_") symbol and if other other characters
   are present, the entire payload could be ignored and not passed to
   DNS software, or the malicious characters could be filtered out
   before passing the payload to DNS software.
That is not correct. *Host* names are limited, but domain names are not. Domain 
names can have any octet in them. This is a common misunderstanding in the DNS; 
see RFC 7719 for definitions of DNS terms. I suggest that this paragraph be 
changed to:
   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  Some DNS programs
   only handle domain names in host name format, although many are
   inconsistent about this. 

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

Re: [IPsec] 4307bis/7321bis key sizes

[Paul Hoffman]

On 23 Aug 2016, at 12:43, Derek Atkins wrote:


Paul,

On Tue, August 23, 2016 3:28 pm, Paul Hoffman wrote:


On 23 Aug 2016, at 12:12, Derek Atkins wrote:

Just to play devil's advocate here, are you implying that we'll see 
a

5-10-year lead time on quantum computer development sufficiently in
order
to spend those 5-10 years:
1) having this discussion again,
2) revving the documents
3) getting the revved documents through the process
4) getting the revved documents published
5) getting the revved documents implemented
6) getting that new implementation into the field, and (most
importantly)
7) getting the OLD hardware decommissioned?


No, not at all. PaulW's proposal is *not* about adding a new 
algorithm,

it is changing the recommendation status for the algorithms. Both
algorithms will be in the deployed systems. So the 5-10 years lead 
time
is getting users to change their configs. If we can't get them to 
change
them in 10 years, we probably can't get them to change them ever. It 
is
operator's responsibility to maintain their configurations, not ours 
to
be the configuration police. Note that this thread is split off from 
the

QR thread.


I apologize for jumping in, but my reading doesn't match your 
statement.

My reading was Paul proposing to change the Implementation Level of
AES-256 from SHOULD to MUST.


Ah! If you're right, then I agree with that part of his proposal.


That implied subtext is that some devices
may not currently implement AES-256 (even though they SHOULD) and he 
wants
to ensure that, if/when a quantum computer comes into existence then 
all

that is requires *IS* a configuration change to move deployment to
AES-256.


That sounds fine.

I may have misunderstood his proposal because he also wanted to demote 
AES-128 from MUST to MUST-. I object on the grounds that we have no idea 
if there will quantum-capable computers that can erode AES-128 in the 
foreseeable future, and that even if a dedicated adversary could weaken 
AES-128 to say 80 bits of strength, that we would want to say to all 
developers "don't implement this".


--PaulH

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

Re: [IPsec] 4307bis/7321bis key sizes

[Paul Hoffman]

On 23 Aug 2016, at 12:12, Derek Atkins wrote:


Just to play devil's advocate here, are you implying that we'll see a
5-10-year lead time on quantum computer development sufficiently in 
order

to spend those 5-10 years:
1) having this discussion again,
2) revving the documents
3) getting the revved documents through the process
4) getting the revved documents published
5) getting the revved documents implemented
6) getting that new implementation into the field, and (most 
importantly)

7) getting the OLD hardware decommissioned?


No, not at all. PaulW's proposal is *not* about adding a new algorithm, 
it is changing the recommendation status for the algorithms. Both 
algorithms will be in the deployed systems. So the 5-10 years lead time 
is getting users to change their configs. If we can't get them to change 
them in 10 years, we probably can't get them to change them ever. It is 
operator's responsibility to maintain their configurations, not ours to 
be the configuration police. Note that this thread is split off from the 
QR thread.


--PaulH

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

Re: [IPsec] 4307bis/7321bis key sizes

[Paul Hoffman]

On 23 Aug 2016, at 10:55, Paul Wouters wrote:


On Mon, 8 Aug 2016, Paul Wouters wrote:

I haven't heard any objection to making 128 bit key sizes MUST- and
256 bit key sizes MUST.


You can hear one now.


Answers that agree or disagree would be good
to hear.


The proposed change is based on the existence of quantum computers that 
have a sufficient number of properly-interacting qbits. We have 
literally no idea if those computers will ever exist. All current data 
indicates that we will see the progressing of "sufficient number" and 
"properly-interacting" and be able to increase key sizes well ahead of 
widespread use of quantum computers.


--Paul Hoffman

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

Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt

[Paul Hoffman]

On 9 Aug 2016, at 5:44, Scott Fluhrer (sfluhrer) wrote:


-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Monday, August 08, 2016 9:15 AM
To: Paul Hoffman
Cc: Yaron Sheffer; ipsec@ietf.org; Scott Fluhrer (sfluhrer)
Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt

Paul Hoffman writes:

On 5 Aug 2016, at 8:23, Yaron Sheffer wrote:


The trick to that is to add a new column to the IANA table
https://www.iana.org/assignments/ikev2-parameters/ikev2-

parameters.x

html#ikev2-parameters-5


That's the first of two tricks: the second is getting agreement 
about
the rules for the values in that column. It seems like there is 
still

disagreement in the crypto community about how susceptible different
algorithms and modes are to quantum.


As an IANA expert, I am not that happy adding yet another column to 
that

table. The ESP/IKEv2 reference columns already seem to make enough
confusion for people :-)


On the other hand, we need to give people some guidance somehow...


Do we? Who is "we"? Why is "our" guidance any better than what they get 
from their own experts, particularly if "our" guidance gets ossified in 
an IANA registry or RFCs that are updated slowly?


Also I think it is bad idea to list which ciphers are quantum 
computing safe, as
I have no idea whether RC5 or Blowfish are really in that category, 
even

when they do have long keys...


There's no known Quantum attack against either (assuming long keys), 
and so they're in the same category as AES-256.


That would be better stated as "There's currently no known..."

It might be better to list ciphers which we consider not to be safe, 
i.e.,
explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 
128-

bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not
PRF_AES_CBC).


That makes a lot of sense; ultimately, we don't really know which ones 
are strong against Quantum Computers (then again, we really don't know 
which ones are strong against conventional computers using 
undiscovered attacks :-); we do know some are likely weak.


Exactly.

--Paul Hoffman

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

Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt

[Paul Hoffman]

On 5 Aug 2016, at 8:23, Yaron Sheffer wrote:


The trick to that is to add a new column to the IANA table
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5


That's the first of two tricks: the second is getting agreement about 
the rules for the values in that column. It seems like there is still 
disagreement in the crypto community about how susceptible different 
algorithms and modes are to quantum.


--Paul Hoffman

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

Re: [IPsec] draft-pauly-ipsecme-split-dns-01 discussion

[Paul Hoffman]

Greetings. I support the adoption of this draft as a WG document. I have 
a minor editorial quibble (it should be "split DNS" instead of 
"Split-DNS"), and would like a reference to RFC 2775, but those can be 
dealt with as the WG discusses the document.


--Paul Hoffman

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

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Paul Hoffman]

On 3 Jul 2016, at 11:32, Paul Wouters wrote:

On Jul 3, 2016, at 21:08, Mark McFadden <markmcfad...@icc-uk.com> 
wrote:


A number of quantum-resistant asymmetric public key algorithms have 
been proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny 
Diffie-Hellman.


I thought NTRU was patent encumbered? Is that still the case? How 
about the others you mention?


I agree asking CFRG for help would be a wise decision.


Isn't this kinda off-topic for the thread? I though we were first 
considering "create an IKEv2 extension that mixes in the PSK" as the 
simplest way to get around the "go back to IKEv1" guidance.


--Paul Hoffman

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

[IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

[Paul Hoffman]

Greetings. As discussed on the list for the past few weeks, and in the 
face-to-face meeting in Buenos Aires (which, for many of us, seems to 
translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready 
for WG Last Call. We would like everyone to review it carefully, given 
that there have been some significant changes over the past few months.


This WG Last Call will end on April 22. It would be grand if everyone on 
this list would read the draft as if it was brand new and respond on the 
list with any problems, any questions, or even just "it is ready to 
progress as-is". Extra points are given for reviewers who don't wait 
until the last minute.


--Paul Hoffman and Dave Waltermire

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

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

[Paul Hoffman]

On 23 Mar 2016, at 14:01, Tero Kivinen wrote:

> Valery Smyslov writes:
>>> It matters when you use things like 802.15.9. IEEE 802.15.9 provides a
>>> method to transport IKEv2 messages over IEE Std 802.15.4. In typical
>>> PHY of the 802.15.4 the max frame size is 127 bytes, which leaves
>>> about 96 bytes for the 802.15.9 for payload. Normal 300 byte IKEv2
>>> packet will require about 3-4 fragments sent in 3-4 frames. Each of
>>> those frames will be acknowledged, and there might be timing
>>> constrains how often they can be sent (for example in TSCH network
>>> this might be once per second at max, when using 10ms slot time, and
>>> slotframe size of 100).
>>>
>>> If we raise the MAC size from 8 to 16, that will cause 8% probability
>>> that we need one more frame to send that last part...
>>
>> That's a good reason. Shouldn't this (or similar) explanation be
>> added to the draft?
>
> Perhaps. How much of current information we want to put in the
> document. The things are changing all the time, and it might be true
> now for IoT, but might not be true in few years. Isn't enough to just
> say that currently this algorithm might be used for IoT.

That seems to be the right way to go.

--Paul Hoffman

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

Re: [IPsec] Proposed wording for a revised charter

[Paul Hoffman]

On 21 Mar 2016, at 8:54, Daniel Palomares wrote:


Hello Paul,

MOBIKEv2 was already presented in IETF90.
https://www.ietf.org/proceedings/90/slides/slides-90-ipsecme-3.pdf
We had little discussion, but I felt there was interest on this 
proposal.


I understand that it was discussed in the distant past, and that there 
was a tad of interest. That's not enough to get it in the charter.


--Paul Hoffman

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

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

[Paul Hoffman]

This version has many significant changes from the previous draft. 
Please review it soon so we don't have a lot of surprises in WG Last 
Call.


--Paul Hoffman

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

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

[Paul Hoffman]

On 11 Mar 2016, at 6:07, Daniel Migault wrote:

> I would also be more than happy to present our ongoing work on IKEv2/YANG.

Great! Please so do on the list. :-)

--Paul Hoffman

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

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

[Paul Hoffman]

On 11 Mar 2016, at 4:55, Paul Wouters wrote:


I would like to discuss the IKEv2 IANA registries and the requirements
for new code points. This is in response to Tero's comments regarding
the latest non-WG entry for a 3gpp extension that was never passed
through the working group. Tero's suggestion was to "allow it this
time", which really begs the question on how we will handle this in 
the

future.


That seems to be a reasonable topic for discussion. Could you (or you 
and Tero) put together a proposal and do 10 minutes on it?


--Paul Hoffman

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

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

[Paul Hoffman]

On 10 Mar 2016, at 23:13, Yoav Nir wrote:


Regarding draft-ietf-ipsecme-safecurves

I think this is pretty much done. I don’t see why I’d need 15 
minutes to say, “Version -00 had Curve25519; version -01 added 
Curve448; we don’t need to wait for CFRG’s signature draft, 
because we have RFC 7427; I think we’re ready for WGLC”


Great! I've cut down the time allotment for it then.

Of course, you could say that on the list in a separate thread so that 
we'll start the WG Last Call sooner...


--Paul Hoffman

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

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

[Paul Hoffman]

On 10 Mar 2016, at 21:52, Valery Smyslov wrote:

I'd like to make a short presentation (~10 min) about using 
compression in IKEv2

(draft-smyslov-ipsecme-ikev2-compression).


Sorry, we totally spaced that out. We'll add it.


I'm also a bit puzzled that there is nothing in the agenda
concerning the yang data model for IPsec. I remember in Prague
authors promised to merge their drafts and to present
a new model. I see the new draft issued, but I heard no details of 
what

was changed (and why), and what are the next steps.


As you point out, the authors already had time to do an initial 
presentation. Since then, there has been no discussion on the mailing 
list. Using face-to-face meeting time to discuss things that are not 
discussed on the list is not a good use of our time. If the Yang model 
stuff starts being discussed on the list and there is sufficient 
interest, we should talk about it at future meetings or even at a 
virtual interim.


--Paul Hoffman

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

[IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

[Paul Hoffman]

https://www.ietf.org/proceedings/95/agenda/agenda-95-ipsecme

Comments are welcome.

Of course, this is not an invitation to stop conversation before the 
meeting; just the opposite. Please keep the on-list discussion active so 
that the meeting can be more useful.


--Dave Waltermire and Paul Hoffman

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

[IPsec] Revised version of draft-ietf-ipsecme-rfc4307bis?

[Paul Hoffman]

Greetings. We had kinda hoped to have this one wrapped up before the 
IETF meeting, but that is now seeming less likely. Will the authors have 
a revised draft based on the recent comments soon?


--Paul Hoffman

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

Re: [IPsec] draft-fluhrer-qr-ikev2-01

[Paul Hoffman]

Your proposal of using heuristics from the SA payload instead of using a 
new registry seems like a bad tradeoff. It costs nothing to create a new 
registry. Further, the code that implementers need to write to use the 
new registered value is smaller *and more definitive* than the code 
needed to use your proposed heuristics.


As for your prediction that AES support might be removed from some CPUs 
in the future: that seems particularly unlikely. Basically, you never 
see CPU features removed from a product line. You sometimes see new 
families of low-end CPUs designed without all the features of current 
CPUs, but even that would not be a negative here. Further, if we need 
algorithms beyond AES in the future, it seems really likely that a 
competition for a replacement would favor one that could re-use the AES 
support in current chips.


I think a small registry for the (hopefully) few developers who care 
about QR a decade before anyone thinks there is any possibility of its 
use is a reasonable way forward.


--Paul Hoffman

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

[IPsec] Fwd: RFC 7670 on Generic Raw Public-Key Support for IKEv2

[Paul Hoffman]

Of interest here for those who followed the trajectory of this draft.

--Paul Hoffman

Forwarded message:


From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
Cc: drafts-update-...@iana.org, rfc-edi...@rfc-editor.org
Subject: RFC 7670 on Generic Raw Public-Key Support for IKEv2
Date: Wed, 20 Jan 2016 19:57:13 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.


 RFC 7670

 Title:  Generic Raw Public-Key Support for IKEv2
 Author: T. Kivinen, P. Wouters, H. Tschofenig
 Status: Standards Track
 Stream: IETF
 Date:   January 2016
 Mailbox:kivi...@iki.fi,
 pwout...@redhat.com,
 hannes.tschofe...@gmx.net
 Pages:  10
 Characters: 21350
 Updates:RFC 7296

 I-D Tag:draft-kivinen-ipsecme-oob-pubkey-14.txt

 URL:https://www.rfc-editor.org/info/rfc7670

 DOI:http://dx.doi.org/10.17487/RFC7670

The Internet Key Exchange Version 2 (IKEv2) protocol did have support
for raw public keys, but it only supported RSA raw public keys.  In
constrained environments, it is useful to make use of other types of
public keys, such as those based on Elliptic Curve Cryptography.
This document updates RFC 7296, adding support for other types of raw
public keys to IKEv2.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and 
suggestions

for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for 
the
standardization state and status of this protocol.  Distribution of 
this

memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
https://www.ietf.org/mailman/listinfo/ietf-announce
https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  
Unless

specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC




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

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Paul Hoffman]

This seems like a lot of guessing about what IoT devices want, 
specifically how they would handle tradeoffs of code complexity, CPU 
usage, and message size. If this WG offers an extension that is "for 
IoT", there will be a tendency to use it even in places where it might 
actually make things worse, so we really should be careful about 
deciding whether or not to pursue this.


How can we determine if the IoT community (as compared to IPsec 
developers) have a need for IKE compression?


--Paul Hoffman

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

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Paul Hoffman]

On 5 Jan 2016, at 2:58, Valery Smyslov wrote:


Hi Paul,
thank you for your comments.


This draft makes me nervous, as compression has been removed from
encryption specifications in the last few years.


As far as I know IPcomp isn't deprecated, is it?


No, but that's not what PaulW said.

If you mean TLS, then as far as I understand the compression-related 
attacks
on TLS rely on an ability for an attacker to insert specific data into 
the

encrypted (and compressed) stream that contains secret information
(e.g. password). I don't think it's relevant to IKE and it is 
discussed

in the Security Considerations section.


No one considered it relevant to TLS until researchers discovered the 
problems there. I think that's PaulW's point, and one that I agree with.





I find the security
considerations also weak on this. It basically says "if you think
compression might be security issue, don't use it". Which isn't 
helpful

at all to implementors.


Not really. It says that basically using compression in IKE should be 
safe.
However, IF you transfer secret information inside an IKE SA and IF 
some part of the IKE messages originates outside IKE,
then you are probably at risk. This could happen in case of EAP 
authentication using weak EAP methods that transfer passwords in 
clear. Note, that RFC 7296 strongly discourage

using such methods.

Note, that this is -00 draft and the security considerations
are currently very basic. What do you think should be added there?


That seems like a premature question. We haven't even decided if the 
idea of compressing IKE would give the benefits listed, whether the 
computational cost match the space benefits, and thus should be 
considered at all.


--Paul Hoffman

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

Re: [IPsec] RFC 4307bis

[Paul Hoffman]

On 9 Nov 2015, at 5:48, Yoav Nir wrote:


So I’ve merged the changes and submitted version -01 of the draft.

The stub paragraphs explaining the choices of algorithms are waiting 
to be filled. Please submit pull requests.


https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis


This is an invitation to the WG to contribute to to this draft. If you 
are already familiar with GitHub, submit pull requests as Yoav said. If 
you are not yet familiar with GitHub, feel free to send text to the 
mailing list, and one of the authors will quickly enter those for you in 
GitHub. That is, being able to use GitHub is *not* required for you to 
contribute text.


--Paul Hoffman

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

[IPsec] Fwd: Protocol Action: 'Generic Raw Public Key Support for IKEv2' to Proposed Standard (draft-kivinen-ipsecme-oob-pubkey-14.txt)

[Paul Hoffman]

Of interest to the WG

Forwarded message:


From: The IESG 
To: IETF-Announce 
Cc: kathleen.moriarty.i...@gmail.com, 
draft-kivinen-ipsecme-oob-pub...@ietf.org, The IESG , 
rfc-edi...@rfc-editor.org
Subject: Protocol Action: 'Generic Raw Public Key Support for IKEv2' 
to Proposed Standard (draft-kivinen-ipsecme-oob-pubkey-14.txt)

Date: Mon, 19 Oct 2015 10:10:17 -0700

The IESG has approved the following document:
- 'Generic Raw Public Key Support for IKEv2'
(draft-kivinen-ipsecme-oob-pubkey-14.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of 
an

IETF Working Group.

The IESG contact person is Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/





Technical Summary

The document extends IKEv2 with generic support for multiple
formats of raw public keys. This is expected to be used in IOT
settings and/or setups using DANE. Raw RSA keys were removed
from IKEv2 in its latest iteration (RFC 7296) in anticipation of
this document.

Working Group Summary

There was not enough IPsecME WG energy behind the draft,
so it never became a WG document. But the chairs do
support its publication as an AD-sponsored Standards Track
RFC so as not to lose an existing IKEv2 feature
(http://www.ietf.org/mail-archive/web/ipsec/current/msg08358.html).
The document updates RFC 7296.

Document Quality

This is a small extension to the protocol and
it was written by experienced IPsec implementors;
moreover, it re-enacts and extends functionality that's
been there for a while.  It has had several reviews by
experienced IPsecMe WG participants.

idnits should a reference to an obsoleted RFC, this is
correct as that is the appropriate reference.
-- Obsolete informational reference (is this intentional?): RFC 5996
  (Obsoleted by RFC 7296)

Personnel

The document shepherd is Yaron Sheffer.
The responsible Area Director is Kathleen Moriarty.



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

[IPsec] Scope of RFC4307 update

[Paul Hoffman]

On 12 Oct 2015, at 6:50, Tero Kivinen wrote:


I think AES-CCM is useful to have as SHOULD, as it is useful in
certain environments, but I do not want to mark it as MUST, as it is
not used in other environments.

On the other hand I assume that in practice those IoT implementations
are going to ignore this completely, and only implement the ciphers
they use, and they will not be implementing all mandatory to implement
ciphers, as they do not have space for them.


This is a reasonable observation about deployment of IPsec. In the 
pre-IoT past, we have had the same discussion, with some developers 
saying "I am supposed to write a system for a particular customer who 
has a particular set of algorithms that they have chosen for their 
application; why should that be considered out of compliance with the 
IETF?"


Thus, the WG needs to decide the desired scope of the requirements for 
this document are and put them into the document. Without that, we can 
endlessly debate about particular choices for "MUST" and even "SHOULD".


--Paul Hoffman

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

Re: [IPsec] RFC4307 update

[Paul Hoffman]

There seems to be interest in the WG in adopting this work, and it seems 
that draft-nir-ipsecme-rfc4307bis is a reasonable starting point 
(although there is already some good debate about the specifics).


Yoav and Tero: please resumbit this document as 
draft-ietf-ipsecme-rfc4307bis with any changes you have seen from the 
past few days that you want.


WG: we will make this an active topic of discussion (along with our 
other topic, closing out the DDoS document).


--Paul Hoffman

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

[IPsec] Fwd: Last Call: (Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)) to Proposed Standard

[Paul Hoffman]

Of possible interest to people here.

Responses to this should go to i...@ietf.org, not to the IPsecME WG 
mailing list.


Forwarded message:


From: The IESG 
To: IETF-Announce 
Subject: Last Call:  (Cloning 
IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)) to 
Proposed Standard

Date: Tue, 29 Sep 2015 14:46:46 -0700


The IESG has received a request from an individual submitter to 
consider

the following document:
- 'Cloning IKE SA in the Internet Key Exchange Protocol Version 2
(IKEv2)'
 as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2015-10-27. Exceptionally, comments may 
be

sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document considers a VPN End User establishing an IPsec SA with
a Security Gateway using the Internet Key Exchange Protocol Version 2
(IKEv2), where at least one of the peers has multiple interfaces or
where Security Gateway is a cluster with each node having its own IP
address.

With the current IKEv2 protocol, the outer IP addresses of the IPsec
SA are determined by those used by IKE SA.  As a result using
multiple interfaces requires to set up an IKE SA on each interface,
or on each path if both the VPN Client and the Security Gateway have
multiple interfaces.  Setting each IKE SA involves authentications
which might require multiple round trips as well as activity from the
VPN End User and thus would delay the VPN establishment.  In addition
multiple authentications unnecessarily increase the load on the VPN
client and the authentication infrastructure.

This document presents the solution that allows to clone IKEv2 SA,
where an additional SA is derived from an existing one.  The newly
created IKE SA is set without the IKEv2 authentication exchange.
This IKE SA can later be assigned to another interface or moved to
another cluster mode using MOBIKE protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[IPsec] Fwd: Last Call: (Minimal IKEv2) to Informational RFC

[Paul Hoffman]

Of interest to people in this WG. If you have comments on the draft, 
please send them to i...@ietf.org, not on this list.


--Paul Hoffman

Forwarded message:


From: The IESG <iesg-secret...@ietf.org>
To: IETF-Announce <ietf-annou...@ietf.org>
Cc: l...@ietf.org
Subject: Last Call:  (Minimal 
IKEv2) to Informational RFC

Date: Fri, 18 Sep 2015 07:27:27 -0700


The IESG has received a request from the Light-Weight Implementation
Guidance WG (lwig) to consider the following document:
- 'Minimal IKEv2'
 as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2015-10-02. Exceptionally, comments may 
be

sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document describes minimal version of the Internet Key Exchange
version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for
performing mutual authentication and establishing and maintaining
Security Associations (SAs). IKEv2 includes several optional
features, which are not needed in minimal implementations.  This
document describes what is required from the minimal implementation,
and also describes various optimizations which can be done.  The
protocol described here is compliant with full IKEv2 with exception
that this document describes mainly shared secret authentication
(IKEv2 requires support for certificate authentication in addition to
shared secret authentication).

This document does not update or modify RFC 7296, but provides more
compact description of the minimal version of the protocol.  If this
document and RFC 7296 conflicts then RFC 7296 is the authoritative
description.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[IPsec] Not meeting at IETF 94 in Yokohama, but continuing work here on the list

[Paul Hoffman]

Greetings again. Dave (our new co-chair) and I talked, and we don't see 
any need to meet at the upcoming meeting in Yokohama. Instead, we would 
love to see more discussion here about the DDoS document and discussion 
of possible new items.


--Paul Hoffman

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

Re: [IPsec] Leadership change

[Paul Hoffman]

On 6 Sep 2015, at 15:13, Yaron Sheffer wrote:


 Dear members of the IPsecME working group,

 After co-chairing the IPsecME working group for 7 years ever since 
its inception, I have decided that both I and the working group could 
benefit from a change. I have asked the security ADs to relieve me of 
this position, and I am glad they came up with a worthy co-chair to 
continue leading the group, alongside Paul.


 David Waltermire is with the National Institute of Standards and 
Technology where he works on standardizing approaches to automate 
security processes. He has been active at the IETF as a contributor in 
a number of working groups including SACM and MILE, and as Security 
Directorate member and reviewer. He has a background in systems, 
network, and software engineering. David is looking forward to working 
with the IPsecME working group in this new role.


 I am proud of what we have achieved in the working group and grateful 
to the small core of old timers and some not-so-old timers who have 
worked and are still working to maintain IPsec as a secure and 
relevant part of the Internet's infrastructure. I wish best of luck to 
Paul, Dave and the rest of the team.


 I intend to continue being active within the Security Directorate, so 
I'll be seeing you, guys and gals.


Thank you Yaron, and thank you David. The change in half the 
"leadership" of the WG should not affect our work too much, particularly 
at our lower level of work these days.


--Paul Hoffman

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

Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item

[Paul Hoffman]

There is general agreement that this document is a good starting point 
for a WG item. Yoav and Simon: please prepare this as a -00 draft, 
incorporating any of the relevant suggestions you got during the past 
few weeks.


--Paul Hoffman

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

[IPsec] Fwd: Last Call: draft-kivinen-ipsecme-oob-pubkey-11.txt (More Raw Public Keys for IKEv2) to Internet Standard

[Paul Hoffman]

Of interest to this WG. This is an individual submission, not a WG item, 
so comments should be sent as described in the announcement.


Forwarded message:


From: The IESG iesg-secret...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
Subject: Last Call: draft-kivinen-ipsecme-oob-pubkey-11.txt (More 
Raw Public Keys for IKEv2) to Internet Standard

Date: Wed, 26 Aug 2015 06:59:17 -0700


The IESG has received a request from an individual submitter to 
consider

the following document:
- 'More Raw Public Keys for IKEv2'
draft-kivinen-ipsecme-oob-pubkey-11.txt as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2015-09-23. Exceptionally, comments may 
be

sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


The Internet Key Exchange Version 2 (IKEv2) protocol currently only
supports raw RSA keys.  In constrained environments it is useful to
make use of other types of public keys, such as those based on
Elliptic Curve Cryptography.  This documents adds support for other
types of raw public keys to IKEv2.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item

[Paul Hoffman]

Greetings. There was some general interest in having a standard way to 
modern elliptic curves for ephemeral key exchange. Please respond in 
this thread whether or no you think this document is a good start on 
that work, and whether or not you think the WG should have this as a 
work item.


--Paul Hoffman

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

Re: [IPsec] PSK mode

[Paul Hoffman]

We should ask the NSA authors or their proxies before we do anything. 
Heck, maybe some NSA folks might even want to contribute to such an 
extension to IKEv2. We are in absolutely no rush, given how long it will 
be before serious researchers think there are practical quantum 
computers.


--Paul Hoffman

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

[IPsec] Work on the IPsec-related YANG documents

[Paul Hoffman]

Greetings. At the meeting in Prague, there was discussion of the 
IPsec-related YANG documents (draft-tran-ipecme-yang-ipsec, 
draft-wang-ipsecme-ipsec-yang, and draft-wang-ipsecme-ike-yang). Given 
the low level of understanding of YANG, it would be great if the authors 
of the three documents could either combine the documents or, failing 
that, agree on some wording for the WG about what each doc does and why 
they should exist in parallel. After that, the WG will be in a better 
position to think about whether we want to adopt them as WG items.


--Paul Hoffman

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

Re: [IPsec] [Editorial Errata Reported] RFC7296 (4387)

[Paul Hoffman]

Please accept this erratum and mark it has Held for document update.

--Paul Hoffman

 On Jun 4, 2015, at 5:08 AM, RFC Errata System rfc-edi...@rfc-editor.org 
 wrote:
 
 The following errata report has been submitted for RFC7296,
 Internet Key Exchange Protocol Version 2 (IKEv2).
 
 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=7296eid=4387
 
 --
 Type: Editorial
 Reported by: Yoav Nir ynir.i...@gmail.com
 
 Section: 3.7
 
 Original Text
 -
   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.
 
 Corrected Text
 --
   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_SA_INIT response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.
 
 Notes
 -
 IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time.
 
 Instructions:
 -
 This erratum is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 
 
 --
 RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
 --
 Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
 Publication Date: October 2014
 Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
 Category: INTERNET STANDARD
 Source  : IP Security Maintenance and Extensions
 Area: Security
 Stream  : IETF
 Verifying Party : IESG
 

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

Re: [IPsec] Question about PFS in IKEv2

[Paul Hoffman]

On May 28, 2015, at 7:21 AM, Paul Wouters p...@nohats.ca wrote:
 I had a long talk with Tero a few IETF's ago, and he was pretty
 convincing that it makes no sense whatsoever to have different
 phase 1/2 diffie hellman groups.

We actually talked about this during the design of IKEv2, but some people 
claimed we needed the separation because of different security needs for the 
two parts. In retrospect, we should have said even if that's true, it will 
cause problems. Here is an example of where it causes problems.

 Try to tell your webgui developers instead? :)

That seems to be the easiest way around this protocol mis-design.

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

Re: [IPsec] Barry Leiba's Discuss on draft-ietf-ipsecme-ikev2-null-auth-06: (with DISCUSS and COMMENT)

[Paul Hoffman]

On May 21, 2015, at 11:35 AM, Barry Leiba barryle...@computer.org wrote:
 First: Thanks, Paul, for a very informative and useful shepherd writeup.

...but then...

 I have no problem with the reference to Experimental RFC 5739, but I do
 have a problem with the downref not having been noted in the last call
 announcement, as required by RFC 3967 (BCP 97).  And I think the MUST in
 the last paragraph of Section 2.5 requires 5739 to be normative.  I hate
 to say this, but I think this requires a second last call on this
 document, which will really serve no one.  We really do need to do an
 update to BCP 97 to fix this, because it comes up all the time.

If the IESG wants to fix BCP 97, that's grand. Do note in the very informative 
and useful shepherd writeup, it says:

If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but 
it is more
appropriate as a normative reference.

I really meant that. Instead of wasting everyone's time with another IETF LC, 
please strongly consider changing the DISCUSS to yes, you need to move that 
reference to the Informational References section.

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

[IPsec] Publication requested for draft-ietf-ipsecme-chacha20-poly1305

[Paul Hoffman]

Greetings again. I have asked our AD to move this draft forwards for IETF Last 
Call. She will first review it and, if she has desired changes, will probably 
ask for them to be done before taking the draft to the IETF.

You can always see the current status of the document at 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ If you 
have a Datatracker account (which is free and easy to get), you can even 
subscribe to the Atom feed for the document (and any other draft).

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

[IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

[Paul Hoffman]

Greetings again. This begins the two-week WG Last Call on 
draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love 
to hear from people in either of two groups:

- Those who have already reviewed an earlier version of this draft. Please 
re-read the draft now, and let us know if it is perfect, or if there anything 
else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and 
Valery.

- Those who have *not* yet reviewed this draft, but want to help the IETF 
create good standards in this area. If you are an IPsec implementer, or know 
one at your organization, reviewing this draft and sending any comments to the 
list (even just seems fine or I liked it except this one thing) is useful 
to all of us.

It seems very likely that this new algorithm combination will appear in IKEv2 
and ESP soon, and having folks give a bit more review will help prevent 
whoopsies in the future.

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

[Paul Hoffman]

On Apr 25, 2015, at 2:27 AM, Yoav Nir ynir.i...@gmail.com wrote:
 With this I believe the document is ready for WGLC. I might want to add an 
 appendix with an example.

As chair and shepherd: we can't start the WG Last Call on this until we have 
examples*s*, given the changes in the -03 to add IKEv2. Please issue a -04 soon 
that has an appendix with one example of use in IKEv2, and another in IPsec.

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

Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt

[Paul Hoffman]

On Apr 1, 2015, at 6:57 PM, Kathleen Moriarty 
kathleen.moriarty.i...@gmail.com wrote:
 
 I went back to the email thread as I wanted to look at the consensus and 
 don't see it the way Paul does.  
 Here is the end of the thread:
 http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html
 
 It reads as confusion with the term updates and most being ok with going in 
 either direction, Paul against and Yaron more in favor.

Yes, exactly. So, it sounds like you see the consensus (and confusion) the way 
I do.

 Updates can update very specific text in a draft.  Since this just applies in 
 this special case, the updates text needs to be clearly worded to reflect 
 that or you copy in all the text that applies from the other draft.

Sounds fine. Who do you want to make that decision?

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

[IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

[Paul Hoffman]

Greetings. We have a new short draft in the WG, and would like to get reviews 
soon so we can move it into WG Last Call in about two weeks. We are not in a 
rush, but we also don't need to delay this too much.

We have five committed reviewers, but it would very useful if we had a few 
more. If you are an implementer, or just good at crypto, please consider doing 
a review now. If you have questions about how to review, feel free to reach out 
to me in personal mail.

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

[IPsec] Adopted as a WG work item: Chacha20-Poly1305

[Paul Hoffman]

Greetings again. At the Dallas meeting, we asked again about adoption of 
draft-nir-ipsecme-chacha20-poly1305. We got one more promise to review, so with 
at least five reviewers (Tero Kivinen, Paul Wouters, Jim Knowles, Valery 
Smyslov, and Michael Richardson), the chairs believe that this represents 
enough commitment for the WG to take on this work.

At the meeting, the WG seemed inclined to not want the material in Section 4 
for a variety of reasons. Yoav: please publish 
draft-ietf-ipsecme-chacha20-poly1305-00, minus Section 4, soon. We will update 
the charter to indicate this work item, with an expected time to IETF Last Call 
in May.

--Paul Hoffman and Yaron Sheffer

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

[IPsec] That last bunch of milestone changes

[Paul Hoffman]

Greetings. I deleted the old done milestones from the charter because no one 
will understand them any more. I also moved the expectation for IETF Last Call 
for null-auth to April, after Kathleen finishes her re-review.

I also put in a request to Kathleen to accept a milestone for Chacha20-Poly1305.

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

[IPsec] Slides for today's meeting

[Paul Hoffman]

...are posted. You can find them at 
https://datatracker.ietf.org/meeting/92/materials.html

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

Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

[Paul Hoffman]

On Feb 26, 2015, at 2:11 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 Greetings again. A few people have expressed interest in having 
 https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item 
 for IPsecME. If you want this as a WG document, and you are willing to review 
 drafts as they move through, please say so on this thread. If you are opposed 
 to this being a WG document, please say so (and say why). Thanks in advance.

This got very little interest, which surprised me. Without a few more people 
who will commit to review the document and offer comments, we can't really call 
it a WG work item. Is there really so little interest in new algorithms that 
are being adopted in other protocols?

If you are an IPsec implementer, it would be very useful to know whether or not 
you would support adding this algorithm to your implementation, and why.

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

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

[Paul Hoffman]

On Feb 27, 2015, at 9:05 AM, Kathleen Moriarty 
kathleen.moriarty.i...@gmail.com wrote:
 Section 2.4
 I see that this draft does not update RFC4301, but in reading this section, 
 should it?

It seems that people here would be happy either way. I propose that I add to 
the shepherd report:

Our AD asked whether or not this document should be labeled as Updates 4301 
based on the text in Section 2.4. There was a bit of discussion about whether 
or not this document fits the general definition of updates for another RFC, 
with no strong feelings either way. The WG defers this question to the IESG and 
will accept whatever the IESG wants for this.

If you object to this outcome, please say so before Monday. Thanks!

--Paul Hoffman


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

[Paul Hoffman]

On Feb 27, 2015, at 9:05 AM, Kathleen Moriarty 
kathleen.moriarty.i...@gmail.com wrote:
 
 Hello,
 
 Thank you very much to the authors and WG for your efforts on this draft!  
 It's good to see some of the OS work coming through as options in protocols.
 
 I just have a couple of comments/questions to clarify before we progress this 
 into IETF last call.
 
 The introduction is very well written, thank you for that.
 
 Section 2.4
 I see that this draft does not update RFC4301, but in reading this section, 
 should it?

That's a good question, and you can see it both ways.

- The draft says that the PAD processing in RFC 4301 needs to be updated for 
this draft, so the draft updates RFC 4301.

- Implementations of RFC 4301 that do not care about IKEv2 using this draft 
should not be updated, so this draft doesn't update 4301, just the 4301 
processing when using IKEv2 and this draft.

I tend toward the second interpretation, but am happy either way. What do 
others think?

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

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

[Paul Hoffman]

On Feb 27, 2015, at 1:58 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
 
 That's a good question, and you can see it both ways.
 
 - The draft says that the PAD processing in RFC 4301 needs to be updated for 
 this draft, so the draft updates RFC 4301.
 
 - Implementations of RFC 4301 that do not care about IKEv2 using this draft 
 should not be updated, so this draft doesn't update 4301, just the 4301 
 processing when using IKEv2 and this draft.
 
 I tend toward the second interpretation, but am happy either way. What do 
 others think?
 
 --Paul Hoffman
 
 I tend the other way, so we need an example or two. If you read the abstract 
 of RFC 6040, it says: On decapsulation, [RFC 6040] updates both RFC 3168 and 
 RFC 4301 to add new behaviours for previously unused combinations of inner 
 and outer headers. Which means that even though existing implementations are 
 not affected until they encounter these new message variants, we use 
 Updates because new implementations are expected to include the new 
 behavior.

That's an interesting example, one from outside our WG. Note, however, that RFC 
6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that it is 
the only one like this draft that says and you need to change your PAD 
processing for this new thing.

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

[IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305

[Paul Hoffman]

Greetings again. A few people have expressed interest in having 
https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item 
for IPsecME. If you want this as a WG document, and you are willing to review 
drafts as they move through, please say so on this thread. If you are opposed 
to this being a WG document, please say so (and say why). Thanks in advance.

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

[IPsec] Dallas meeting, likely in the last slot on Friday

[Paul Hoffman]

Greetings again. The preliminary schedule for the Dallas meeting has been 
published (https://datatracker.ietf.org/meeting/92/agenda.html) and IPsecME WG 
is in the last slot on Friday. If you haven't made your air reservations yet (I 
don't think we have any active participants who actually live in Dallas...), 
please don't assume you can leave the IETF early.

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

[IPsec] Close of second WG LC on draft-ietf-ipsecme-ikev2-null-auth

[Paul Hoffman]

Greetings again. We didn't get the level of review on the -03 document we hoped 
for, but feel that there was sufficient review and little enough push-back for 
us to say that the WG LC was successful. The authors have agreed to a bunch of 
changes, so we are now waiting for a -04. When that is published, we'll ask our 
AD to move the document to IETF Last Call.

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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Paul Hoffman]

On Feb 8, 2015, at 1:20 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 I think we've come a full circle. We now have a proposal that makes 
 proof-of-work more deterministic for each type of client (which I find very 
 useful). But the weaker clients will always lose, no matter what POW solution 
 we choose. This has been a problem with this proposal from day one and it's a 
 limitation that we as a group need to decide whether to accept or not. In a 
 world where some clients are 100X more powerful than others, IMHO this result 
 is something we have to live with.
 
 The only partial solution I see to this problem is to recommend using RFC 
 5723 session resumption, so that clients who have recently connected can 
 reconnect even in DoS situations.

Can a gateway sanely do session resumption when it is under DoS attack? That 
is, can the gateway safely allocate CPU resources to a purported session 
resumption?

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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Paul Hoffman]

On Feb 8, 2015, at 3:21 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 Yes, of course. It just needs to verify the integrity (MAC) of the received 
 ticket (as easy or easier than our proposed puzzle verification), and then 
 the rest of the exchange is lighter-weight than a typical IKE exchange. See 
 http://tools.ietf.org/html/rfc5723#section-4.3.2.

I knew the latter part, but I was more concerned about the former. As long as 
the verification is no harder than the proposed puzzles, then yes, resumption 
seems like a good addition. I wanted to be sure that it wasn't harder.

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

[IPsec] NUDGE: Re: Second WG Last call, or continuation of WG Last Call, on The NULL Authentication Method in IKEv2 Protocol draft-ietf-ipsecme-ikev2-null-auth

[Paul Hoffman]

[[ We really want to hear from everyone who reviewed the draft earlier, and 
would love to hear from at least a few new reviewers as well. These reviews are 
really a helpful way to participate in the WG! ]]

 On Jan 28, 2015, at 2:22 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 Greetings again. Please review draft-ietf-ipsecme-ikev2-null-auth-03.txt: it 
 is now our WG Last Call item.
 
 If you commented earlier, please look at 
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-03 and 
 see if your comments were reflected either by adoption, or by an adequate 
 comment on the issue you brought up.
 
 If you did not comment during the first part of the WG Last Call, but you 
 were intrigued by some of the comments in the last call, *please* read the 
 document and comment, even if just to say I have reviewed this document and 
 it is fine or I have now reviewed the document and here are a few things 
 that still deserve comment.
 
 If it looks like there is general agreement, we'll close out this 
 second/continued WG Last Call in two weeks, on February 11.
 
 --Paul Hoffman

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

[IPsec] Fwd: Last Call: draft-ietf-ippm-ipsec-08.txt (IKEv2-based Shared Secret Key for O/TWAMP) to Proposed Standard

[Paul Hoffman]

Some folks here might be interested in this draft, now in IETF Last Call. Do 
*not* send comments to the IPsecME mailing list; instead, follow the 
instructions in the last call below.

--Paul Hoffman

 The IESG has received a request from the IP Performance Metrics WG (ippm)
 to consider the following document:
 - 'IKEv2-based Shared Secret Key for O/TWAMP'
  draft-ietf-ippm-ipsec-08.txt as Proposed Standard
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 i...@ietf.org mailing lists by 2015-02-09. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
   The O/TWAMP security mechanism requires that both the client and
   server endpoints possess a shared secret.  Since the currently-
   standardized O/TWAMP security mechanism only supports a pre-shared
   key mode, large scale deployment of O/TWAMP is hindered
   significantly.  At the same time, recent trends point to wider IKEv2
   deployment which, in turn, calls for mechanisms and methods that
   enable tunnel end-users, as well as operators, to measure one-way and
   two- way network performance in a standardized manner.  This document
   describes the use of keys derived from an IKEv2 SA as the shared key
   in O/TWAMP.  If the shared key can be derived from the IKEv2 SA, O/
   TWAMP can support certificate-based key exchange, which would allow
   for more operational flexibility and efficiency.  The key derivation
   presented in this document can also facilitate automatic key
   management.
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 

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

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol draft-smyslov-ipsecme-ikev2-null-auth

[Paul Hoffman]

On Jan 9, 2015, at 12:28 PM, Paul Wouters p...@nohats.ca wrote:
 
 On Fri, 9 Jan 2015, Paul Hoffman wrote:
 
 Greetings again. The chairs apologize for the log delay on this, but it is 
 time to move on this document. This begins the two-week WG Last Call on 
 https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth. The 
 purpose of the WG Last Call is to get as many people as possible to read the 
 document carefully, looking for any technical or editorial issues that 
 should be discussed before the document is sent to the IETF.
 
 Paul meant:
 
 https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth

Blarg, I certainly did. I have no idea how that happened in my tool chain.

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

Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd

[Paul Hoffman]

Please note that the conclusion of this survey was that the WG was not going to 
adopt the document. The chairs asked that the authors set up their own 
discussion fora if they want to continue discussion. Announcing new versions of 
non-WG drafts on this list is fine, but trying to keep the discussion alive 
here is not.

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

[IPsec] Calls for adoption: wrap-up

[Paul Hoffman]

Greetings. A few weeks ago, we started summaries for adoption by the WG of two 
drafts: draft-nagayama-ipsecme-ipsec-with-qkd and 
draft-mglt-ipsecme-clone-ike-sa. This message concludes that there is not 
sufficient interest in the WG (that is, enough people who will actively 
contribute to the draft progression) for either draft to be advance 
successfully.

Both drafts had some interest from people other than the authors, but it seemed 
like a fair amount of that was defensive; that is, those people were willing to 
work on the document, but mostly to prevent bad design, not because they 
supported the use case. Given that, if the authors of either decide to pursue 
publication, it would be great if they reached out to all the people on the 
list who expressed opinions and try to incorporate those before moving 
forwards. Notes about new versions of these drafts (and other non-WG drafts) 
are still welcome on the list as long as they do not disrupt the ongoing WG 
work.

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

[IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa

[Paul Hoffman]

chair hats on

Greetings again. The Clone IKE SA proposal tries to optimize IKE SA setup in 
cases where VPN gateways have multiple interfaces and want to establish 
different SAs on the different interfaces without having to repeat the IKE 
authentication. Instead, they could clone a single IKE SA multiple times, and 
then move it to different interfaces using MOBIKE.

If you agree with the need to standardize this usage, and believe that 
draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for that 
standardization, and are willing to review and contribute text to the document 
if it is adopted by the WG, please say so on the list. This WG has a history of 
adopting documents but then not having enough reviewers for us to feel 
confident that we are making a good standard, so we need to see a reasonable 
number of actively interested people before we adopt the document. If it is not 
adopted, the authors can ask for it to be published as an RFC through 
individual submission or by the Independent Submissions Editor.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd

[Paul Hoffman]

chair hats on

Greetings again. There is a small emerging industry of crypto solutions that 
transmit keys using Quantum Key Distribution (QKD), and then use those keys for 
classical high-speed encryption. Several such solutions are using IKE, and 
there is a perceived need to standardize this usage. If so, that 
standardization should be done in this Working Group.

If you agree with the need to standardize this usage, and believe that 
draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for 
that standardization, and are willing to review and contribute text to the 
document if it is adopted by the WG, please say so on the list. This WG has a 
history of adopting documents but then not having enough reviewers for us to 
feel confident that we are making a good standard, so we need to see a 
reasonable number of actively interested people before we adopt the document. 
If it is not adopted, the authors can ask for it to be published as an RFC 
through individual submission or by the Independent Submissions Editor.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Call for adoption: Client Puzzles

[Paul Hoffman]

The call for adoption has had mixed results. On the one hand, there is lots of 
interest in working on the problem. On the other, there is a fair amount of 
trepidation about whether making things significantly harder for botnets is 
attainable with the current state of botnets and puzzles is achievable; if it 
is not, maybe we shouldn't add another extensions that could make IKEv2 more 
fragile.

Given the interest, though, we will adopt this as a WG item. However, given the 
trepidation, we might purposely abandon the work later if we think we are not 
able to make a useful mechanism.

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

Re: [IPsec] Charter update

[Paul Hoffman]

[[ Another nudge to keep this thread going. If you care about the charter, 
please comment. ]]

On Jul 19, 2014, at 9:48 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:

 IPsec folks,
 
 Our existing charter (http://tools.ietf.org/wg/ipsecme/charters) is badly out 
 of date. Below is a proposed charter revision. Please review and comment on 
 the list. We might also discuss the new charter in the face-to-face next week.
 
 Thanks,
 Paul and Yaron
 
 
 IP Security Maintenance and Extensions (ipsecme)
 
 
  Charter
 
  Current Status: Active
 
  Chairs:
  Paul E. Hoffman paul.hoff...@vpnc.org
  Yaron Sheffer yaronf.i...@gmail.com
 
  Security Area Directors:
  Stephen Farrell stephen.farr...@cs.tcd.ie
  Kathleen Moriarty kathleen.moriarty.i...@gmail.com
 
  Security Area Advisor:
  Kathleen Moriarty kathleen.moriarty.i...@gmail.com
 
  Mailing Lists:
  General Discussion: ipsec@ietf.org
  To Subscribe:   https://www.ietf.org/mailman/listinfo/ipsec
  Archive:http://www.ietf.org/mail-archive/web/ipsec/
 
 Description of Working Group:
 
The IPsec suite of protocols includes IKEv1 (RFC 2409
and associated RFCs), IKEv2 (RFC 5996), and the IPsec
security architecture (RFC 4301). IPsec is widely
deployed in VPN gateways, VPN remote access clients,
and as a substrate for host-to-host, host-to-network,
and network-to-network security.
   
The IPsec Maintenance and Extensions Working Group
continues the work of the earlier IPsec Working Group
which was concluded in 2005. Its purpose is to maintain
the IPsec standard and to facilitate discussion of
clarifications, improvements, and extensions to IPsec,
mostly to IKEv2. The working group also serves as a
focus point for other IETF Working Groups who use IPsec
in their own protocols.
   
The current work items include:
   
Recently discovered incorrect behavior of ISPs poses a
challenge to IKE, whose UDP messages (especially #3 and #4)
sometimes get fragmented at the IP level and then dropped
by these ISPs. There is interest in solving this issue by
allowing transport of IKE over TCP; this is currently
implemented by some vendors. The group will standardize such
a solution.
   
The WG will review and revise the list of mandatory-to-
implement algorithms for ESP and AH based on five years of experience 
with newer algorithms and cryptographic modes.
   
The WG will revise the IKEv2 specification with a small number
of mandatory tests required for the secure operation of IKEv2
when using elliptic curve cryptography. This work will be based
on draft-sheffer-ipsecme-dh-checks.
 
IKEv2 has had many interoperable implementations and can now be considered
a mature protocol. The WG will republish the protocol as an Internet 
 Standard.
 
At the time of writing, all the above are in late stages of the IETF 
 process.
Therefore, the WG will go into low-power mode: it will remain active as a 
 focal point
for the IPsec community. But it will only take on new work items if a 
 strong community
interest can be seen.
 
This charter will expire in July 2015 (12 months from approval).
If the charter is not updated before that time, the WG will be
closed and any remaining documents revert back to individual
Internet-Drafts.
   
 
 Goals and Milestones:
 
   Done - IETF Last Call on large scale VPN use cases and requirements
   Done - IETF last call on IKE fragmentation solution
   Done - IETF last call on new mandatory-to-implement algorithms
 
   [No current milestones]
 ___
 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] Agenda for Toronto meeting

[Paul Hoffman]

Now posted: http://www.ietf.org/proceedings/90/agenda/agenda-90-ipsecme

--Paul Hoffman

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

[IPsec] Our meeting in Toronto

[Paul Hoffman]

Greetings again. The Toronto meeting is a few weeks away. The IPsecME WG is 
scheduled in the last slot of the week, Friday late morning: 
https://datatracker.ietf.org/meeting/90/agenda.html This gives us 1.5 hours.

Currently, I have the following non-WG documents on the WG agenda:
draft-smyslov-ipsecme-ikev2-null-auth
draft-mglt-ipsecme-mobikev2
draft-nir-ipsecme-puzzles
Am I missing any? Again, the criterion is that the documents not have been 
presented at an earlier IETF meeting, and that there must have already been 
some discussion on the list before the meeting.

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

[IPsec] Important: One-week WG review of newest draft-ietf-ipsecme-ikev2-fragmentation

[Paul Hoffman]

Greetings again. The IESG had a lot of questions and concerns about 
draft-ietf-ipsecme-ikev2-fragmentation during their review. Valery made a large 
number of changes to the text to help clarify the language, particularly around 
PMTU. The current draft and all the IESG comments can be found at:

https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/

Before we take Valery's changes back to the IESG, we want to be sure that the 
WG agrees on all the text and, if not, makes more clarifications. Please send 
any comments to the list by Tuesday, June 17.

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

Re: [IPsec] Any reason to meet in Toronto?

[Paul Hoffman]

On Jun 4, 2014, at 6:41 AM, Paul Wouters p...@nohats.ca wrote:

 While
 presenting it would be a one slide presentation, it would be good
 to get this unstuck and have people review it, as I'm waiting on the
 IANA registry code point for this :/

The Toronto meeting is more than six weeks away. If someone wants a document 
finished before then, please don't wait: discuss it on the list and move it 
forwards. There is nothing magic about being able to say I made a presentation 
at a meeting, particularly in this WG.

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

Re: [IPsec] Any reason to meet in Toronto?

[Paul Hoffman]

On Jun 3, 2014, at 12:19 PM, Yoav Nir ynir.i...@gmail.com wrote:

 Well, there’s my puzzles draft ([1]).

If you want to present it, sure.

 And we could argue some more about dynamic VPN (and the dropping thereof).

Nope.

 In fact, just stick an “open mic” part on the agenda, and such an argument is 
 sure to come.

Doing that on list would be possibly be more useful than waiting for the 
meeting. Or not.

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

[IPsec] Any reason to meet in Toronto?

[Paul Hoffman]

Greetings again. The WG currently has no documents under active discussion. 
Given that, Yaron and I thought that we don't *have* to meet in Toronto. 
However, at our meetings, we try to let people with IPsec-related drafts to 
make initial presentations. We could have a short meeting to do that in Toronto 
if there are a few documents that (a) have not been presented at previous 
IPsecME WG meetings and (b) are related to IPsec.

Thoughts?

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

[IPsec] Short re-run of WG LC: draft-kivinen-ipsecme-signature-auth-06.txt

[Paul Hoffman]

Many thanks to Joel Snyder for helping clarify lots of the wording in this 
document. It feels much cleaner to me. I'm not 100% convinced that technical 
changes slipped in during those extensive changes. So, I'd really like the WG 
to review the latest draft. If you have any new concerns at all, please send 
them to the mailing list before Wednesday May 14.

--Paul Hoffman


On May 7, 2014, at 5:50 AM, 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 
 Working Group of the IETF.
 
Title   : Signature Authentication in IKEv2
Authors : Tero Kivinen
  Joel Snyder
   Filename: draft-kivinen-ipsecme-signature-auth-06.txt
   Pages   : 17
   Date: 2014-05-07
 
 Abstract:
   The Internet Key Exchange Version 2 (IKEv2) protocol has limited
   support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
   The current version only includes support for three Elliptic Curve
   groups, and there is a fixed hash algorithm tied to each group.  This
   document generalizes IKEv2 signature support to allow any signature
   method supported by the PKIX and also adds signature hash algorithm
   negotiation.  This is a generic mechanism, and is not limited to
   ECDSA, but can also be used with other signature algorithms.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-06
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-signature-auth-06

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

Re: [IPsec] Seeking a volunteer to help move draft-kivinen-ipsecme-signature-auth with a copy edit

[Paul Hoffman]

Thanks for the many offers! I accepted one and he has already finished the task.

Again, this WG works best when there are lots of volunteers for doing things 
like reviews. Please keep this in mind when Yaron and I ask for volunteers in 
the future.

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

[IPsec] Seeking a volunteer to help move draft-kivinen-ipsecme-signature-auth with a copy edit

[Paul Hoffman]

Greetings again. We finished WG Last Call on 
draft-kivinen-ipsecme-signature-auth a while ago, but as our Area Director was 
reading it, she found some wording problems that were significant enough for 
her to want to hold it back for an editing pass. For example, there are places 
where singular and plurals are mixed up, or words are repeated in a sentence, 
in a way that someone doing an IETF Last Call might be confused.

The chairs are seeking a volunteer to copy edit the draft. This could be a 
great way for someone who wants to participate in the WG to contribute to our 
work without having to write a protocol or even code one up. Part of the work 
of the IETF is development of protocols, but another part is moving those 
protocols forwards in a way where everyone can use them; this request falls 
into the latter category.

Please reply to me off-list if you're willing to help the WG and take this on. 
I suspect this task would take at most only a few hours.

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

[Paul Hoffman]

Yaron obviously gets to call consensus on this.

On Apr 2, 2014, at 12:33 PM, RJ Atkinson rja.li...@gmail.com wrote:

 On 02  Apr 2014, at 13:25 , Paul Hoffman wrote:
 That was certainly not the intention.
 
 OK.
 
 [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
 with forwarding silicon that could parse AH and any other IPv4/IPv6
 options - at wire-speed for 10 Gbps interfaces - 10 years ago.  I am
 aware of 2 other very widely deployed implementations with the same
 ability to parse past AH to read TCP/UDP ports and apply ACLs at
 wire-speed.  So this is a widely deployed capability, rather than
 theory. :-]
 
 That's not an important note for this discussion, ...
 
 Ah, but it is important, because it talks about deployed reality,
 and many many users and implementers DO care about the ability 
 to apply ACLs.

You have not said why that is important for *this discussion* which is about 
the document on cryptographic algorithm implementation requirements. If an 
implementer cares about what your previous employer shipped and so on, they are 
welcome to implement AH; nothing in the wording of this document says otherwise.

 which is about what the IPsec community
 has expressed as a general preference.
 
 You are mis-characterising the VPN community (e.g. VPNC)
 as being the whole IPsec community.  

No, I'm talking about what has been said in the WG on this topic to date. This 
WG is the best representation of the IPsec community that we have.

 This I-D supposedly
 is NOT a VPN-focused draft, but instead claims to address 
 the whole audience of IPsec implementers, users, and usages.

Correct. If it was VPN focused, it would probably not even mention AH.

 You feel that preference is wrong, and you have stated
 that in earlier WG discussions.
 
 No.  

Actually, yes. Looking in the archives, I see you stating it in a few different 
threads.

 That is not what I believe or feel, NOR is the quote 
 a correct summary what I have expressed in past discussions.
 Instead, that is a mis-apprehension of what I have said.
 
 In fact, I don't think that the preference for ESP with an integrated
 transform is wrong or bad - for VPN uses.  Indeed, there are 
 well-understood and broadly agreed reasons why - for VPNs -
 ESP with an integrated transform is preferable.  Further, we all 
 agree and understand that VPN is the most widely deployed use case.  
 However, it is not the only deployed IPsec use case.  

That is what you have said on earlier threads, so I'm not sure how you could 
say that what I said is wrong.

 A general IPsec Requirements document ought to be addressing
 all deployed use cases, and ought not be limited to VPN uses.

If that's what the WG wants, great. In me reading the list as a document 
author, I don't see people agreeing with that.

 We owe it to readers to be crisp, clear, complete, and accurate 
 with the text in this draft.
 
 Yes, but:
 
 Candidate new text:
 
   When no IPv4 options or IPv6 optional headers are present, and 
   in environments without concerns about attacks based on option
   insertion (e.g. inserting a source routing header to facilitate
   pervasive eavesdropping), the IPsec community generally prefers
   ESP with NULL encryption over AH.  However, some protocols
   require AH.  Also, AH always protects all IPv4 options and IPv6
   optional headers, while ESP NULL is unable to protect any IPv4
   options or to protect IPv6 options that are seen  processed by
   intermediate systems (e.g. routers, security gateways, other
   middle-boxes).  Some IP-layer options, for example IPSO [RFC-1108]
   and CALIPSO [RFC-5570], today are deployed in some environments 
   while using AH to provide both integrity protection  authentication.
 
   Further, deployed routers from multiple vendors are able to parse
   past an AH header in order to read upper-layer protocol
   (e.g. TCP) header information (e.g. to apply port-based router
   ACLs) at wire-speed.  By contrast, there is no 100% reliable way
   to parse past an ESP header, although some ESP header parsing
   heuristics have been documented [RFC-5879] that work in some cases.
 
 That is neither crisp nor clear; it is more complete;
 
 it is inaccurate about the parameters that the IPsec community cares about.
 
 Precisely HOW is it inaccurate ?

There has been no one on the list other than you who has given those parameters 
for the statement the IPsec community generally prefers...

 I believe that everything in my text is accurate.
 If there is something inaccurate, please do say precisely what.

Done so, now twice.

 The proposed text comes off as an advertisement for AH, but that's exactly
 the opposite direction that the WG has been leaning for this document.
 
 I'm open to having you or others propose some alternative text, provided
 that text makes clear that ESP can't protect IP options in transit, 
 while AH can.  This difference in the provided security properties is
 entirely factual

Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

[Paul Hoffman]

On Apr 1, 2014, at 1:46 PM, Paul Wouters p...@nohats.ca wrote:

 On Mon, 31 Mar 2014, internet-dra...@ietf.org wrote:
 
 Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-03
 
 So one of the changes is:
 
 - SHOULD+ AES-GCM [RFC4106]
 + SHOULD+ AES-GCM with a 16 octet ICV [RFC4106]
 
 While I'm happy with that change (I argued for it to not using the
 truncated ICV versions), the document now makes no statement about those
 other ICV variants. RFC 4106 states:
 
   The ICV consists solely of the AES-GCM Authentication Tag.
   Implementations MUST support a full-length 16-octet ICV, and MAY
   support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
 
 Me personally, and one of the authors of 4106 (John Viega) would like to
 see those other ICV's moved to SHOULD NOT. Since these are MAY in 4106,
 and not mentioned in this draft, they would remain MAY.

That was the intention: MAY. SHOULD NOT somewhat indicates a belief that the 
crypto has degraded, and that is not the case here.


 I also wonder about:
 
   It is NOT RECOMMENDED to use ESP with NULL authentication
in conjunction with AH
 
 Why do we now say NOT RECOMMENDED instead of continuing to talk in
 RFC4835 terms? eg:
 
   ESP with NULL authentication MUST NOT be used in conjunction
   with AH.
 
 If we go through the effort of stating such deployments are insecure,
 which we do in the next line, we might as well clearly tell implementors
 not to do this. not recommended does not say don't do this.

RFC 4835 does not say that ESP with NULL MUST NOT be used with AH. It waffles.

 language nits:
 
 As a non-native english speaker, efficacy was not clear to me, and
 almost read as efficiency. So I would change undermines the efficacy
 of encryption. Maybe something like just undermines the trustworthiness
 the encryption (although that sounds a bit Colbert like :)
 
 s/perfers/prefers

I'll make these changes in -04. It turns out I need to do a rev anyway because 
I forgot to list the new DES MUST NOT in the changes summary.

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

[IPsec] Fwd: [89all] London Meeting Survey

[Paul Hoffman]

If you were in London but didn't see this, please consider filling in the 
survey. There are also questions for people who weren't in London but 
participated remotely. The IAOC pays a lot of attention to the results of these 
surveys.

Begin forwarded message:

 From: Ray Pelletier rpellet...@isoc.org
 Subject: [89all] London Meeting Survey
 Date: March 20, 2014 at 1:58:49 PM PDT
 To: 89...@ietf.org
 
 All;
 
 This is a short and anonymous survey about your IETF meeting experience 
 generally and specifically your experience at IETF 89 in London. It will be 
 used to make improvements at future meetings where needed (and possible). 
 Feedback on the survey itself is welcome.
 
 https://www.surveymonkey.com/s/XG5S9VC
 
 Thanks for attending the meeting and your participation in this survey.
 
 Ray

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

Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01

[Paul Hoffman]

On Mar 5, 2014, at 11:07 PM, Tero Kivinen kivi...@iki.fi wrote:

 In section 2 it says:
 
   Note that IKEv2 and IPsec session do not need to be on the same node
   as IKEv2 and IPsec context are different.
 
 This is not so easy. The RFC5996 says:
 
 --
 2.4.  State Synchronization and Connection Timeouts
 ...
   An implementation needs to stop sending over any SA if
   some failure prevents it from receiving on all of the associated SAs.
   If a system creates Child SAs that can fail independently from one
   another without the associated IKE SA being able to send a delete
   message, then the system MUST negotiate such Child SAs using separate
   IKE SAs.
 --
 
 I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using
 same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA
 are on separate nodes, that do set up new kind of requirements for
 those nodes. I.e. if one node having IPsec SAs fails, the node having
 IKE SA needs to detect this, and send delete notification for each
 IPsec SA that were in that node. Also if the node having the IKE SA
 will fail, then all the IPsec SAs associated with that IKE SA, must
 stop sending, i.e. they needs to be destroyed.  

Tero's comment nails the concern I had when reading the document. IKEv2 ties 
Child SAs to their parent SA, and using the context of one without the other 
seems dangerous.

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

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

[Paul Hoffman]

On Mar 3, 2014, at 12:02 PM, Valery Smyslov sva...@gmail.com wrote:

 The draft lists the following trasforms based on AES cipher:
 
 AES-GCM
 AES-CCM
 AES-CTR
 AES-128-CBC
 AES-GMAC
 AES-XCBC-MAC-96
 
 All these transforms, except for AES-XCBC-MAC-96,
 allows to be used with different key lengths - 128, 192 and 256 bits.
 It looks strange to me that, unlike the others, AES-128-CBC
 has key length explicitely specified in the draft. Why it differs in
 this respect from the others? What about AES-192-CBC and
 AES-256-CBC - are they also MUST or MAY? Or even MUST NOT? :-)
 
 I think the draft should either:
 - remove explicit key length from AES-128-CBC and make it just AES-CBC
 - add explicit key length to all other AES-based transforms (except for 
 AES-XCBC-MAC-96)
 - leave things as is, but explain why AES-CBC differs in this respect from 
 the others

The next draft changes AES-128-CBC to AES-CBC, and says:

In the following sections, all AES modes are for 128-bit AES. 192-bit AES
MAY be supported for those modes, but the requirements here are for 128-bit AES.

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

Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts

[Paul Hoffman]

On Mar 8, 2014, at 1:08 PM, Black, David david.bl...@emc.com wrote:

 What about 256-bit AES keys?  They should also be a MAY.

Good catch.

--Paul Hoffman

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

[IPsec] SHOULD NOT in draft-ietf-ipsecme-esp-ah-reqts

[Paul Hoffman]

On Mar 8, 2014, at 1:37 PM, Black, David david.bl...@emc.com wrote:

   - SHOULD NOT- is a better keyword than SHOULD NOT+

How do others feel about this? It feels like a bit of a bikeshed, but we may as 
well be as helpful as possible.

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

[IPsec] ICV sizes

[Paul Hoffman]

On Mar 8, 2014, at 1:37 PM, Black, David david.bl...@emc.com wrote:

 I have no strong opinion on ICV size for GCM and GMAC, but I am interested
 in the outcome as an author of the Block Storage IPsec profile update
 (draft-ietf-storm-ipsec-ips-update-04).  That draft does not currently
 express requirements on ICV length.  That draft's in Authors 48 hours at
 the moment as part of the entire iSCSI draft cluster, and it could be held
 to apply the ICV length outcome determined here if that were deemed important.

Making technical changes to a document in AUTH48 is a really bad idea. If you 
were not specific enough when writing the draft, you should probably just leave 
it alone.

--Paul Hoffman

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

Re: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-fragmentation-05.txt (IKEv2 Fragmentation) to Proposed Standard

[Paul Hoffman]

A process note: even though this is IETF Last Call, WG members are still 
encouraged to comment on the draft. That is, just because we already finished 
WG LC, that doesn't mean you should not read the draft again and make any 
helpful comments on i...@ietf.org or to the IESG.

--Paul Hoffman

On Feb 26, 2014, at 3:42 AM, The IESG iesg-secret...@ietf.org wrote:

 
 The IESG has received a request from the IP Security Maintenance and
 Extensions WG (ipsecme) to consider the following document:
 - 'IKEv2 Fragmentation'
  draft-ietf-ipsecme-ikev2-fragmentation-05.txt as Proposed Standard
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 i...@ietf.org mailing lists by 2014-03-12. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't allow IP fragments to pass through.
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 
 ___
 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] Getting slides for the upcoming meeting

[Paul Hoffman]

Greetings. We are having our face-to-face meeting in a week; 
https://datatracker.ietf.org/meeting/89/agenda/ipsecme/

So far, I have received no slides. I would like to.

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

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

[Paul Hoffman]

On Feb 25, 2014, at 3:09 PM, Paul Wouters p...@cypherpunks.ca wrote:

 On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
 
  Hi, this is to start a 2-week working group last call on the revised 
 Algorithm Implementation Requirements
  document, ending March 11. The draft is at: 
 http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We
  should have last called the draft a while ago, and I apologize for the 
 delay.
 
 Section 2.2:
 
 It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old
 crypto export restrictions? While I think NULL ESP is a good debugging
 tool, and a good replacement for AH in general, I don't think this is
 really a MUST item (unless you would actually advise people to migrate
 from AH to ESP NULL, in which case I'll cheer on this MUST)

It is for systems that don't implement AH. We should probably say this 
explicitly in section 3.

 Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane
 modern IKE daemon that allows 1DES (or modp768)

The WG has never voiced a MUST NOT for this before. I'm fine with making that 
change if no one objects.

 Section 2.3:
 
 This does not list anything with md5. Is there another RFC that already
 discourages this use for IPsec? If so, can it be references in this
 document. If not, shouldn't we talk about an HMAC-MD5 downgrade to
 SHOULD NOT+ ?

HMAC-MD5 still gives 128 bits of strength, which in fact is more than the 
MUST-level HMAC-SHA1-96. It was a MAY in 4835; by not listing it here, it is 
still MAY.

 [ Turns out that document is RFC 4835, but only mentioned at the
  end. Should this document not Obsolete: 4835? ]

This document should indeed obsolete 4835. Good catch.

 Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can
 think of for this is when we use a combined mode algorithm like AES-GCM.
 But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be
 SHOULD+ as well?

That's covered in Section 3. The tables are the raw list of requirements; their 
use is covered in Section 3.

 Section 2.5:
 
 I would put 2.5 as the introduction paragraph to 2.1.

Bike shed.

 I'm also confused
 why the entries in 2.2 and 2.3 do not appear in the 2.5 summary.

I just checked, and I think the table of changes is correct. Which do you think 
is missing?

 Should
 they be added with - in the Old Requirement, and their listing in the
 New Requirement?

No, this is a table of differences.

 Section 3 states:
 
   If authentication on the IP header is needed in conjunction with
   confidentiality of higher-layer data, then AH SHOULD be used in
   addition to the transforms recommended above.
 
 How does AH protect the confidentiality of higher-layer data ?

It does not, of course. I think this sentence was trying to be about if the 
higher-layer data already has its own confidentiality, then you can add AH. I 
think the sentence should be removed because it assumes that the device adding 
authentication knows whether or not the higher-layer service is using 
confidentiality correctly, and it can't know this.

 Seciont 4:
 
 The text about The Triple Data Encryption Standard (TDES) is obsolete
 appears twice and could be consolidated?

The second one is about DES. :-)

 Section 4.3:
 
 This section is the only section that mentions MD5 and SHA1. Perhaps it
 should summarize or refer to RFC 4835?

I think it is better to make this document obsolete 4835 and keep the negative 
text.

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

[IPsec] Our London agenda is filling up

[Paul Hoffman]

Greetings again. I have updated the agenda at 
https://datatracker.ietf.org/meeting/89/agenda/ipsecme/ to reflect recent 
requests.

Yaron and I would like to see active discussion on the mailing list of any of 
the drafts that are listed in the agenda. The face-to-face time in London 
should be focused on dealing with issues, not making introductory presentations.

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

[IPsec] Proposed agenda for London

[Paul Hoffman]

http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme

Proposals for changes are welcome. Note that some of the people listed as 
speaking have not yet been asked, but we hope they agree. :-)

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

Re: [IPsec] ADVPN Use Cases proposals

[Paul Hoffman]

On Dec 11, 2013, at 10:45 AM, Brian Weis b...@cisco.com wrote:

 The ADVPN proposals currently state how they believe they meet the 
 requirements of RFC 7018, but not how well they match each of the actual use 
 cases. The minutes of the Vancouver meeting record that Steve Hanna suggested 
 it might be helpful to have each of proposal teams describe in more detail 
 how their proposal would address the 3 use cases. There was some agreement 
 (including from Sean) that this would be valuable information for the 
 protocol starting point selection process.
 
 Yaron  Paul, do you agree and if so can you give the authors some guidance 
 on what you think would be most useful? E.g., have each proposal document how 
 RFC7018's three use cases meet the 16+ RFC7108 requirements, or something 
 else?

That could indeed be useful for the non-authors who are considering 
contributing to the current discussion. However, it feels like the authors have 
not been very interested in updating their docs when clarification has been 
asked for and given on the mailing list, so I am hesitant to stop the current 
discussion in order to wait for those. Personally, I don't think an author 
sending a message to the mailing list with their view of the matches; that 
feels like more advertising for the current round of questions. Yaron may have 
a different view.

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

Re: [IPsec] routing protocols for ADVPN

[Paul Hoffman]

hat on

On Dec 8, 2013, at 3:00 PM, Frederic Detienne (fdetienn) fdeti...@cisco.com 
wrote:

 Now if it helps clarifying our position:

Stop this, please. It is rude to hijack a thread that is specifically for 
non-authors. If you want to clarify a position, simply update the draft.

To everyone else who is not an author of a draft: please see the first message 
in the thread 
http://www.ietf.org/mail-archive/web/ipsec/current/msg08861.html and consider 
voicing your opinion, hopefully without debate from document authors.

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

[IPsec] Fwd: Last Call: draft-ietf-opsec-vpn-leakages-02.txt (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC

[Paul Hoffman]

This IETF-wide last call should be of definite interest to many developers in 
this WG. Please send any review comments to the addresses below, not to the 
IPsecME WG mailing list.

--Paul Hoffman

Begin forwarded message:

 From: The IESG iesg-secret...@ietf.org
 Subject: Last Call: draft-ietf-opsec-vpn-leakages-02.txt (Virtual Private 
 Network (VPN) traffic leakages in dual-stack hosts/ networks) to 
 Informational RFC
 Date: December 2, 2013 at 4:53:48 AM PST
 To: IETF-Announce ietf-annou...@ietf.org
 Cc: op...@ietf.org
 Reply-To: i...@ietf.org
 
 
 The IESG has received a request from the Operational Security
 Capabilities for IP Network Infrastructure WG (opsec) to consider the
 following document:
 - 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/
  networks'
 draft-ietf-opsec-vpn-leakages-02.txt as Informational RFC
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 i...@ietf.org mailing lists by 2013-12-16. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
  The subtle way in which the IPv6 and IPv4 protocols co-exist in
  typical networks, together with the lack of proper IPv6 support in
  popular Virtual Private Network (VPN) products, may inadvertently
  result in VPN traffic leaks.  That is, traffic meant to be
  transferred over a VPN connection may leak out of such connection and
  be transferred in the clear from the local network to the final
  destination.  This document discusses some scenarios in which such
  VPN leakages may occur, either as a side effect of enabling IPv6 on a
  local network, or as a result of a deliberate attack from a local
  attacker.  Additionally, it discusses possible mitigations for the
  aforementioned issue.
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 

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

Re: [IPsec] Other documents to upgrade to internet standard

[Paul Hoffman]

On Nov 7, 2013, at 9:52 AM, Yoav Nir y...@checkpoint.com wrote:

 On Nov 7, 2013, at 9:43 AM, Tero Kivinen kivi...@iki.fi
 wrote:
 
 So have you actually seen anyone actually using those groups between
 different vendors?
 
 Perhaps we should have an interop event. How about the Sunday of the London 
 meeting?

Tero was probably talking about using them in the wild, not at an interop 
event. We have messages saying that vendors have shown interop among 
themselves, so an interop event just for this point is overkill, given the 
amount of work it takes to organize everyone.

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

Re: [IPsec] 5996bis 3.3.1 proposal structure

[Paul Hoffman]

 or not this is the last
 Transform Substructure in the Proposal.  This field has a value of 0 if
 this was last Transform Substructure, and a value of 3 if there are more
 Transform Substructures.  . . .

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

Re: [IPsec] connect to VPNC

[Paul Hoffman]

Greetings. This mailing list is for the development of the IPsec suite of 
protocols, not for tech support for a particular implementation. Your question 
is better answered by your vendor or maybe one of the many general 
question-and-answer web sites on the Internet.

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

[IPsec] End of WG LC on draft-ietf-ipsecme-ikev2-fragmentation; next steps

[Paul Hoffman]

Thank you to everyone for the lively review of 
draft-ietf-ipsecme-ikev2-fragmentation; this is the kind of energy we can 
really use in the WG. Valery: please prepare a new draft based on the comments 
received. Please include discussion of points even if they don't become 
technical changes in the draft; this will help future developers understand 
more about what the protocol is doing.

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

[IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

[Paul Hoffman]

Although there is a spirited, useful discussion going on between three or four 
participants, we could certainly use more reviewers for this WG document. 
Please send any comments to the list, and feel free to hop into the threads 
already running. Thanks!

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

Re: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-00.txt

[Paul Hoffman]

As a note to the WG, I asked Raj to turn in a revised draft which covered some 
of the points that Valery and others have made. Given the number of questions 
asked so far, I would prefer that the WG hold off on discussing this draft 
until there is a new, clarified draft.

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