Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05

[Dan Harkins]

  Hello,

  I agree with Tero here. This "tightening" is not necessary. There's 
no security
benefit by disallowing the RFC 7296 RECOMMENDED method of treating AEAD 
ciphers.
The only thing this will do is require pointless changes to existing RFC 
7296

compliant implementations.

  regards,

  Dan.

On 1/4/22 12:32 AM, RFC ISE (Adrian Farrel) wrote:

Resend with corrected email alias

Adrian

RFC ISE (Adrian Farrel) wrote:

Thanks Tero, much appreciated.

I will discuss this with the authors.

It is sometimes the case that this type of document (i.e. an NSA profile),
tightens the 2119 language from the referenced RFCs or removes options.
The argument in the past has been that, while the base spec gives some
degree of permissible variance, the specific deployment environment
requires particular behavior.

(FYI, these documents *never* relax the 2119 language.)

Nevertheless, I will check that the authors intended this behavior and
flag it to the responsible AD for confirmation.

Best,
Adrian


Tero Kivinen wrote:

While doing IANA expert review on the document I found some issues
with this document, so here are my comments to it.

In section 5 there is text which says:

In particular, since AES-GCM is an AEAD
algorithm, ESP implementing AES-GCM MUST indicate the integrity
algorithm NONE.  [RFC7296]

This does not match the recommendation for the RFC7296 which says in
section 3.3:

Combined-mode ciphers include
both integrity and encryption in a single encryption algorithm, and
MUST either offer no integrity algorithm or a single integrity
algorithm of "NONE", with no integrity algorithm being the
RECOMMENDED method.

This would mean that this document if approved would make the
recommended method of RFC7296 of no integrity algorithm not allowed by
this draft.

I do not think it is appropriate to this draft make such change, and I
would propose to change the wording on the section 5 to match the
RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm
is being sent in proposal at all, but it is also allowed to send
single integrity algorithm of "NONE".

--

And then some nits:

--

In the abstract there is unexpanded acronym NSA on first line. On the
introduction this is spelled out but there is acronym (NSA) listed
there, it is only included on the first line of section 3. Usually it
would be best to include the full expanded version of the acronym on
the first use, and then use the acronym, and also expand all acronyms
in the abstract.

--

>From section 5 forward the references to RFCs use bit funny format,
where the reference is AFTER the period of the sentence. This makes it
hard to parse the text, as some times you could assume that the
reference refers to the next sentence not the previous one.

For example the text:

User Interface (UI) suites are named suites that cover some typical
security policy options for IPsec.  [RFC4308] Use of UI suites does
not change the IPsec protocol in any way.

does not make clear where the RFC4308 reference belongs. Looking that
the text I think it belongs to the first sentence, so better format
would be:


User Interface (UI) suites are named suites that cover some typical
security policy options for IPsec ([RFC4308]).  Use of UI suites does
not change the IPsec protocol in any way.

(with or without parenthesis).

Same with some other references in the document.

--

In section 5.1, 5.2, 5.3, it would be good idea to explictly mention
that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is
already mentioned in the section 4, but implementors might just jump
to section 5 and define suites from there, so changing:

  Encryption: ENCR_AES_GCM_16

to

  Encryption: ENCR_AES_GCM_16 (with key size of 256 bits)

would make all information needed available in that section.

--

I think we can still keep the

  Integrity: NONE

even if we fix the section 5 to use the recommended way of not
including integrity algorithm at all, as this should be clear enough.

--

Section 6 is not really part of the UI suites, as they authentication
is separate from the algorithm negotiation in the IKEv2, but I think
including it here will make sense, but I wonder why text is written in
such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is
not allowed? I would have assumed that either SHA-384 or SHA-512 would
have been good enough for RSA.

With ECDSA I can see that match hash length with the group length, but
that does not really apply with RSA.

--

Section 7 has again text that changes RFC7296.

RFC7296 section 3.5 explictly says that:

  This identity may
be used for policy lookup, but does not necessarily have to match
anything in the CERT payload;

Text in section 7 says that:

The identity authentication
method MUST use an end-entity certificate provided by the
authenticating party a

Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt

[Dan Harkins]

  Gee maybe someone is blocking email :/

On 7/11/21 8:38 PM, Paul Wouters wrote:
Hmm, it used to be that if you are subscribed to one IETF list, you 
can post to any of them. That does not seem to work for the ipsec list :/



-- Forwarded message -
From: *Paul Wouters* >

Date: Sun, Jul 11, 2021 at 11:34 PM
Subject: Re: [IPsec] I-D Action: 
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
To: Panwei (William) >
Cc: ipsec@ietf.org  >



On Mon, 5 Jul 2021, Panwei (William) wrote:

Hi Wei Pan,

> According to the discussion on the mailing list, I update the draft 
to version 05. In this version, I deleted the unnecessary 
considerations for the configuration changes. For now, the solution is 
very simple and just includes the negotiation at creating IKE SAs and 
optimization at rekeying IKE and Child SAs.

>
> Comments and feedbacks are more than welcome.

It is lookger much better and simpler, but I still had a few issues and
wanted to make the document a bit shorter and clearer.  I made some
changes for your consideration. I've attached an updated xml and txt file
in case you would like to use my changes. The changes are:

- Reduced the text that was used to explain a lot of IKEv2 basics.

Instead, a reference to IKEv2 should be enough. This greatly simplifies
the text.

- Remove the parts about "changed configuration".

If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296
says this:

    In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
    different Traffic Selectors and algorithms than the old one" was
    changed to "Note that, when rekeying, the new Child SA SHOULD NOT
    have different Traffic Selectors and algorithms than the old one".

So if the configuration has changed, you should not do any kind of REKEY,
whether it is OPTIMIZED or not. You should do a re-authentication (in
other words, a new IKE from scratch)

- IKE REKEY MUST contain KE, because RFC 7296 says:

    The main reason for rekeying the IKE SA is to ensure that the
    compromise of old keying material does not provide information about
    the current keys, or vice versa.  Therefore, implementations MUST
    perform a new Diffie-Hellman exchange when rekeying the IKE SA.  In
    other words, an initiator MUST NOT propose the value "NONE" for the
    Diffie-Hellman transform, and a responder MUST NOT accept such a
    proposal.  This means that a successful exchange rekeying the IKE SA
    always includes the KEi/KEr payloads.

- Removed: It also helps to avoid IP fragmentation of IKEv2 messages

I don't think this is actually true, since on rekey there are no required
CERT payloads, which is the vast majority of the payload size in IKE_AUTH
that causes fragmentation.

- Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED}

This matches better with the OPTIMIZED_REKEY notify. Also, I find that
"minimum" is a little confusing. It could mean "minimum lifetime" or
"minimum of the previous one". I find "optimized" covers this better
than "minium".

- Shortened titles

For improved readability of Table of Contents

- Some grammar and style

Open questions to the working group:

1) Should the SUPPORTED notify mean that peers MAY use this method or MUST
    use this method? There could be a use for making it MUST, as a peer
    could then eventually stop supporting the "old method". Initiators
    would know by the lack of the notify that they might not be able to
    rekey in the old way, and must add/delete or re-auth the SA.

2) Alternatively, the SUPPORTED notify could have a payload that signifies
    whether the old method is supported or not.

3) Should we look at supporting rekeying multiple Child SAs at once? Or
    should we tell people they should have used additional Traffic
    Selectors and combined the Child SAs into one ?

4) When a Child SA was negotiated with PFS, what should an optimized rekey
    do when there is no KE payload? Send INVALID_KE_PAYLOAD ?


Paul



>
> Regards & Thanks!
> Wei Pan
>
>> -Original Message-
>> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org 
] On Behalf

>> Of internet-dra...@ietf.org 
>> Sent: Monday, July 5, 2021 12:24 PM
>> To: i-d-annou...@ietf.org 
>> Subject: I-D Action: 
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt

>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>         Title           : IKEv2 Optional SA&TS Payloads in Child
>> Exchange
>>         Authors         : Sandeep Kampati
>>                           Wei Pan
>>                           Meduri S S Bharath
>>                           Meiling Chen
>>      Filename        :
>> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>>      Pages           : 9
>>      

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Dan Harkins]

  Hi Daniel,

  That seems to be part of the problem. The IETF isn't in the business 
of dictating
administrative behavior through normative language. Protocols comply. 
People can use
compliant protocols or not, and if they decide to use protocols which 
are non-compliant,
or if they use proprietary protocols, it doesn't make them somehow 
"non-compliant".


  This effort seems to have gained steam due to developers being told 
by their project
management co-workers to do things to their IKEv1 code which they did 
not think was
appropriate given the state of IKEv2. I can certainly relate to such 
difficult interactions.
That said, the give-and-take of engineering and project/product 
management is not really in
the IETF's bailiwick. If people want to take an RFC to the 
project/product management
team and say, "look, the IETF has spoken!" then good luck, but that is a 
misuse of the

imprimatur of the IETF and don't try and standardize _that_ behavior.

  We can move a standard to historic. We can decide not to do any more 
development on it.
We can't force people to do anything and we can't declare they are 
"non-compliant" if

they decide to use a protocol we don't approve of.

  It's interesting how SCEP has survived and actually thrived despite 
its restricted
use and it's well-known security problems when EST, an IETF standard, 
exists. People
strung the SCEP draft through multiple dozens of versions, dragging it 
out, it was made
historic as a sop to this effort yet people still want to use it. I 
don't understand but
a very large vendor of tablet and phone hardware/software (who 
ironically stole their OS
name from the company that developed SCEP) decided to use it in their 
BYOD offering
and so product/project management teams all say we must continue to use 
SCEP and update
our SCEP code in order to work with these products that we can't avoid 
due to their
massive market share. Sure, continued use of IKEv1 is a problem but it's 
a molehill

compared to the mountain of today's use of SCEP. Yet here we are.

  Dan.

On 6/29/21 11:17 AM, Daniel Migault wrote:
I thought the purpose of the draft was to be able to say "look at this 
document it says you MUST switch to IKEv2 if you want to remain IPsec 
interoperable. I am suprised I do not see the MUST in question. I am 
fine whatever chair/co-authors are fine with.


Yours,
Daniel

On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <mailto:ynir.i...@gmail.com>> wrote:


[no hats]
I don’t want to start (or resume) a religious holy war about
uppercase MUSTs, but they’re usually about protocol compliance.
What people should (not SHOULD) do with their systems is not
subject to requirements language, because the IETF does not
engineer administrators. What? You are not compliant with RFC 
if you didn’t upgrade your systems already?

I could understand a statement that Product  is not compliant
with RFC  because it still offers IKEv1, but I don’t like
non-compliant administrators. Not that I’m advocating to add that
statement to the draft. I think it’s fine as it is: just offering
advice that systems should be upgraded.

Yoav


On 29 Jun 2021, at 17:21, Daniel Migault mailto:mglt.i...@gmail.com>> wrote:

I believe that the first sentence of section 3 says it all. ship it!

I still have some minor comments, though these may have already
been discussed. There are no normative MUST to upgrade ( and in
general very little normative language).
Shouldn't we have for example:
Systems running IKEv1 should be upgraded and reconfigured to run
IKEv2.

moved to :
Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.

There are overall very little number of SHOULD/MUST but maybe
    that is an editorial choice.

Yours,
Daniel



Yours,
Daniel

On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins mailto:dhark...@lounge.org>> wrote:


   Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language
less speculative and more concrete
>     are valid and should be reflected in the document.
>
> - Is it OK that the intended status is Standards Track?
Shouldn't it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247.
What in particular is being updated?
>     I believe the recent IESG directives require a short
explanation of what is being updated
>     to be present in Abstract. In any case, it should be
clearly indicated in the body of the document.
>     Have I missed it?
>
 

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Dan Harkins]

  Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:

Hi,

I think document is mostly ready. Few observations:

- FWIW I think that Dan's efforts to make draft's language less speculative and 
more concrete
are valid and should be reflected in the document.

- Is it OK that the intended status is Standards Track? Shouldn't it be BCP?

- The draft states that it updates RFC 7296, 8221, 8247. What in particular is 
being updated?
I believe the recent IESG directives require a short explanation of what is 
being updated
to be present in Abstract. In any case, it should be clearly indicated in 
the body of the document.
Have I missed it?

- Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every 
aspect." is a bit too vague.


  You know, that was bugging me too. "in every aspect" is laying it on 
a bit thick. IKEv1
has a security proof. The much maligned PSK mode authenticates the key 
as well as the
exchange which is better than what IKEv2 does (and why IKEv1 did not 
need an update to do
PQC). So saying it's less secure "in every aspect" just isn't true. But 
I couldn't figure

out a better way to say it


   I believe it's better to list security aspects where we believe IKEv2 is 
superior:

   * IKEv2 supports modern cryptographic primitives, including AEAD ciphers
   * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS 
(puzzles, RFC 8019) attacks
   * support for post-quantum crypto in IKEv2 is being developed 
(draft-ietf-ipsecme-ikev2-multiple-ke)
   * IKEv2 supports various authentication methods via integration with EAP 
(core spec)
   * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
   * did I forget something?


  But this is great! I agree that such a brief summary of the superior 
features

would be better than a factually challenged "in every aspect" statement.

  regards,

  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Dan Harkins]

On 6/27/21 7:02 PM, Paul Wouters wrote:

On Sun, 27 Jun 2021, Dan Harkins wrote:

  Thanks for facilitating this discussion (especially given the 
editor's issues with

interacting with me).


I don't want to keep focussing on this, but again I need to
defense myself. I have no issues with interacting with you on public
mailing lists. I have a personal opinion that your behaviour has been
inappropriate enough towards me and other groups of people that I wish
no longer interact with you via non-public emails. 


  Yet all these problematic non-public email interactions seem to have been
initiated by you! (I have the receipts).

I believe that is within my rights. 


  If only you would give that accommodation ("my rights") to me.

  But whatever, it's not really an IPsecme issue.


This does not interfere with me responding to on topic
discussion where I am acting in an official IETF capacity, such as
Document Author or Working Group Chair.


  Or document *editor*, as is the case here.


Yes, the unaddressed points are in the 3rd email. Everything
above the "there is another IKEv1 feature not available in IKEv2" 
line are my
unresolved comments, everything below that is further discussed in 
the final 2 emails

and is not relevant to the comments I made on the draft.

  Basically, I want to get rid of the speculative language and the 
guesswork language
which is  not really even necessary to make the case. I also provided 
2 reworded
paragraphs which I think improve the draft and are more clear. Of 
course, that's my
opinion, it's open to debate and disagreement, but if others agree 
with me then I

think these changes should be adopted by the editor.


At the time, I was waiting for more comments before updating the
document. I have now pushed these changes. I've taken in some text of 
Dan,

although I did not remove everything he suggested removing because I deem
those bits have value to bring across. If other people wish to chime in,
that would be useful to determine consensus.


  I still think there is a problem in providing speculative text about 
some vendors
and their potentially "unmaintained code". Unless you're prepared to 
state which
vendors are not maintaining their code to the detriment of their 
customers I don't
think you should allude to such a situation. And I really don't think an 
RFC is the

appropriate vehicle to describe such vendor behavior even if you were gonna
describe it.

  The draft does not need to engage in such speculation. There are 
plenty of other
concrete, definitive reasons to send IKEv1 to historic. This 
coulda/shoulda/woulda

stuff is not necessary and actually detracts from the draft.

The changes to the document are minor, so I think this can be 
evaluated as

part of this WGLC, but the final decision on that rests with the chairs.


  Actually it rests with the group. This is a document of the working 
group.


  Dan.

https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01 



Paul

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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Dan Harkins]

  Hi Yoav,

  Thanks for facilitating this discussion (especially given the 
editor's issues with
interacting with me). Yes, the unaddressed points are in the 3rd email. 
Everything
above the "there is another IKEv1 feature not available in IKEv2" line 
are my
unresolved comments, everything below that is further discussed in the 
final 2 emails

and is not relevant to the comments I made on the draft.

  Basically, I want to get rid of the speculative language and the 
guesswork language
which is  not really even necessary to make the case. I also provided 2 
reworded
paragraphs which I think improve the draft and are more clear. Of 
course, that's my
opinion, it's open to debate and disagreement, but if others agree with 
me then I

think these changes should be adopted by the editor.

  regards,

  Dan.

On 6/27/21 11:32 AM, Yoav Nir wrote:

To facilitate this discussion:

The comments are in this message: 
https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/


Paul repled with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/


Dan replied with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/


Tero: 
https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/


And finally, Dan: 
https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/


If I read this correctly, the last two messages are about some of 
decision-making process in IKEv2 drafts, so it’s not relevant to the 
draft now in WGLC.


Can I assume the unaddressed points are those in the third message?

Yoav

On 27 Jun 2021, at 10:27, Dan Harkins <mailto:dhark...@lounge.org>> wrote:



  I sent substantive comments on this draft to the list on May 6th of 
this

year. They were not addressed so they apply to this WGLC.

  Dan.

On 6/26/21 1:38 AM, Yoav Nir wrote:

Hi, all.

Although this draft is really new, having been submitted in April of 
this year, its predecessor draft has been under discussion since 
March of 2019.


This begins a 2-week WGLC. Please read the draft and post comments 
to the list. Since this is rather new, short messages in the vein of 
“Yeah, this is good. Ship it”, but substantive comments are, of 
course, even more welcome.


The WGLC ends at EOD (for me) July 12th, just a week before the IETF 
meeting.


Thanks

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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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




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

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Dan Harkins]

  I sent substantive comments on this draft to the list on May 6th of this
year. They were not addressed so they apply to this WGLC.

  Dan.

On 6/26/21 1:38 AM, Yoav Nir wrote:

Hi, all.

Although this draft is really new, having been submitted in April of this year, 
its predecessor draft has been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post comments to the list. 
Since this is rather new, short messages in the vein of “Yeah, this is good. 
Ship it”, but substantive comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.

Thanks

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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

[Dan Harkins]

  Hi Tero,

  Thanks for the clarification. I don't want to resurrect the idea
here but I feel compelled to respond to this:

On 5/9/21 4:21 AM, Tero Kivinen wrote:

And also I think shared key authentication also offeres exactly same
benefits than authentication with public key encryption for the
deniability point of view (i.e., either end can calculate everything
as long as they know the shared secret).


  With public key encryption, anyone is able to construct what looks
like a valid IKE conversation between any two participants by using
publicly available information (i.e. their certificates). For that
capability to be done with shared key authentication it would require
the shared key used for "authentication" to be known by everyone, which
sort of voids the whole security of the protocol.

  Basically, the shared key authentication mode would only be the
equivalent of public key encryption authentication mode when using
the Pre-shared Key for the Internet [1], which was an April Fools draft
and (I think this bears repeating these days) was not intended to be
taken seriously.

  regards,

  Dan.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsec-internet-key

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

[Dan Harkins]

On 5/6/21 12:21 PM, Paul Wouters wrote:

On Wed, 5 May 2021, Dan Harkins wrote:


  - the first two bullet points in section 3 are basically speculation,
    "a number of..." is meaningless. These bullet points are ultimately
    not even necessary to make the case being made. Delete these, 
please.


I have heard from vendors, so I don't think this is speculation.


  I don't doubt that such vendors exist but the wording sounds very
speculative, "a number of IKEv1 systems...will never be patched."
It begs the question, who? which ones? and I don't think we need to
get into specifics like that.


I think it is important to get these points across. Especially the
second bullet point, as people might think IKEv1 is still being
supported because their devices are still seeing regular updates,
without realizing that the IKEv1 code on those devices in fact will
not receive any further updates.


  OK, for the second one how about if it's rewritten to say:

"* IKEv1 development ceased over a decade ago and no new work will
   happen. This poses the risk of unmaintained code in an otherwise
   supported product which can result in security vulnerabilities."

That way it's not talking about "a number of vendors" but still
gets the point across that dead code is not good.

  - fourth bullet in section 3 should be rewritten. The "Often, 
IKEv1..."
    sentence should be removed but the remainder is a decent point. 
IKEv1

    was standardized before modern ciphers were designed, to get support
    for modern, accepted ciphers use IKEv2.


How about:

OLD:

  *  IKEv1 systems most likely do not support modern cryptographic
  algorithms.  AES-GCM is only defined for ESP and not IKE, and
  often not implemented for ESP.  And CHACHA20_POLY1305 is not
  defined for IKEv1.  Often, IKEv1 is configured with the very weak
  Diffie-Hellman Groups 2 and 5 and some implementatipons do not
  support any stronger alternatives.
NEW:

   * The IKEv1 protocol pre-dates modern cryptographic algorithms. While
 a limited number of more modern cryptographic algorithms were added
 to the IKEv1 specification, interoperability concerns means that 
the defacto
 algorithms deployed for IKEv1, AES-CBC, SHA1, DH2 and DH5, are no 
longer

 recommended and a migration to IKEv2 is the best method to deploy
 modern cryptographic algorithms with the IKE and IPsec protocols.

Or if you have an altnerative proposal, I'm happy to hear it.


  That's much better but its a bit tortured. How about:

   "* Great strides have been made in cryptography since IKEv1 development
  ceased. While some modern cryptographic algorithms were added to
  IKEv1, interoperability concerns mean that the defacto algorithms
  negotiated by IKEv1 will consist of dated or deprecated algorithms
  like AES-CBC, SHA1, and Diffie-Hellman groups 2 and 5. IKEv2 provides
  state-of-the-art suite of cryptographic algorithms that IKEv1 lacks."

Or maybe just make the whole bullet point be the last sentence. All that
needs to be said is that "IKEv2 provides state-of-the-art cryptographic
algorithms that IKEv1 lacks." That's the reason right there.


  - there is another IKEv1 feature not available in IKEv2: a deniable
    authentication method. IKEv1 had a very cool deniable exchange
    involving encrypted nonces. IKEv2 decided to not support that for
    whatever reason. Lack of support for a cool and usefu authentication
    method doesn't really make the case to send IKEv1 to historic


Can you clarify this a bit further for me? Is this deniable
authentication method part of all IKEv1 auth methods? Or is this a
specific feature that needed to be specifically enabled?


  It was one of the authentication methods: PSK, certs, encrypted
nonces. The encrypted nonce method was completely deniable. Honest
participants would get strong authentication but they could prove
to a court-of-law that the whole exchange could be fabricated by a
third party and deny ever taking part in it.


That said, if the WG deemed this feature no longer required when
specifying IKEv2, then I do not think we need to mention this here when
we are talking about motivations for people to move from IKEv1 to IKEv2.

If there is a good reason and people are prevented from upgrading to
IKEv2 because of this, I would be expecting an IKEv2 draft to be
developed to address this shortcoming. But it seems to me (I wasn't here
when these decisions were made) that the WG did not think this issue was
a concern ?


  I walked away from the WG after I produced -02 of the draft that became
IKEv2 so I have no idea what the was thinking after April of 2002 (nearly
two decades! Yikes). There were a number of decisions that the WG made that
looking back were odd. This is just one of them. Deniability is a valuable
property and I don't know 

Re: [IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed

[Dan Harkins]

  WRONG! You got exactly ZERO emails since your last hissy fit yet
you went out of your way to send me one accusing me of bullying
you. Your passive-aggressive attacks are getting ridiculous and
really tiring.

  Oh, and cryptography is deemed an armament by your own government.
So maybe petition your PM to stop such "mocking."

  Again, I'd be happy to take over this I-D. I'll accept emails from
anyone.

  Dan.

P.S. telling someone they should be "culled" (which means to be
slaughtered) is against the IETF's anti-harassment policy. You might
want to stop being such a hypocrite.

On 5/5/21 9:25 PM, Paul Wouters wrote:

On May 5, 2021, at 23:15, Dan Harkins  wrote:



 OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme
a break.


I actually tried giving you a break last time you brought this up,
but literally days laters you repeated the same behaviour again.
Actions have consequences, so I exercised my right to not have to listen
to your personal emails to me.


If the editor of a draft in an IETF WG blocks legitimate email
concerning the draft then perhaps the editor of the draft shouldn't
be editor of the draft anymore.


I have no problem responding to emails on this list, even sent by you.
They are not blocked and we can have IPsec related conversations in 
public.



I'll volunteer to take over this draft. I don't block anyone and
will tolerate all sorts of inclusive or non-inclusive behavior.


As someone who added a mocking Human Rights Considerations section to
promote the right to bear arms in RFC 8492 and as someone who used a
“Lester White” persona to publish a draft mocking (and targetting)
a number of vulnerable groups of people, while throwing in a personal
attacks on me and ekr under the guise of “sarcasm is freedom of
speech”, I would urge the chairs to pick another alternative author,
if they deem one is necessary.

I will process your on-topic comments to the draft in a separate email,
and if needed rev the document to address the issues and we can discuss
that further on this email list.

I will not further comment on your opinion about my personal email
server configuration, because that is out of scope for this list, AND
because it is still my desire and right not to talk or listen to you
about anything other than IETF work covered by the Note Well and IETF
anti-harassment policy.

Paul


.On 5/5/21 8:08 PM, PMDF Internet Messaging wrote:
This report relates to a message you sent with the following header 
fields:

 Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86...@lounge.org>
 Date: Wed, 05 May 2021 20:08:35 -0700
 From: Dan Harkins 
 To: Paul Wouters , ipsec@ietf.org
 Subject: Re: [IPsec] I-D Action:
  draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt
Your message cannot be delivered to the following recipients:
 Recipient address: p...@nohats.ca
 Reason: Remote SMTP server has rejected address
 Diagnostic code: smtp;550 5.7.1 : Sender 
address rejected: Refusing email from Dan Harkins for repeated 
bullying and non-inclusive behaviour
 Remote system: dns;mx.nohats.ca 
(TCP|198.137.202.94|47303|193.110.157.68|25) (mx.nohats.ca ESMTP 
Postfix)

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

[IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed

[Dan Harkins]

  OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme
a break.

  If the editor of a draft in an IETF WG blocks legitimate email
concerning the draft then perhaps the editor of the draft shouldn't
be editor of the draft anymore.

  I'll volunteer to take over this draft. I don't block anyone and
will tolerate all sorts of inclusive or non-inclusive behavior.

  Dan.

On 5/5/21 8:08 PM, PMDF Internet Messaging wrote:

This report relates to a message you sent with the following header fields:

   Message-id: <6297c870-0507-b3e8-ee6e-5517bdc86...@lounge.org>
   Date: Wed, 05 May 2021 20:08:35 -0700
   From: Dan Harkins 
   To: Paul Wouters , ipsec@ietf.org
   Subject: Re: [IPsec] I-D Action:
draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

Your message cannot be delivered to the following recipients:

   Recipient address: p...@nohats.ca
   Reason: Remote SMTP server has rejected address
   Diagnostic code: smtp;550 5.7.1 : Sender address 
rejected: Refusing email from Dan Harkins for repeated bullying and non-inclusive 
behaviour
   Remote system: dns;mx.nohats.ca (TCP|198.137.202.94|47303|193.110.157.68|25) 
(mx.nohats.ca ESMTP Postfix)


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

[Dan Harkins]

  Paul,

  Thanks for doing this. A few comments:

  - the first two bullet points in section 3 are basically speculation,
    "a number of..." is meaningless. These bullet points are ultimately
    not even necessary to make the case being made. Delete these, please.

  - fourth bullet in section 3 should be rewritten. The "Often, IKEv1..."
    sentence should be removed but the remainder is a decent point. IKEv1
    was standardized before modern ciphers were designed, to get support
    for modern, accepted ciphers use IKEv2.

  - there is another IKEv1 feature not available in IKEv2: a deniable
    authentication method. IKEv1 had a very cool deniable exchange
    involving encrypted nonces. IKEv2 decided to not support that for
    whatever reason. Lack of support for a cool and usefu authentication
    method doesn't really make the case to send IKEv1 to historic, but
    then, oh well. As an aside, I suggested a way to add an exchange
    such an exchange using HPKE [1]. Not that I'm saying this needs to
    be added to IKEv2, but if you're gonna talk about IKEv1 features
    missing in IKEv2 you should be complete.

Other than that, good work.

  regards,

  Dan.

[1] https://mailarchive.ietf.org/arch/msg/cfrg/zjQLxV2u1wUZMFraDuy6KRPIaqU/

On 4/28/21 8:48 AM, Paul Wouters wrote:

On Wed, 28 Apr 2021, internet-dra...@ietf.org wrote:

Subject: [IPsec] I-D Action: 
draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt


Looks like the datatracker email does not post the diff between
different document names :P

The diff is:

https://tools.ietf.org/rfcdiff?url1=draft-pwouters-ikev1-ipsec-graveyard-06.txt&url2=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt 



Basically, it removes the IANA request to close the IKEv1 registries,
changes draft name / title to avoid "graveyard" and lists some items
as bullet points and sections, and changes some subjective wording to
more objective language.

I'm not saying this is ready for WGLC, but 

Paul

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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

[IPsec] comments on graveyard draft, became Re: Delivery Notification: Delivery has failed

[Dan Harkins]

  Oh for gaia's sake

On 3/8/21 6:33 AM, PMDF Internet Messaging wrote:

This report relates to a message you sent with the following header fields:

   Message-id: 
   Date: Mon, 08 Mar 2021 06:33:15 -0800
   From: Dan Harkins 
   To: Paul Wouters 
   Subject: comments on graveyard draft

Your message cannot be delivered to the following recipients:

   Recipient address: p...@nohats.ca
   Reason: Remote SMTP server has rejected address
   Diagnostic code: smtp;550 5.7.1 : Sender address 
rejected: Exercising my freedom to not hear you scream
   Remote system: dns;mx.nohats.ca (TCP|198.137.202.94|47805|193.110.157.68|25) 
(mx.nohats.ca ESMTP Postfix)


  Let freedom ring :-P

  Comments on the draft, make them official I guess. What I wrote was:

-

  Hi Paul,

  I kind of ran through my comments pretty quickly so let me repeat
them here so they don't get lost:

  - like the TLS 1.0 to historic, I think this draft should be BCP
  - make the title ikev1-to-historic, get rid of cutesy name
  - remove all the subjective opinion in section 3-- all the "high
    chance" or "most likely" or "quite often" etc-- and just mention
    that anything IKEv1 can do IKEv2 can do better, and that the
    reasons to do IKEv1 in the past-- PQ and labeled IPsec-- are
    no longer legit due to the advancement of the relevant drafts
  - I don't think deprecating the registries is necessary if the
    RFC goes to historic, as you note, there's been no work on IKEv1
    for over a decade so leaving the registries alone will not be
    some backdoor way of sneaking in IKEv1 changes. Other orgs are
    using the repository so just deprecating is not right.
  - If you're gonna reject any DH groups then reject the weak ones,
    it doesn't make sense to do 1 and 22 and leave 2 and 5 (and 23
    and 24!) alone.

It didn't look like there was any opposition to adopting this so
just consider these as comments on the draft as adopted.

  thanks,

  Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Dan Harkins]

On 3/4/21 4:46 PM, Dan Brown wrote:

Sorry for foolishly forgetting about the OCB RFC, which specifies OCB3.

But that OCB3 RFC is from 2014, five-ish years before the OCB2 break.

  It says:

"The version of OCB defined in this document is a refinement of two
   prior schemes.  The original OCB version was published in 2001 [OCB1]
   and was listed as an optional component in IEEE 802.11i.  A second
   version was published in 2004 [OCB2] and is specified in ISO 19772.
   The scheme described here is called OCB3 in the 2011 paper describing
   the mode [OCB3]; it shall be referred to simply as OCB throughout
   this document.  The only difference between the algorithm of this RFC
   and that of the [OCB3] paper is that the tag length is now encoded
   into the internally formatted nonce.  See [OCB3] for complete
   references, timing information, and a discussion of the differences
   between the algorithms."

So this RFC describes OCB3.

Again, the OCB2 attack severely erodes my trust in OCB3, though maybe 
I'm an outlier. Maybe I'm also forgetting recent CFRG or other effort 
to regain trust in OCB3 relative to OCB2?


And it also says:

  "OCB has received years of in-depth analysis previous to its
   submission to the CFRG and has been under review by the members of
   the CFRG for over a year.  It is the consensus of the CFRG that the
   security mechanisms provided by the OCB AEAD algorithm described in
   this document are suitable for use in providing confidentiality and
   authentication."

  So CFRG has produced a document defining OCB3 and that document
represents the consensus of the CFRG. I'm not sure what else you think
CFRG should be doing but maybe mention it on the CFRG list instead of
IPsec. Also, Phil Rogaway is on the CFRG list but I don't think he's
on this one. If you have trust issues with OCB then maybe bring them
up with him there.

  Dan.



--------
*From: *Dan Harkins 
*Sent: *Mar 4, 2021 5:29 PM
*To: *Dan Brown ; ipsec@ietf.org
*Subject: *Re: [IPsec] [Cryptography] Direct public confirmation from 
Dr. Rogaway (fwd)



  Hi Dan,

On 3/4/21 11:04 AM, Dan Brown wrote:


Deciding whether to use OCB sounds like a job for CFRG!

As I understand it, OCB2 is severely broken:
https://eprint.iacr.org/2019/311

<https://urldefense.proofpoint.com/v2/url?u=https-3A__eprint.iacr.org_2019_311&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=8aGCbnoSU7ozJ-QSzxHGokOgKsea7IZq6669KyaMNNA&s=bSN3q8CM03xYZRbPi2KanYD7GKxGF2HjAZ9AjTc5Nvk&e=>

That said, OCB1 and OCB3 may be just fine, but a broken OCB2 is
not a good sign.  All the more reason to defer to CFRG, unless
you want to play Monty Hall problem.




  CFRG already produced RFC 7253. That's really all they can
be expected to do. It's up to individual IETF WGs to define
how to use that cipher mode in their particular protocols.
That's where we come in.

  regards,

  Dan.


Dan

*From:* IPsec  *On Behalf Of *Dan Harkins
*Sent:* Wednesday, March 3, 2021 2:37 PM
*To:* ipsec@ietf.org
*Subject:* Re: [IPsec] [Cryptography] Direct public confirmation
from Dr. Rogaway (fwd)


  Faster and more secure seem to be compelling reasons. Those
reasons are
probably more compelling for ESP than they are for IKE.

  The license for OCB always had some caveats like the code could
not be used
for military purposes which is something of a nightmare for a
manufacturer of
general purpose hardware/software. Considering how difficult it
would be to
ensure that your product is never used by a military anywhere in
the world,
that's probably enough of a reason for TLS to not support it.
Remember how
long ECC was delayed for (imagined) IP reasons?

  IP is bad news. People don't want anything to do with partially
encumbered
technology. Now this technology is not encumbered at all so, yea,
let's do it.

  If an individual draft was to appear would the WG adopt it as a
work item?

  regards,

  Dan.

On 2/28/21 1:47 PM, Yoav Nir wrote:

IIRC the license has allowed OCB to be used for TLS for
several years. They haven’t taken it up. There are no AES-OCB
ciphersuites

inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
< >

So I’m wondering right with you: It has a theoretical
advantage in security and a measurable advantage in speed in
software.  Neither were compelling enough for anyone to
bother adding it in TLS ciphersuites.  Why should our
conclusion be any different?

Yoav



On 28 Feb 2021, at 22:35, Paul Wouters mailt

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Dan Harkins]

  Hi Dan,

On 3/4/21 11:04 AM, Dan Brown wrote:


Deciding whether to use OCB sounds like a job for CFRG!

As I understand it, OCB2 is severely broken: 
https://eprint.iacr.org/2019/311


That said, OCB1 and OCB3 may be just fine, but a broken OCB2 is not a 
good sign.  All the more reason to defer to CFRG, unless you want to 
play Monty Hall problem.





  CFRG already produced RFC 7253. That's really all they can
be expected to do. It's up to individual IETF WGs to define
how to use that cipher mode in their particular protocols.
That's where we come in.

  regards,

  Dan.


Dan

*From:* IPsec  *On Behalf Of *Dan Harkins
*Sent:* Wednesday, March 3, 2021 2:37 PM
*To:* ipsec@ietf.org
*Subject:* Re: [IPsec] [Cryptography] Direct public confirmation from 
Dr. Rogaway (fwd)



  Faster and more secure seem to be compelling reasons. Those reasons are
probably more compelling for ESP than they are for IKE.

  The license for OCB always had some caveats like the code could not 
be used
for military purposes which is something of a nightmare for a 
manufacturer of
general purpose hardware/software. Considering how difficult it would 
be to
ensure that your product is never used by a military anywhere in the 
world,

that's probably enough of a reason for TLS to not support it. Remember how
long ECC was delayed for (imagined) IP reasons?

  IP is bad news. People don't want anything to do with partially 
encumbered
technology. Now this technology is not encumbered at all so, yea, 
let's do it.


  If an individual draft was to appear would the WG adopt it as a work 
item?


  regards,

  Dan.

On 2/28/21 1:47 PM, Yoav Nir wrote:

IIRC the license has allowed OCB to be used for TLS for several
years. They haven’t taken it up. There are no AES-OCB ciphersuites

inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4


So I’m wondering right with you: It has a theoretical advantage in
security and a measurable advantage in speed in software.  Neither
were compelling enough for anyone to bother adding it in TLS
ciphersuites.  Why should our conclusion be any different?

Yoav



On 28 Feb 2021, at 22:35, Paul Wouters mailto:p...@nohats.ca>> wrote:


So now that OCB is finally free, do we want to implement it? :)

I'm honestly not sure if the improvements of AES-GCM are worth it.
I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or
counters.

Paul

-- Forwarded message --
Date: Sat, 27 Feb 2021 14:37:30
From: "Salz, Rich via cryptography" mailto:cryptogra...@metzdowd.com>>
To: "cryptogra...@metzdowd.com
<mailto:cryptogra...@metzdowd.com>" mailto:cryptogra...@metzdowd.com>>
Subject: [Cryptography] Direct public confirmation from Dr.
Rogaway


https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/

<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_cfrg_qLTveWOdTJcLn4HP3ev-2Dvrj05Vg_&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=LZV-8STdDDeui1TmXz2JORn2wTtSrkJa_-l3hZK-AO8&e=>
:



I can confirm that I have abandoned all OCB patents

and placed into the public domain all OCB-related IP of mine.

While I have been telling people this for quite some time, I don't

think I ever made a proper announcement to the CFRG or on the

OCB webpage. Consider that done.



I hope people will use the scheme to do positive things.



phil

___
The cryptography mailing list
cryptogra...@metzdowd.com <mailto:cryptogra...@metzdowd.com>
https://www.metzdowd.com/mailman/listinfo/cryptography

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.metzdowd.com_mailman_listinfo_cryptography&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=_9IPM1exZqE6F4PLBAvpqDF-bHkBi5JPiUyq3eeyfwo&e=>
___
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=B4s3eO4jZ5UhqwAPEQu9SxQaSVWKuM4HcC1moozCyBc&e=>



___

IPsec mailing list

IPsec@ietf.org

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Dan Harkins]

  Faster and more secure seem to be compelling reasons. Those reasons are
probably more compelling for ESP than they are for IKE.

  The license for OCB always had some caveats like the code could not 
be used
for military purposes which is something of a nightmare for a 
manufacturer of

general purpose hardware/software. Considering how difficult it would be to
ensure that your product is never used by a military anywhere in the world,
that's probably enough of a reason for TLS to not support it. Remember how
long ECC was delayed for (imagined) IP reasons?

  IP is bad news. People don't want anything to do with partially 
encumbered
technology. Now this technology is not encumbered at all so, yea, let's 
do it.


  If an individual draft was to appear would the WG adopt it as a work 
item?


  regards,

  Dan.

On 2/28/21 1:47 PM, Yoav Nir wrote:
IIRC the license has allowed OCB to be used for TLS for several years. 
They haven’t taken it up. There are no AES-OCB ciphersuites 
inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4 



So I’m wondering right with you: It has a theoretical advantage in 
security and a measurable advantage in speed in software.  Neither 
were compelling enough for anyone to bother adding it in TLS 
ciphersuites.  Why should our conclusion be any different?


Yoav


On 28 Feb 2021, at 22:35, Paul Wouters > wrote:



So now that OCB is finally free, do we want to implement it? :)

I'm honestly not sure if the improvements of AES-GCM are worth it.
I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.

Paul

-- Forwarded message --
Date: Sat, 27 Feb 2021 14:37:30
From: "Salz, Rich via cryptography" >
To: "cryptogra...@metzdowd.com " 
mailto:cryptogra...@metzdowd.com>>

Subject: [Cryptography] Direct public confirmation from Dr. Rogaway


https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :



I can confirm that I have abandoned all OCB patents

and placed into the public domain all OCB-related IP of mine.

While I have been telling people this for quite some time, I don't

think I ever made a proper announcement to the CFRG or on the

OCB webpage. Consider that done.



I hope people will use the scheme to do positive things.



phil

___
The cryptography mailing list
cryptogra...@metzdowd.com 
https://www.metzdowd.com/mailman/listinfo/cryptography
___
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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [IPsec] graveyard: deprecate->historic

[Dan Harkins]

On 1/12/20 10:35 PM, Benjamin Kaduk wrote:

On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote:

On 12/23/19 10:46 AM, Benjamin Kaduk wrote:

Since we're in pedantic process mode...

[snip]

Perhaps something like "IKEv1 is no longer relevant for Internet
systems" would work, though I suspect we could even get away without such
an intro sentence and just dive in straight with "Systems running IKEv1
should be upgraded and reconfigured to run IKEv2.

    See that's the thing. There is nothing compelling to force the change
away
from "no longer relevant" so people still use it. If there was something
compelling to make people want to change we wouldn't be forced to do this,
sigh, die die die nonsense. Perhaps, "we're the IETF and we are really
serious now". That should dispel all doubt in whoever happens to read this
RFC. That way we won't need a die die die die or a die die die die die die.

I'm only aboue 95% sure I'm parsing you properly -- you're saying that if
there was a clear reason to move from IKEv1 to IKEv2 the market would have
done it already and we wouldn't be bothering with a doc like this?  That
is, that what we're really doing is akin to "we're the IETF and we
pinky-swear that we're not going to touch this anymore" as opposed to "here
is a list of the ways that using IKEv1 is going to bite you"?


  Yes, that's what I'm saying. From discussing this over the past few 
meetings
it seems the motivation for this is because people are still getting 
pressure
in their companies to work on IKEv1 or support IKEv1 or whatever and 
people want
it to go away. But they're losing that argument at work so they want a 
document
with the imprimatur of the IETF that they can wave at the PLM person (or 
whoever)

and say, "SEE! IT'S DEAD! Finished. No more. Over. The IETF has spoken!"

  So my "we're the IETF and we're serious this time" was sarcastic (and 
that comes
out poorly in email, hence the parsing difficulty) because I don't think 
this is

what the RFC process is for.

  IKEv1 is done, it's over, it's dead. It's been like that for more 
than a decade.
We already made a statement that we won't touch IKEv1 anymore and we 
made that
statement fifteen years ago. And we're still doing "die die die" stuff 
that's now

been refashioned into a "graveyard" effort in order to address the sensitive
sensibilities of the new IETF, but it's still the same thing. It's 
trying add an
underscore and an exclamation point to a statement that was already 
made. Because

we're really serious this time-- it's in the graveyard!

  Dan.



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

Re: [IPsec] graveyard: deprecate->historic

[Dan Harkins]

On 12/23/19 10:46 AM, Benjamin Kaduk wrote:

Since we're in pedantic process mode...

[snip]

Perhaps something like "IKEv1 is no longer relevant for Internet
systems" would work, though I suspect we could even get away without such
an intro sentence and just dive in straight with "Systems running IKEv1
should be upgraded and reconfigured to run IKEv2.


  See that's the thing. There is nothing compelling to force the change 
away

from "no longer relevant" so people still use it. If there was something
compelling to make people want to change we wouldn't be forced to do this,
sigh, die die die nonsense. Perhaps, "we're the IETF and we are really
serious now". That should dispel all doubt in whoever happens to read this
RFC. That way we won't need a die die die die or a die die die die die die.

  Dan.


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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

On 8/30/19 10:51 AM, Paul Wouters wrote:

On Fri, 30 Aug 2019, Dan Harkins wrote:

 Administrators doing site-to-site VPNs are better of using a true 
random

 strong PSK instead of a weaker PAKE.


  Well how many administrators generate a nice string of 256-bits of 
"true
random strong PSK"? Seriously, if administrators followed such advice 
then

we would not continually adding another "die" on the "die die die IKEv1"
routine we seem to do every 9 months. How many "dies" are we up to now?


I did not add killing PSKs to that draft, precisely because some
objected because strong PSK's are stronger than PAKEs.


  Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added
protection of resistance to dictionary attack against the symmetric 
credential

(which could, in fact, be a PSK).

  The definition of dictionary attack is one in which the adversary 
gains an

advantage through computation and not interaction. So even with a strong PSK
you are still susceptible to a dictionary attack since it is the 
protocol that

is susceptible to attack and not the credential. With a strong PSK it just
makes the dictionary attack use much more time to be successful (and yes the
"true random strong PSK" that's 256 bits could make the attack 
computationally

infeasible but then managing such a credential is similarly infeasible).

  Think of it this way, if your strong PSK has 64 bits of good randomness
it will take around 2^32 offline computations after A SINGLE ACTIVE 
ATTACK to

get a probability of 0.5 of success while if you used that same thing with a
PAKE it would take around 2^32 ACTIVE ATTACKS to get a probability of 0.5.

  What a PAKE allows you to do is retain security even in the presence of a
not-so strong PSK. It does not mean the PAKE is weak. We should not be
standardizing a weak PAKE and I don't think any of the candidates that CFRG
is considering are weak.

  If you can manage a "strong PSK" then using it with a PAKE makes it 
stronger.
If you can't manage a "strong PSK" then a PAKE still increases security. 
There's

really no reason to use a PSK exchange susceptible to dictionary attack when
something like SPEKE is available.

  regards,

  Dan.




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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

On 8/30/19 9:16 AM, Paul Wouters wrote:

On Fri, 30 Aug 2019, Dan Harkins wrote:


  Sure we can. We could do the thing that was done in TLS-pwd. When the
client registers his username and password she gets a static DH public
key of the server (TLS-pwd made this be a p256 curve for its compact
representation and adequate strength for the purpose of identity
protection). The scheme then is if the client wants to protect its
identity it uses the server's DH public key and does a static-ephemeral
exchange, gets a secret, encrypts its identity and sends its ephemeral
DH key (in compact representation, it's 33 octets) plus the encrypted
identity in one "identity payload". If it doesn't care about identity
protection it just sends its identity.


EAPTLS already uses like 8 round trips. So anything that has PAKE using
less than 8 seems like a win already :P So I am fine adding a few
roundtrips for whatever PAKE we come up with if that avoids all of this
extra complexity. Especially if this complexity is something that is 
added

to the client provisioning.

Remember this PAKE stuff is meant for those scenarios where we have an
enduser with _only_ a username/password. If this requires installing
additional client configuration, those clients might as well go to
X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method
supporting OTPs.


  Doing EAPTLS seems pointless. If your "additional client configuration"
involved a new trust anchor and an EST exchange and an X.509 certificate
then why not just use IKE?

  EAP is an abomination. It includes an identity request/response roundtrip
that generates an identity that the EAP RFC says is unsuitable for any
authentication purpose. Imagine that, an "authentication" protocol that
wastes a roundtrip getting a useless identity and then punts off the job
of getting a usable identity to another authentication protocol that has
to wrap itself in an EAP encapsulation. Putting EAP into IKE was a bad idea
and it seems doubly bad to put a PAKE (or PSK or OTP) into EAP inside IKE.


Administrators doing site-to-site VPNs are better of using a true random
strong PSK instead of a weaker PAKE.


  Well how many administrators generate a nice string of 256-bits of "true
random strong PSK"? Seriously, if administrators followed such advice then
we would not continually adding another "die" on the "die die die IKEv1"
routine we seem to do every 9 months. How many "dies" are we up to now?

  Management of such "true random strong PSKs" is a pain which is why
administrators use PSKs that are shorter, easier to remember, and easier to
enter with a high probability of being correct. So a PAKE is just a robust
solution for administrators that will do what we know they're gonna do 
anyway.

They're not weak.

  For a site-to-site VPN something like "identity protection" might not be
that big of a deal so there need not be any client provisioning. A simple
phone call between the 2 parties could suffice. If identity protection is
needed, then there's a provisioning step or we do an additional roundtrip.

  regards,

  Dan.





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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

On 8/30/19 2:27 AM, Tero Kivinen wrote:

Dan Harkins writes:

How does the responder know which of the one million username password
pairs to pick to generate the generator when calculating D-H in the
IKE_SA_INIT? The actual identity of the user is only sent in the
encrypted IKE_AUTH message.

I.e., I think this has exactly same problem than IKEv1 has with
pre-shared keys for main mode. You must know the initiator identity
based on the IP-addresses, thus makes this completely unusable for
non static VPN cases.

    HA! I did miss something :-)

    Yes, I guess a new payload is needed to express the username. This can
be added to the IKE_SA_INIT message. Or maybe it can be a special type of
NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this
should not involve an extra Auth exchange (as the framework PAKEs do)
since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE
is.

We had similar discussion in the postquantum preshared keys case,
i.e., we needed to know the identity of the other end to pick the PPK,
but the identity is only transmitted in the IKE_AUTH, and IKE_AUTH is
encrypted with the key which is generated in IKE_SA_INIT. We solved
this issue in qr-ikev2 by making so that encryption of the IKE_AUTH
does not need the PPK, but uses only normal Diffie-Hellman and PPK is
only added to the actual IPsec trafic keys.

The problem is that if we add the identity to the IKE_SA_INIT, then we
loose the identity protection part of the IKEv2, as we then cannot
encrypt the identity.


  Sure we can. We could do the thing that was done in TLS-pwd. When the
client registers his username and password she gets a static DH public
key of the server (TLS-pwd made this be a p256 curve for its compact
representation and adequate strength for the purpose of identity
protection). The scheme then is if the client wants to protect its
identity it uses the server's DH public key and does a static-ephemeral
exchange, gets a secret, encrypts its identity and sends its ephemeral
DH key (in compact representation, it's 33 octets) plus the encrypted
identity in one "identity payload". If it doesn't care about identity
protection it just sends its identity.


Current solutions have been trying to keep the identity protection
part as good as it is without those extensions, i.e., qr-ikev2 still
provides same identity protection than what normal IKEv2 does, and
then provides extended protection for the actual trafic keys. Attacker
who can break Diffie-Hellman can see the identities, but will not see
the actual trafic protected by PPK.

With PAKEs, I think it is important to do the same, i.e., keep the
identity protection parts of the IKEv2 at least as good as they are
now, and that usually needs we need to do normal IKEv2 Diffie-Hellman
first to protect identities, and then inside that when we know
identities do the actual authentication using PAKE.

Hybrid qske does things bit differently as it adds IKE_INTERMEDIATE
exchanges between IKE_SA_INIT and IKE_AUTH but all of those
IKE_INTERMEDIATE exchanges are anonymous, i.e., the identity of the
other end is not yet known, the authentication is done in the end with
IKE_AUTH, and only then the identity of the other end is known, and we
can use per user information like shared keys or password etc.


Yes, we can do a PAKE exchange after IKE_SA_INIT and use that to do
identity protection. It just does add another round trip and I was trying
to point out how we can get a PAKE mode of IKE without any additional
round trips or things like that. SPEKE is just a Diffie-Hellman and IKE
already does a Diffie-Hellman. With the identity protection scheme I
described above we're doing a 2nd Diffie-Hellman so work-wise it's a
wash but from a protocol standpoint I think it's cleaner.

The qr-ikev2 stuff is done that way but that's because we want to augment
the qr exchange with a traditional D-H. That's the design. There is no
reason to force PAKEs to do the same thing, which isn't to say we can't
just that we don't have to.


  regards,

  Dan.


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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

On 8/29/19 7:55 PM, Michael Richardson wrote:

Dan Harkins  wrote:
 >   I had some discussions with several people in Montreal on the subject 
of
 > using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is
 > quite cumbersome. I was told I should bring it up on the IPsec list so

Understood, but could you say, despite that, why it's worth it for SPEKE?
Afterall, we adopted EAP, which could also be said to be quite cumbersome
rather than build all sorts of username/password and 3GPP/SIM integrations..


  The "PAKE framework" is complicated and unnecessary. Around the time 
that I

was proposing a PAKE for IKE, "EAP-only" IKE was also being proposed. As it
turns out the only reason to use EAP-only IKE was with a PAKE-- server-side
cert was taken care of by normal EAP-IKE and if both sides have a cert then
just do plain jane IKE. But the chairs at the time had a vested interest in
doing EAP-only and in making PAKE, the alternative to EAP-only, be as
cumbersome as possible. And so we got this mess that no one implements.

  SPEKE can just fall straight into the IKE_SA_INIT exchange (with a 
username

indicator as Tero pointed out) and it is authenticated with the IKE_AUTH
exchange. There is no additional framework messaging and there is no EAP
messaging and overhead. It's clean.


 > In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
 > where either side can initiate. The PAKE I'm describing here is SPEKE,
 > a balance PAKE.

Got it.

 >   This would require a new Auth Method defined for SPEKE/PAKE to indicate
 > that the SPEKE shared secret is used. And that should be all that's 
needed.
 > It should be that simple. The protocol shouldn't have to change, no new
 > messages, no new payloads, no new nuthin. If I'm missing something please
 > let me know.

As I understand you, it's basically PSK authentication, but the PSK is
no longer directly shared.  Would the QM "augmentation" of PSK have any value
here?


  Yes, that's a way of thinking of it. The PSK is not shared and no 
PSK-derived

data is shared. Both sides prove they know the secret without exposing it.

  regards,

  Dan.



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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

On 8/29/19 5:11 PM, Tero Kivinen wrote:

[removed cfrg from CC, as I do not think this issue really belongs
there as we are discussing IKE signaling here].

Dan Harkins writes:

   First of all this suggestion is for a particular PAKE and I'm not
suggesting that any of the other candidates would slide in so effortlessly.
In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
where either side can initiate. The PAKE I'm describing here is SPEKE,
a balance PAKE.

   SPEKE does a simple Diffie-Hellman but uses a secret generator that is
deterministically obtained from the password. This technique is basically
one of the hash-to-curve functions from the CFRG's hash-to-curve I-D
or a simple hashing and exponentiation for MODP groups. All this happens
at password provisioning time prior to IKE being run.

   Then when IKE is run the secret generator for the negotiated group is
used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The
result is, if they both have the same generator (which means they had the
same password), an authenticated shared secret. This secret is verified in
the IKE_AUTH exchange.

How does the responder know which of the one million username password
pairs to pick to generate the generator when calculating D-H in the
IKE_SA_INIT? The actual identity of the user is only sent in the
encrypted IKE_AUTH message.

I.e., I think this has exactly same problem than IKEv1 has with
pre-shared keys for main mode. You must know the initiator identity
based on the IP-addresses, thus makes this completely unusable for
non static VPN cases.


  HA! I did miss something :-)

  Yes, I guess a new payload is needed to express the username. This can
be added to the IKE_SA_INIT message. Or maybe it can be a special type of
NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this
should not involve an extra Auth exchange (as the framework PAKEs do)
since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE
is.

  regards,

  Dan.


   This would require a new Auth Method defined for SPEKE/PAKE to indicate
that the SPEKE shared secret is used. And that should be all that's needed.
It should be that simple. The protocol shouldn't have to change, no new
messages, no new payloads, no new nuthin. If I'm missing something please
let me know.


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

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Dan Harkins]

  Hello,

  I had some discussions with several people in Montreal on the subject of
using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is
quite cumbersome. I was told I should bring it up on the IPsec list so
here goes (copying CFRG since that's where the PAKE work is being done).

  First of all this suggestion is for a particular PAKE and I'm not
suggesting that any of the other candidates would slide in so effortlessly.
In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
where either side can initiate. The PAKE I'm describing here is SPEKE,
a balance PAKE.

  SPEKE does a simple Diffie-Hellman but uses a secret generator that is
deterministically obtained from the password. This technique is basically
one of the hash-to-curve functions from the CFRG's hash-to-curve I-D
or a simple hashing and exponentiation for MODP groups. All this happens
at password provisioning time prior to IKE being run.

  Then when IKE is run the secret generator for the negotiated group is
used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The
result is, if they both have the same generator (which means they had the
same password), an authenticated shared secret. This secret is verified in
the IKE_AUTH exchange.

  This would require a new Auth Method defined for SPEKE/PAKE to indicate
that the SPEKE shared secret is used. And that should be all that's needed.
It should be that simple. The protocol shouldn't have to change, no new
messages, no new payloads, no new nuthin. If I'm missing something please
let me know.

  regards,

  Dan.

On 8/8/19 12:30 AM, Stanislav V. Smyshlyaev wrote:

Dear ipsecme,

I am writing this message on behalf of the CFRG chairs.

Currently there is an ongoing PAKE selection process in the CFRG.
According to the plan of the PAKE selection process, the CFRG chairs 
have selected a number of PAKE-related topics that require independent 
reviews from experts deeply involved in several particular areas of 
IETF work: TLS and IPsec protocols, constrained environments and privacy.


The chairs would like to announce the call for reviewers, who will be 
asked to prepare their reviews regarding one or more of the following 
topics about the nominated PAKEs:

- Convenience for usage within/together with TLS 1.3 Handshake.
*- Convenience for usage within/together with IKEv2.*
- Convenience for usage in M2M/IoT protocols (i.e., with corresponding 
constrains on hardware).
- Privacy considerations (e.g., recommendations to prevent user 
enumeration).


The experts who would like to volunteer to do such a review are kindly 
asked to choose:

1) which topics from the provided list will be considered by them;
2) whether they could prepare their reviews for
- all four balanced PAKEs,
- all four augmented PAKEs or
- all eight candidate PAKEs.

We ask each of the expert to prepare reviews for all PAKEs (or at 
least all balanced/all augmented ones) to be sure that each of the 
PAKEs will be studied from the same points of view.


*The call for reviewers will last until the 15th of August. Please 
send a message to c...@irtf.org  or 
cfrg-cha...@ietf.org , if you could help. *

Deadline for the reviews is 15th of September.

The reviews will later be provided to Crypto Review Panel experts, who 
will prepare their overall reviews during Stage 5.


Best regards,
Stanislav Smyshlyaev,
CFRG Secretary

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


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

Re: [IPsec] Quantum Resistant IKEv2

[Dan Harkins]

  Hi Michael,

On 2/13/17 11:06 AM, Michael Richardson wrote:

Paul Wouters  wrote:
 >> Michael Richards also suggested we attempt to address how to
 >> distribute the PPKs.  However, I would agree with Valery Smyslov; this
 >> is out
 >> of scope for this document; for example, the current IKE RFC allows
 >> preshared secrets, and does not address how to distribute them.

 > I agree. If we address how to distribute PPK's we would have basically
 > created META-IKE.

I'm specifically asking that we agree on some simple things.
Like that they be written in hex, or bubble-babble, or base64, etc.
Simple stuff so that we can get a PPK from one machine (via sneaker-net) to
another machine without needing to write some perl to convert.

  Think of whom you're trying to protect against. The first to have a 
QC are
most likely nation-states that you really aren't too happy with today 
and will

most likely be less happy with in 20 years. If we have some specification on
using sneaker-net with hex or bubble-babble or base64, etc that's what's 
gonna
be deployed and it's gonna be the weakest link in this scheme. I dare 
say that

your sneaker-net would need to be protected by men with guns that you trust
implicitly driving armored cars to come close to the security you think 
you're

getting by mixing the PSK into the keying material.

  On top of that, I think it would be good to try and make sharing the PSK
as difficult as possible. If there are > 1 people running around with a 
group

PSK then successfully breaking into the computer of one of them will void
the security the I-D is providing for the entire group. If we make it easy
to share that will be the first thing that will be done. A sneaker-net
compatible flat file would encourage the laziest and least secure behavior.

  PKIX defined a symmetric key package and it has many options to securely
wrap an arbitrary symmetric key, or many symmetric keys in a package. It can
also include a key id to use when describing the symmetric key. We 
should look
at something like that. It's ASN.1 and everyone hates ASN.1 but an 
alternative

could be defined with JSON or something like that. The symmetric key package
can be deployed using the EST extensions that Sean Turner has proposed-- you
authenticate EST using a certificate, the EST server uses your authenticated
identity to locate your package and sends it to you. Yes it requires you to
implement a whole bunch of other stuff but I think it's worth the price 
we're

placing on the PSK.

  If you hate my idea then at least take this as an argument for declaring
the matter out of scope for the QC-resistant I-D and tackling it later.

  regards,

  Dan.

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

[IPsec] OIDs for IKE DH groups

[Dan Harkins]

  Greetings,

  Are there defined OIDs for IKE DH groups 14 to 18 (from RFC 3526)?
If so, does anyone know what they are?

  Thanks in advance,

  Dan.


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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Dan Harkins]

On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote:
>
>> On 3 Nov 2015, at 1:33 PM, Tero Kivinen  wrote:
>>
>> Yoav Nir writes:
>>> There is 1 for “RSA Digital Signature” and you can encode any hash
>>> function the you would like, but for ECDSA there is:
>>> 9 - ECDSA with SHA-256 on the P-256 curve
>>> 10 - ECDSA with SHA-384 on the P-384 curve
>>> 11 - ECDSA with SHA-512 on the P-521 curve
>>
>> Also number 3 DSS Digital Signature uses a SHA-1 hash
>>
>>> So unless you go by RFC 7427, you can’t mix and match.
>>
>> So everybody should move to use that :-)

  Yes, they should! Note that the repository uses a definite
article (and we all know which curves the authors were referring
to). So you can't do #9 with the brainpoolp256 curve, which is
sub-optimal.

> It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So
> you couldn’t fit the output of SHA-384 in there. It does work the other
> way around (SHA-256 and P-384), but I’m not sure whether that is any
> more secure than SHA-256 with P-256.

  That's why X9.62 specifies using the left-most length of
prime bits when the digest is larger than the length of the
prime. It does work. Technically you can use ecdsa-with-SHA384
and "the P-256 curve", why you would want to is a different
story.

  Odd fact: the WAPI protocol (Chinese wireless encryption and
authentication protocol) uses SHA-256 with a special Chinese
government-specified curve based on a 192-bit prime and doesn't
follow X9.62. It uses the entire 256 bit digest to calculate the
signature on the 192-bit curve. The 256-bit digest does "fit"
since the math is all mod p. The result (r,s) is properly formed
but s will be different from a standard ECDSA signature.

  Dan.



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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Dan Harkins]

On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote:
>
>> On 2 Nov 2015, at 11:44 AM, Paul Wouters  wrote:
>>
>> On Mon, 2 Nov 2015, Yoav Nir wrote:
>>
>>> P.S. Someone’s asked me off-list whether there is any IPsecME
>>> document that says not to trust SHA-1 in signatures, both AUTH payload
>>> and certificates, the way the TLS 1.3 document may end up saying for
>>> TLS. I’m wondering if RFC4307bis might be the place for this, in
>>> particular the signature in AUTH payload. Just something to think about
>>> before we bikeshed.RFC4307bis Bikeshedding Session.
>>
>> We should have text to clarify the difference of algorithm use in
>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH
>> processing crypto restrictions don't beling in 4307bis.
>
> I think we do need some kind of statement along the lines:
>  - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says
> “SHOULD use SHA-1” and this is a document from only last year…)
>  - Don’t use DSS because that is only defined with SHA-1.
>  - With ECDSA no need to specify because each curve comes with a hash

  Do you mean each _signature_ comes with a hash because you can
use different hash algorithms to sign with any given curve. X9.62 in
section 7.3, under Actions subsection e sub 1, even specifies what
to do if the hash function used in the signature produces a digest
that is greater than the length of the prime used in the curve
definition-- namely, take the left-most length of prime bits of the
digest to construct intermediate variable E.

  Dan.

>  - PSK is fine because you are using a PRF.
>  - With anything else, don’t use any hash weaker than SHA-256.
>
> If not here, where does this advice go?
>
> Yoav
>
> ___
> 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] PSK mode

[Dan Harkins]

https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

  "CSfC deployments involving an IKE/IPsec layer may use RFC
   2409-conformant implementations of the IKE standard (IKEv1)
   together with large, high-entropy, pre-shared keys and the
   AES-256 encryption algorithm.  RFC 2409 is the only version
   of the IKE standard that leverages symmetric pre-shared keys
   in a manner that may achieve quantum resistant confidentiality."

  :-)

  Dan.





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

Re: [IPsec] everything old is new again

[Dan Harkins]

  And of course by, "does this implicit construction imply some
kind of concatenation…" I don't mean concatenation at all. I
mean some sort of chopping off 32 bits. Sorry for the confusion.

  Dan.

On Mon, March 16, 2015 4:37 pm, Dan Harkins wrote:
>
>   Hello,
>
>   I'm leaving too early to attend the ipsecme meeting at IETF 92
> but I notice that draft-mglt-6lo-aes-implicit-iv is on the
> agenda as "other documents".
>
>   The idea of using an implicit IV was brought up in the IPsec WG
> back in 1997 and rejected (yes, this was just for CBC mode but
> that's because CCM and GCM were not designed yet). Why is
> this a good idea now?
>
>   The "unpredictable"-ness of an IV for CBC mode addresses a
> chosen plaintext attack that would otherwise reduce CBC mode
> down to ECB mode (and enable a codebook attack). I _think_
> the draft addresses this because the IV ends up being secret
> but that requires reading a bit into section 4. Namely, does one
> take the "clear text payload" as plaintext and the "dedicated 16
> byte key" as the key for a single ECB-style encryption using AES?
> It says there's a payload and a key and it says AES is used as
> a PRP but no normative text to say exactly what to do to get
> this IV.
>
>   Also, if that is the way the IV is (secretly) generated then does
> this propose using a 128-bit IV, the block length of AES, for GCM?
> Most implementations use the default 96-bit IV so does this
> implicit construction imply some kind of concatenation or does
> it propose to use a 128-bit IV with GCM? SP 800-38D describes
> an RBG-based IV construction, is that what this draft is doing?
>
>   As an aside, the Security Considerations of this draft need work.
> It says that IV generation "has been left to the implementation as
> long as certain security requirements are met." What are they? Do
> the different modes have different requirements?  Are these
> requirements met by this draft? If so, how?
>
>   regards,
>
>   Dan.
>
>
>
> ___
> 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] everything old is new again

[Dan Harkins]

  Hello,

  I'm leaving too early to attend the ipsecme meeting at IETF 92
but I notice that draft-mglt-6lo-aes-implicit-iv is on the
agenda as "other documents".

  The idea of using an implicit IV was brought up in the IPsec WG
back in 1997 and rejected (yes, this was just for CBC mode but
that's because CCM and GCM were not designed yet). Why is
this a good idea now?

  The "unpredictable"-ness of an IV for CBC mode addresses a
chosen plaintext attack that would otherwise reduce CBC mode
down to ECB mode (and enable a codebook attack). I _think_
the draft addresses this because the IV ends up being secret
but that requires reading a bit into section 4. Namely, does one
take the "clear text payload" as plaintext and the "dedicated 16
byte key" as the key for a single ECB-style encryption using AES?
It says there's a payload and a key and it says AES is used as
a PRP but no normative text to say exactly what to do to get
this IV.

  Also, if that is the way the IV is (secretly) generated then does
this propose using a 128-bit IV, the block length of AES, for GCM?
Most implementations use the default 96-bit IV so does this
implicit construction imply some kind of concatenation or does
it propose to use a 128-bit IV with GCM? SP 800-38D describes
an RBG-based IV construction, is that what this draft is doing?

  As an aside, the Security Considerations of this draft need work.
It says that IV generation "has been left to the implementation as
long as certain security requirements are met." What are they? Do
the different modes have different requirements?  Are these
requirements met by this draft? If so, how?

  regards,

  Dan.



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

Re: [IPsec] Charter review

[Dan Harkins]

On Fri, November 7, 2014 12:03 am, Yaron Sheffer wrote:
> 
>
> Regarding formal security proofs, I strongly disagree.
>
> The current wording is extremely mild. It does not require an actual
> security proof (which would not be realistic), but says "The solution
> should be in line with current best practices, including ... possible
> formal protocol security proofs."
>
> This to me means that people have looked at the modified protocol and
> can say that the new stuff does not inhibit such a security proof in the
> future, and that we formally understand the security properties that are
> supposed to be provided by the protocol.
>
> We are making a major change to IKE, and as much as I care about its
> goals, we should try to do it right. Relying on "the security afforded
> by DH" is not easy when in the real world, both peers might be reusing
> exponents and/or using too short DH groups.

  This "major change" is to remove authentication. Peers reusing
exponents is already entirely permissible in IKE. Authenticating a
reused exponent does not change the problem caused by reusing
an exponent. I don't even know what "too short DH groups" are but
if you can do it in IKE with authentication then what's the issue that
is introduced when you take away authentication?

  I welcome the new interest in formal security proofs in the IETF but
I don't think this particular charter change compels one.

  regards,

  Dan.



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

Re: [IPsec] Charter review

[Dan Harkins]

On Tue, November 4, 2014 7:21 pm, Brian Weis wrote:
> On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty
>  wrote:
>
>> Hi,
>>
>> The chairs provided text for an updated charter in line with the newly
>> adopted working group items.  The recharter text has been posted and
>> I'd like to give the WG a little time to comment prior to adding this
>> to a telechat for review.
>
> I support the work item looking at defending against DDoS, and have no
> objection to the opportunistic work item (after omitting the wording on
> channel binding).

  +1

  How about we also get rid of the mention of a formal security proof
of opportunistic encryption? The security is just that afforded by D-H.

  Dan.

> Brian
>
>>
>> Here is a link:
>>
>> http://datatracker.ietf.org/doc/charter-ietf-ipsecme/
>>
>> Thanks.
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> --
> Brian Weis
> Security, Enterprise Networking Group, Cisco Systems
> Telephone: +1 408 526 4796
> Email: b...@cisco.com
>
> ___
> 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] new version of IKEv3

[Dan Harkins]

  Hello!

  I've updated IKEv3 and the new version has been posted (see below).
Major changes are:

  * support for NAT-T (which is different than the way it was done in
 prior versions of IKE, please take a look at it).
  * addressing the MiTM attack Valery Smyslov brought up on the list.
  * allowing more than one IKE SA per peer (which was kind of necessary
 to support NATs).

  I look forward to hearing any comments or issues people have with
this protocol. As usual, if you plan on implementing it and would like
to interoperate I'd love to hear from you.

  regards,

  Dan.

--

A new version of I-D, draft-harkins-ikev3-01.txt
has been successfully submitted by Dan Harkins and posted to the
IETF repository.

Filename:draft-harkins-ikev3
Revision:01
Title:   The (Real) Internet Key Exchange
Creation date:   2013-04-12
Group:   Individual Submission
Number of pages: 43
URL:
http://www.ietf.org/internet-drafts/draft-harkins-ikev3-01.txt
Status:  http://datatracker.ietf.org/doc/draft-harkins-ikev3
Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-01
Diff:http://www.ietf.org/rfcdiff?url2=draft-harkins-ikev3-01

Abstract:
   The current version (v2) of the Internet Key Exchange failed to
   address many of the shortcomings of the original version (v1).  This
   memo defines a new version (v3) of the Internet Key Exchange that
   attempts to do so.


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

Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks

[Dan Harkins]

  Hello,

  I think it looks fine and I have a nit that the authors can ignore
if they like.

  I don't like the fact that RFC 5903 does not list a specific value for
"a" in the parameter set definition and instead just says -3 in the
equation for the curve. This draft does the same sort of thing in
Section 2.3 by saying, "for groups 19, 20, 21,  a=-3, and all other
values of a, b and p for the group are listed in the RFC." Which to
me sounds like it's the same value: minus three.

  Note that RFC 5114 also defines these groups but lists the proper
(to me) value for "a". It's probably not right to just refer to RFC 5114,
especially since RFC 5903 is listed in the repository for those curves,
so my nit would be to change it to "for groups 19, 20, and 21,
a = -3 mod p, and for all other values" just to let the reader who
might not be so familiar with the topic know that "a" is not the same
for each curve.

  This is a good draft and I'm glad it was written.

  regards,

  Dan.

On Mon, April 8, 2013 2:46 pm, Paul Hoffman wrote:
> [[ So far, we have received only *one* review of this document, from Tero.
> If we don't receive more reviews, the document might not progress due to
> lack of interest. Please review this document within the next week and
> contribute your review to the list. ]]
>
> Greetings. This is the start of the WG Last Call for
> draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on
> April 15. The current draft is available at
> http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01
>
> Given that this will be a Standards Track document, it is important for it
> to be reviewed by as many people as possible. Possible results of
> individual reviewing the document are:
>
> - "Looks fine, please publish"
>
> - "Looks fine, here are some comments"
>
> - "Has some problems, here they are"
>
> - Other things of that sort
>
> Many people on this mailing list are IPsec implementers but are mostly or
> completely silent on the mailing list. If you are one of those people,
> doing a WG Last Call review is a good way to participate usefully in the
> WG. Please strongly consider (a) reading the current draft and (b) sending
> a message to the list with your short or long review. If there are too few
> reviews on this document, we could get pushback from the IESG about the
> document.
>
> --Paul Hoffman
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

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

Re: [IPsec] IANA ikev2 registry and FC values

[Dan Harkins]

  Hello,

On Thu, January 17, 2013 10:23 am, Yaron Sheffer wrote:
> I agree that sharing registries with related but different protocols is
> not a good thing. I just think this is not one of these cases.

  I agree that this is not the case but sharing registries should not
be a problem. We use OIDs all the time with different protocols.
The problems arise when a group of people attempts to impose
administrative rules on protocol use and say that some completely
legitimate technical application is prohibited for the simple reason
that they say it is.

  Dan.

> Thanks,
>   Yaron
>
> On 01/17/2013 08:13 PM, Tero Kivinen wrote:
>> Yaron Sheffer writes:
>>> OTOH your proposal would mean one more difference between "regular"
>>> IPsec implementations and FC-specific ones. I don't think that would be
>>> a good thing.
>>
>> FC-specific ones are only using these non-truncated ones, and they are
>> using special ID payloads, separate protocol ID values, different
>> types of traffic selectors etc. They are reusing the basic IKEv2
>> protocol, and some of the payloads, but it is different protocol than
>> IKEv2.
>>
 They are not defined for IP use at all. None of the IKEv2/ESP over IP
 uses those values. Ah, found text from our IPsec/IKE Roadmap:

   For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry
  contains values for both the truncated version and the standard
 non-
  truncated version; thus, IKEv2 has the capability to negotiate
 either
  version of the algorithm.  However, only the truncated version is
  used for IKEv2 SAs and for IPsec SAs.  The non-truncated version
 is
  reserved for use by the Fibre Channel protocol [RFC4595].  For
 the
  other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and
 HMAC-
  RIPEMD), only the truncated version can be used for both IKEv2
 and
  IPsec-v3 SAs.

 which actually says we always use truncated version (so I was wrong
 they are not forbidden anywhere, missed this text last time as it uses
 SHA-1 spelling not SHA1, which I was searching for :-).

>>>
>>> This text is simply describing the existing situation. It is not at all
>>> normative.
>>
>> Which is why I also want to describe that existing situation in the
>> IANA registry. If you want to use those non-truncated versions in
>> IPsec, you can write draft describing that...
>>
 That is true, and I do not consider that as a good thing. It is much
 better to have one good way of doing things than two ways of doing
 same thing, especially if those two ways are about the same.

>>>
>>> Yes, but people have good reasons to add algorithms, which is (part of
>>> the reason) why we negotiate them in the protocol. Thus "Tiger",
>>> "camellia" and the like, and I'm sure the FC folks had a good reason
>>> for
>>> the untruncated algorithms, too.
>>
>> They had some reason, but on the other hand IPsec people did not want
>> those untruncated algorithms, and have not specified them for IP use.
>> This is one of the problems when sharing registries causes problems.
>> Suddenly you might have options for protocols which did not request
>> them added to them, because someone else who shares the same registry
>> added them.
>>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] IANA ikev2 registry and FC values

[Dan Harkins]

  Hello,

On Thu, January 17, 2013 9:03 am, Tero Kivinen wrote:
> I got question now about the values allocated for the "IKEv2 in the
> Fibre Channel Security Association Management Protocol" and their use
> in the normal IPsec use over IP. This question was about support for
> AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of
> using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values
> everybody in IP world are using. When those values were allocated it
> was assumed that they were only to be used in the FC world.
>
> I noticed that when all other RFC4595 allocated numbers have FC_ in
> their names, but these AUTH_* does not have those. Also there is
> nothing that explictly forbid their use in the IKEv2/ESP over IP, it
> has been implicit because there is nothing that says they can be used
> in the IP world either.
>
> One of the reasons for these is that this allocation happened when we
> had this process flaw and those drafts never came to the IANA expert
> for review (i.e. to me), so I only did some early comments to their
> -00 draft, and then later noticed that the values had been added to
> the registry.
>
> To clear up this confusion, I would like to add note to the IANA table
> saying "Only for Fibre Channel use" for those two values.
>
> Does anybody have any objections for doing that?

  I don't actually see what the problem is that this note would solve.
Unless there's a problem then I have an objection to adding this note.
Can you restate the problem?

  Dan.



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

[IPsec] ID on adding Brainpool ECC curve's to RFC2409's registry

[Dan Harkins]

  Hello,

  At the Security Area Directorate's lunch at IETF 84 it was agreed that I
would write up an I-D to assign code points for brainpool elliptic cubes
to the registry created by RFC 2409 as a way of addressing a liaison
request from another SDO. Even though this is not an IPsecME working
group issue there has been a little discussion on this list about this
draft. We'd like to go to IETF LC on it soon so if you care about this topic,
please take a look at:

 http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-03

and if you have an issue with it, please comment.

  regards,

  Dan.



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

Re: [IPsec] New draft on IKE Diffie-Hellman checks

[Dan Harkins]

On Thu, December 13, 2012 7:57 am, Scott Fluhrer (sfluhrer) wrote:
>
>> -Original Message-
>> From: Johannes Merkle [mailto:johannes.mer...@secunet.com]
>> Sent: Thursday, December 13, 2012 5:41 AM
>> To: Scott Fluhrer (sfluhrer)
>> Cc: Dan Harkins; Yaron Sheffer; IPsecme WG
>> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
>>
>> > I'm positing an audience of people who know little about elliptic
>> curves;
>> they have no idea about what a cofactor or a Sophie-Germain prime is.
>> All
>> they're interested in is trying to implement this protocol in a secure
>> manner, and want to dig into the mathematical details as little as
>> possible.
>>
>> Why not keeping the main document general and giving details for
>> registered groups in an appendix?
>
> H, I like that suggestion.

  That's a great suggestion. Yaron also mentioned the idea of adding
a note column to the DH group repository that references the particular
section of your draft (instruct IANA to update the registry with the section
and the RFC number that gets assigned to your draft). I think both of
those would be good.

> Here's what I'm wrestling with; every curve that we currently support
> (and, in fact, every prime curve I've heard anyone suggest) has h=1
> (having h>1 makes the discrete log problem be a factor of sqrt(h) easier,
> for no benefit that I can see); hence, this cofactor test is moot.  So, do
> we complicate our description (at least, of the prime curve section) with
> a test that never really applies?

  Maybe not. It might make sense to say that all the curves have an
implied co-factor of 1 though.

> Now, if we do have a section covering even characteristic curves, those
> have h>1 (the math pretty much forces that), and so a discussion there
> wouldn't be entirely out of place.  On the other hand, there are
> standardized ways of defining the ECDH operation so that the cofactor
> doesn't cause any leakage ("ECC CDH", where the shared secret really is
> hxyG); if the group is defined using that primitive, such a cofactor test
> beforehand is unneeded.  Will such a group use such a modified DH
> operation?  Well, given that no such groups are currently defined, we
> can't say.
>
> My opinion: in the prime curve section, there's no reason to mention a
> cofactor; and that it's premature to put in an even characteristic curve
> section.

  OK, I agree with the former, but why not just cover all the possibilities
by  mentioning the characteristic curves? It's supposed to be a forward-
looking document that's placing requirements on future RFCs that add
new groups and there's no reason why someone couldn't add such a curve.
I think it would be cleaner to have everything covered here instead of
having this one mention 3 of 4 and another RFC mention the 4th.

  Dan.


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

Re: [IPsec] New draft on IKE Diffie-Hellman checks

[Dan Harkins]

On Tue, December 11, 2012 1:36 pm, Dan Brown wrote:
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Dan Harkins
>> Sent: Tuesday, December 11, 2012 4:32 PM
>> To: Dan Harkins
>> Cc: IPsecme WG
>> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
>>
>>
>>   I made a mistake below. Thanks to Dan Brown for pointing it out.
>>
>> On Tue, December 11, 2012 10:06 am, Dan Harkins wrote:
>> [snip]
>> >   - I think it should be mentioned that elliptic curve groups
>> >  have a co-factor, h, and if h > 1 that a further check is
>> >  also required, namely, if the x- and y-coordinates define
>> >  a point Q then ensure that:
>> >
>> >hQ = point-at-infinity
>> >
>> >  Add this check to both 2.3 and 2.4. Of course if h=1 then this
>> >  check can be skipped.
>>
>>   The check should be hQ != point-at-infinity. An equivalent check
>> could be nQ = point-at-infinity where n is the order of the group
>> formed by the generator, G.
>>
> [DB] Well, the hQ != infinity check is insufficient for security, and not
> equivalent to ensuring that nQ=infinity.
>
> Dan, sorry, I did not explain these details in my response to you.

  That's interesting. Your paper "Validating EC Public Keys" (Antipa,
Brown, Menezes, Struik and Vanstone) says in section 3 that the
steps to validate an EC public key, W=(xw, yw), are:

  1. W != infinity
  2. xw and yw are properly represented elements of the finite field
  3. W satisfies the defining equation of the curve; and
  4. nW = infinity

It then says that "if h=1, then condition 4 is implied by the other
three conditions. In some protocols the check that nW = infinity may
either be embedded in the protocol computations or replaced by the
check that hW != infinity."

  Can you explain why hQ != infinity is insufficient and not equivalent
to nQ = infinity?

  thanks and best regards,

  Dan.


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

Re: [IPsec] New draft on IKE Diffie-Hellman checks

[Dan Harkins]

  I made a mistake below. Thanks to Dan Brown for pointing it out.

On Tue, December 11, 2012 10:06 am, Dan Harkins wrote:
[snip]
>   - I think it should be mentioned that elliptic curve groups
>  have a co-factor, h, and if h > 1 that a further check is
>  also required, namely, if the x- and y-coordinates define
>  a point Q then ensure that:
>
>hQ = point-at-infinity
>
>  Add this check to both 2.3 and 2.4. Of course if h=1 then this
>  check can be skipped.

  The check should be hQ != point-at-infinity. An equivalent check
could be nQ = point-at-infinity where n is the order of the group
formed by the generator, G.

  regards,

  Dan.


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

Re: [IPsec] New draft on IKE Diffie-Hellman checks

[Dan Harkins]

  Hello,

  I have a few comments.

  - The Introduction says that "It turns out using EC groups in
 some scenarios require...additional tests. This document
 defines these tests." Well the memo is defining more than
 EC. I think the Intro should introduce us to the why, which
 is sort of mentioned in the next section. It would be better
 to state in the Intro that the memo is defining group
 membership tests to apply to DH values received during
 IKEv2. Then let section 2 have normative text for what's
 REQUIRED and what's RECOMMENDED and set up the reason
 for the sub-sections-- i.e. different kinds of DH groups have
 different kinds of group membership tests.

  - The IANA considerations imply that this is placing requirements
 on future RFCs. That being the case, I think the subsections
 of section 2 should not be so group-number-specific, e.g.
 today's group numbers should not be in the subsection titles.
 I'd suggest:

 2.1 MODP Groups Based on Sophie-Germain Primes
 2.2 MODP Groups With a Small Sub-Group
 2.3 Elliptic Curve Groups Over a Prime Finite Field

 and then in each of them you say what the group membership
 test is and only then say that as of publication of this memo
 the following groups are covered by this section...list the group
 numbers.

 This will allow, for example, Johannes' draft to say that the
 membership tests for the groups it is defining are in section
 2.3 of RFCXYZ and that section heading won't say "groups
 19-21, 25, 26" which would be somewhat clumsy.

 Also, don't say that a=-3 in 2.3. Just say that a, b, and p are
 from the domain parameter set defining the group. I think it's
 better to just define the test, let the reader get a, b, and p.

  - I'd also suggest a sub-section like this:

 2.4 Elliptic Curve Groups Over a Characteristic-2 Finite Field

 And the check is that the x- and y-coordinates are binary
 polynomials of degree m-1 (where m is field size of the curve)
 and that:

y^2 + xy = x^3 + ax^2 + b (in GF(2^m))

 I know that the binary curves in RFC2409's registry were
 removed from the RFC5996's registry but some may be defined
 in the future and it would be good to cover all the possibilities
 now.

  - I think it should be mentioned that elliptic curve groups
 have a co-factor, h, and if h > 1 that a further check is
 also required, namely, if the x- and y-coordinates define
 a point Q then ensure that:

   hQ = point-at-infinity

 Add this check to both 2.3 and 2.4. Of course if h=1 then this
 check can be skipped.

  - Let IANA know what registry these new requirements are
 being place on. It says, "The groups mentioned here are managed
 by IANA." I suggest adding "in [IKEV2IANA]." and add the following
 in the References:

 [IKEV2IANA] Internet Assigned Numbers Authority, "Internet Key
Exchange Version 2 (IKEv2) Parameters", Transform
Type 4-- Diffie-Hellman Group Transform IDs.

  regards,

  Dan.

On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote:
> Hi,
>
> following the recent discussion on the mailing list, Scott Fluhrer and
> myself just published a draft that updates RFC 5996 by adding the
> required recipient-side tests for ECDH. Please see
> http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt.
>
> We have not addressed the issues raised by Dan and Tero regarding
> inconsistencies between various RFCs that define ECDH groups for IKE. I
> personally deem these issues to be out of scope of the current document.
>
> Comments are very welcome.
>
> Thanks,
>  Yaron
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

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

Re: [IPsec] New draft on IKE Diffie-Hellman checks

[Dan Harkins]

  Hello,

On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote:
> Hi,
>
> following the recent discussion on the mailing list, Scott Fluhrer and
> myself just published a draft that updates RFC 5996 by adding the
> required recipient-side tests for ECDH. Please see
> http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt.
>
> We have not addressed the issues raised by Dan and Tero regarding
> inconsistencies between various RFCs that define ECDH groups for IKE. I
> personally deem these issues to be out of scope of the current document.

  If you're planning on updating a standards-track product of this working
group then isn't it up to the group to decide whether they want to tackle
various issues?

  Dan.


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

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

[Dan Harkins]

On Fri, November 30, 2012 1:03 pm, Yaron Sheffer wrote:
> The problem I have with this discussion is, this check (if really
> required) should have been in the base protocol, because the protocol
> has supported EC groups from day one. It doesn't belong in a specific
> curve definition. We could use the errata process to add it. It's not
> ideal, but certainly better than republishing RFC 5996.

  Yes, this check is required for the reasons Scott explained.

  I think "the protocol has supported EC groups from day one" is a
bit of an overstatement. EC support was poorly defined as the protocol
says that g^ir is the shared secret and it's an octet string. That's it.
Many people who were familiar with ECDH assumed that, when doing
ECDH, that octet string is just the x-coordinate of the point that
results from completing the exchange. (Note: it's bad for protocols
to leave it up to the reader to assume).

  Then along came RFC 4753 that said the concatenation of the x-
and y-coordinates (in that order) was the thing that was "used in the
formation of SKEYSEED." Well that screwed up all the people who
(rightly) assumed that it was just the x-coordinate. This was realized
a bit late so now we have RFC 5903 which obsoletes RFC 4753 that
says the ECDH shared secret is the x-coordinate. Unfortunately,
RFC 5114 adds two more ECP groups-- 25 and 26- but says that
the format of the shared secret for them is per 4753, i.e. the wrong
way. And RFC 5114 has not (yet) been obsoleted to fix that.

  So we can have an IKEv2-compliant implementation from prior to
June 2010 that will not interoperate with an IKEv2-compliant
implementation after June 2010. And to be a truly RFC-compliant
implementation it would mean that you represent the ECDH shared
secret differently for P256 and P224. Yuck, what a mess. A recipe
for spagetti code.

  RFC 5996 followed this mess but did nothing to specify what is
the right behavior for ECDH while it was obsoleting RFC 4306.

  While I tend to agree that specification of this critical issue should
not be left to the RFC that defines the curve that horse has already
left the barn for IKEv2. As far as republishing RFC 5996 is concerned,
I think a better approach would be to acknowledge that interoperability
is problematic with IKEv2 and there's not much we can do about it now,
so the best way to proceed is to obsolete it before it gets traction in
the field. And I know a draft that can do just that!

  regards,

  Dan.

> Thanks,
>   Yaron
>
> On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote:
>> There should *absolutely* be a requirement that any point you receive
>> from the peer is actually a point on the curve.
>>
>> What can happen if you don't?  Well, that depends on the implementation
>> of the point addition/doubling; what happens with the normal
>> implementation is that it acts as if it was a different curve with a
>> different curve order -- this means that someone introducing a bogus
>> value can give us a point with a small order (which can't happen with
>> the normal Brainpool curves, because those curves have prime orders).
>>
>> In addition, validating the values is cheap; easily worth the gain.
>>
>>
>> Also, given the you validate the peer's value, and forbid public points
>> which are the point-at-infinity, doubling checking that the D-H common
>> value is not the point at infinity appears to be unneeded.  The
>> Brainpool Curves are (again) of prime order; this implies that the D-H
>> common value is the point at infinity only if the peer's public value is
>> the point at infinity (which ought to be forbidden), or our secret value
>> is a multiple of the curve order (in which case, our public value is the
>> point at infinity).
>>
>>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Dan Harkins
>> Sent: Friday, November 30, 2012 12:57 PM
>> To: Johannes Merkle
>> Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-...@rfc-editor.org
>> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key
>> Exchange
>>
>>
>>Hi Johannes,
>>
>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>>> We have submitted a new revision of the Internet Draft on Using the
>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>>>
>>> Since there was considerable objection to the point compression method
>>> in the WG, we have removed this option altogether and define only the
>>> uncompressed KE payload format, which is in full accordance with

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

[Dan Harkins]

  Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
> We have submitted a new revision of the Internet Draft on
> Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key
> Exchange
> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>
> Since there was considerable objection to the point compression method in
> the WG, we have removed this option altogether
> and define only the uncompressed KE payload format, which is in full
> accordance with RFC 5903.
>
>
> Any feedback is welcome.

  I see that there is a requirement that an implementation MUST verify
that the D-H common value is not the point-at-infinity. Do you think
there should also be a requirement that an implementation MUST verify
that the x- and y-coordinates received from a peer satisfy the equation
of the negotiated curve (and abort the exchange if not)?

  regards,

  Dan.


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

Re: [IPsec] Question about IKEv1 and ECDSA

[Dan Harkins]

  Hello,

On Wed, November 28, 2012 12:07 am, Yoav Nir wrote:
> Hi
>
> I know we don't like IKEv1 questions, but RFC 4754 does mention it, so
> here goes. And sorry if this has been discussed before. I couldn't find
> it.

  What do you mean "we"? :-)

> In IKEv1 the authentication method is negotiated as an SA parameter. So
> presumably the Initiator proposes RSA signatures, ECDSA with the P-256
> curve, etc, and the Responder chooses one of them. This happens in packets
> #1 and #2.
>
> Later the certificate to actually present (in packets #5 and #6) is chosen
> based on a Certificate Request payload, and availability. This is
> different from IKEv2, where authentication method is implied by the
> certificates rather than negotiated.
>
> So two questions:
> 1. Is it impossible to have one peer authenticate with RSA while the other
> authenticates with ECDSA, or even to mix curves?  Or am I missing
> something?

  No, they both have to do ECDSA. The way that ECDSA was added to IKEv1--
make it bound to the curve-- was unfortunate. That means that you can't
really mix curves either after agreeing to do ECDSA with one particular
curve. It would have be much more useful to divorce the curve from the
willingness to do ECDSA. But oh well.

> 2. What if an IKE endpoint has >1 certificates, but the one best-suited
> for the certificate request has a different type key than the one agreed
> to in packet #2?

  Tough luck. You agreed to ECDSA with a particular curve and that's what
you go with.

> If I'm not missing something, it seems like IKEv1 is the wrong vehicle for
> the gradual introduction of ECDSA.  I'm not proposing to fix it, just
> trying to understand.

  It should work in the general case but you have pointed out some
conditions that make it somewhat suboptimal. I believe the ECDSA tiger
team has properly addressed these issues for IKEv2. Please speak up
if you disagree.

  regards,

  Dan.


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

Re: [IPsec] New I-D on IKEv3

[Dan Harkins]

  Hi Valery,

On Wed, November 7, 2012 10:18 pm, Valery Smyslov wrote:
> Hi Dan,
>
> I suspect the IKEv3 in its current form is susceptible to very simple DoS
> attack.
> Suppose we have Alice, Bob and Malory. Alice wants to communicate with
> Bob,
> Malory wants to not allow her to do it. For this Malory sends INIT packet
> to
> Bob
> pretending to be Alice (this packet may have fake or real Alice's source
> IP).
> Bob's state machine transfers to Reception state and Bob replies back
> to what he thinks is Alice. This reply packet either goes to nowhere
> (if IP is fake) or get dropped by Alice according to 6.1.1.2 first bullet.
> Now Malory has achived his goal - untill TM event happens and
> Bob's state machine returns back to Nothing state, Bob will
> discard any INIT packet from real Alice according to 6.1.1.2 second
> bullet.
> What Malory needs to do - infrequently send such INIT packets and
> Alice will have almost no chance to communicate with Bob.

  That is a very good point. It makes me want to do away with the
SPI since it really serves no purpose in IKEv3.

> I think the root of this susceptibility is in the draft's intention to
> have
> only one
> instance of IKEv3 protocol running between two peers, even before
> peer is authenticated or, at least, confirmed her ability to
> participate in IKEv3 (for example by COOKIE exchange).

  Once the peer is authenticated the SA goes away so there is really
only 1 nascent SA between 2 peers, once it's done it's job it goes away.

> Another thing (among others that have been already mentioned by other
> people)
> that I think decreases protocol usability - the lack of error
> notifications.
> If something goes wrong (due to misconfiguration, etc.) peers never
> report the problem to each other, so protocol will try to retransmit for
> quite
> a long time before some recovery actions could be done
> (for example switch to another peer).

  What errors would you like to receive? If you don't like my attribute
assertion do you want to tell me why? I'm sure that can be handled
by sending an error message and going away. What if you fail to
authenticate me? Do you feel compelled to tell me that I failed? What
else would you like to see?

  Thanks for looking at IKEv3 and I hope you will take a look at the -01
version.

  regards,

  Dan.




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

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

[Dan Harkins]

  Hi Derek,

On Wed, November 7, 2012 10:27 am, Derek Atkins wrote:
> Hi,
>
> On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote:
>> Hi David,
>>
>> Point compression is simply the ommission of the x-value, and for point
>> expansion, functions are included in OpenSSL and
>> other crypto libraries. Thus, such mistakes should only occur if someone
>> decides to implement the arithmetic by itself
>> but is incapable of doing it correctly (and does not perform sufficient
>> testing). This seems to me a quite a case of
>> carelessness and I don't think, that an RFC should be so fool-proof to
>> prevent that. There are certainly much more
>> complex aspects in IKE than point compression.
>
> You're making the assumption that an implementor is using OpenSSL or has
> already implemented point compression.  IMHO that is not a reasonable
> assumption.  Many implementations use their own crypto libraries and
> therefore would have to implement these compression and expansion
> functions, including all the potential errors thereto.  So saying "it's
> easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument.

  Decompression is just a square root and a discriminator to say whether
the result is y or -y. All the brainpool curves are of the form p mod 4 = 3,
where p is the prime defining the curve. For such curves the square root
of n would be n^((p+1)/4) mod p. This is straightforward to implement
with any big number library.

  regards,

  Dan.




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

Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt

[Dan Harkins]

On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote:
> On Nov 3, 2012, at 10:37 PM, Tero Kivinen  wrote:
>
>> A general comment: I think we already decided in the WG that we will
>> go with the tcp approach, not with this fragmentation layer in the
>> IKEv2. Why do we have this document here?
>
> We don't. Documents listed as "Related Documents" on the Datatracker page
> are just that: related. They are not WG work items.

  Can IKEv3 be added to the related documents section?

  Thanks,

  Dan.

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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Hi Michael,

On Fri, October 19, 2012 6:08 am, Michael Richardson wrote:
>
>>>>>> "Dan" == Dan Harkins  writes:
> Dan> The thing is, they're not just for 802.11. RFC 5931 uses them
> Dan> too.
>
> But, you don't use the values from the IKEv1 registry do you?
> It might use the curves themselves, but it doesn't identify them using
> the IKEv1 registry.  At least, that all I could tell where/how from
> brief reading of IANA considerations, and some searches.

  Section 3.2.1 says,

 "The Group Description field value is taken from the IANA registry
  for 'Group Description' created by IKE [RFC2409]."

That's how groups are identified, by a ushort whose value comes
out of this registry. For EAP-pwd to use brainpool curves it will be
necessary for the registry to not restrict it from using them (i.e. it
can't say "for 802.11 only").

> (ps: it's a well written security considerations)

  Thank you!

  Dan.

> --
> Michael Richardson , Sandelman Software Works
>
>
>

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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Sean,

  It was a two-part request. I'd like the IESG to follow the same process
they followed for what became RFC 5114.

  Is there a way to get an RFC published to update this registry that
does not need to go through the IESG? If not then the 2nd part is
the critical one; if so then we can just end this fiasco now.

  regards,

  Dan.

On Thu, October 18, 2012 7:58 am, Sean Turner wrote:
> Dan,
>
> There's not need to ask the IESG about the process to update the
> registry in question it's clear: RFC required.  You can get an RFC
> through a WG, through an AD, or through the ISE.
>
> spt
>
> On 10/15/12 10:54 PM, Dan Harkins wrote:
>>
>>Hi Sean,
>>
>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote:
>>>
>>> On 10/12/12 2:32 AM, Dan Harkins wrote:
>>>>
>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
>>>>>
>>>>> I'm going to run my proposal and Michael's by the IESG on an informal
>>>>> telechat to see which one's got the best chance of getting through
>>>>> the
>>>>> process to resolve the IEEE's request.
>>>>
>>>> Can you ask the IESG to just do what it has done in the past? That
>>>> is,
>>>> just update the registry to include code points for new curves without
>>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows
>>>> in a table.
>>>>
>>>> The worst that could happen if the IESG agrees to do that is that
>>>> someone
>>>> somewhere might use a brainpool curve with IKEv1. The odds are slim,
>>>> but they're not zero. And if that happens then so what? Really. So
>>>> what?
>>>
>>> The RFC 5114 example wasn't published to address another SDO request
>>> for
>>> a code point so I don't think it's the same situation.
>>
>>That's certainly a distinction but I don't see how that matters. You
>> could also
>> note that RFC 5114 added MODP groups as well as ECP groups. Also a
>> distinction that really doesn't matter.
>>
>>Again, the SDO request is a _by-product_ of the opposition to just
>> letting
>> Johannes' draft update the registry. It is this same opposition that is
>> creating
>> these problems about notes and pointers and the concern over whether
>> they
>> will have the desired effect and what we should do to ensure they do. If
>> this
>> opposition had not materialized there never would've been another SDO
>> request.
>>
>>It is the same situation, indulge me here a bit:
>>
>>What we had was another organization (NIST) came up with some new DH
>> groups and there was a proposal to add them to both IKEv1 and IKEv2
>> registries. And now, quite similarly, there's another organization (the
>> ECC
>> Brainpool) that came up with some new DH groups and there was a proposal
>> to add them to both IKEv1 and IKEv2 registries.
>>
>>When the proposal was made to add the NIST groups to the IKEv1
>> registry there was no hullabaloo over updating a deprecated protocol's
>> registry and there was no concern that someone somewhere might use
>> the NIST groups with IKEv1.
>>
>>But when Johannes made his proposal to add the ECC Brainpool curves
>> to the IKEv1 registry there was all of a sudden a hullabaloo and much
>> concern that someone somewhere might use the ECC Brainpool groups
>> with IKEv1.
>>
>>So my request to you is to ask that the IESG consider what the
>> process
>> defined for updating this registry is (it's RFC required) and to note
>> that
>> there is precedence to update the registry of this deprecated protocol.
>> So please ask the IESG to just approve a draft (either Johannes' or
>> mine)
>> for publication as an RFC to update this registry in the same manner
>> that
>> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense).
>>
>> Then there'd be no need for the IESG to have a discussion about the
>> (de)merits of notes and pointers in registries and how best to ensure
>> that
>> no one nowhere ever even thinks about using an ECC Brainpool curve in
>> IKEv1 and that certainly sounds like a better use of everyone's time.
>>
>>regards,
>>
>>Dan.
>>
>>
>>
>


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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Sean,

  The thing is, they're not just for 802.11. RFC 5931 uses them too.

  Dan.

On Thu, October 18, 2012 9:12 am, Sean Turner wrote:
> Dan,
>
> After talking it over the preferred* approach to answer the 802.11
> request is to include them in the IKEv1 registry (as suggested by
> Michael R.) with a tweaked note.  Rationale being that if you used what
> I suggested you'd have to make sure two registries were updated if a
> change was made to the registry at some later time. i.e.,:
>
> Value
> -
> 27
> ...
> y
>
> Group
> -
> Reserved for 802.11 Brainpool Group 1
> ...
> Reserved for 802.11 Brainpool Group n
>
> Description
> ---
> This specification
> ...
> This specification
>
> Notes
> -
> Only for 802.11 - Not for use with IKEv1
> Only for 802.11 - Not for use with IKEv1
> Only for 802.11 - Not for use with IKEv1
>
> spt
>
> * I say preferred because you can try another approach if you want.
>
> On 10/18/12 10:58 AM, Sean Turner wrote:
>> Dan,
>>
>> There's not need to ask the IESG about the process to update the
>> registry in question it's clear: RFC required.  You can get an RFC
>> through a WG, through an AD, or through the ISE.
>>
>> spt
>>
>> On 10/15/12 10:54 PM, Dan Harkins wrote:
>>>
>>>Hi Sean,
>>>
>>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote:
>>>>
>>>> On 10/12/12 2:32 AM, Dan Harkins wrote:
>>>>>
>>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
>>>>>>
>>>>>> I'm going to run my proposal and Michael's by the IESG on an
>>>>>> informal
>>>>>> telechat to see which one's got the best chance of getting through
>>>>>> the
>>>>>> process to resolve the IEEE's request.
>>>>>
>>>>> Can you ask the IESG to just do what it has done in the past?
>>>>> That
>>>>> is,
>>>>> just update the registry to include code points for new curves
>>>>> without
>>>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows
>>>>> in a table.
>>>>>
>>>>> The worst that could happen if the IESG agrees to do that is that
>>>>> someone
>>>>> somewhere might use a brainpool curve with IKEv1. The odds are slim,
>>>>> but they're not zero. And if that happens then so what? Really. So
>>>>> what?
>>>>
>>>> The RFC 5114 example wasn't published to address another SDO request
>>>> for
>>>> a code point so I don't think it's the same situation.
>>>
>>>That's certainly a distinction but I don't see how that matters. You
>>> could also
>>> note that RFC 5114 added MODP groups as well as ECP groups. Also a
>>> distinction that really doesn't matter.
>>>
>>>Again, the SDO request is a _by-product_ of the opposition to just
>>> letting
>>> Johannes' draft update the registry. It is this same opposition that is
>>> creating
>>> these problems about notes and pointers and the concern over whether
>>> they
>>> will have the desired effect and what we should do to ensure they do.
>>> If this
>>> opposition had not materialized there never would've been another SDO
>>> request.
>>>
>>>It is the same situation, indulge me here a bit:
>>>
>>>What we had was another organization (NIST) came up with some new DH
>>> groups and there was a proposal to add them to both IKEv1 and IKEv2
>>> registries. And now, quite similarly, there's another organization
>>> (the ECC
>>> Brainpool) that came up with some new DH groups and there was a
>>> proposal
>>> to add them to both IKEv1 and IKEv2 registries.
>>>
>>>When the proposal was made to add the NIST groups to the IKEv1
>>> registry there was no hullabaloo over updating a deprecated protocol's
>>> registry and there was no concern that someone somewhere might use
>>> the NIST groups with IKEv1.
>>>
>>>But when Johannes made his proposal to add the ECC Brainpool curves
>>> to the IKEv1 registry there was all of a sudden a hullabaloo and much
>>> concern that someone somewhere might use the ECC Brainpool groups
>>> with IKEv1.
>>>
>>>So my request to you is to ask

Re: [IPsec] Call for agenda items

[Dan Harkins]

On Wed, October 17, 2012 7:38 am, Paul Hoffman wrote:
> Greetings again. We have a 2-hour time slot in Atlanta, which is way more
> than we asked for. We don't need to be talking about
> draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is
> being sent to the AD for review. This is a call for agenda items. Strong
> preference is given to those which are in the WG charter.

  I would be happy to discuss IKEv3. Please let me know if you'll put me
on the agenda and I'll prepare some slides to talk to.

  Dan.

> draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully
> there will be more discussion of it before the meeting
>
> --Paul Hoffman
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] New I-D on IKEv3

[Dan Harkins]

  Hi Yoav,

On Wed, October 17, 2012 11:52 am, Yoav Nir wrote:
> Add a CFG payload to the list.

  Already noted! CFG and NAT indication.

> By the time we add all the things that we feel must be in an IKEv3, would
> it be any simpler than IKEv2?

  Yes, I believe so. Simpler, more clear, and easier to implement with a
high degree of interoperability.

  Dan.

> Yoav
>
> On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote:
>
>> Hi Dan,
>>
>> The lack or EAP authentication would be a non-starter for us to
>> implement this in our remote access VPN client.  Why not support EAP
>> authentication?
>>
>> Regards,
>> David
>>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Dan Harkins
>> Sent: Friday, October 12, 2012 7:02 PM
>> To: ipsec@ietf.org
>> Subject: [IPsec] New I-D on IKEv3
>>
>>
>>  Hello,
>>
>>  I just submitted a new I-D that defines version 3 of IKE. The goals of
>> this draft are to make a more easily understood, and simpler protocol
>> that has a high degree of probability of achieving interoperability. It
>> should be easier to read, easier to understand, and easier to
>> implement.
>> To those ends it:
>>
>>  - severely limits the negotiable parameters and options
>>  - no long-term IKE SA, it's one and done
>>  - has a simple state machine which, if followed, should ensure the
>> implementation interoperates with other implementations
>>  - is a true peer-to-peer protocol
>>
>>  Please take a look and send me your comments! If you plan on
>> implementing this protocol then definitely contact me, I want to
>> interoperate with you.
>>
>>  regards,
>>
>>  Dan.
>>
>> ---
>>
>>Filename:  draft-harkins-ikev3
>>Revision:  00
>>Title: The (Real) Internet Key Exchange
>>Creation date: 2012-10-12
>>WG ID: Individual Submission
>>Number of pages: 41
>>URL:
>> http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt
>>Status:  http://datatracker.ietf.org/doc/draft-harkins-ikev3
>>Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00
>>
>>
>>
>> ___
>> 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
>>
>> Scanned by Check Point Total Security Gateway.
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] New I-D on IKEv3

[Dan Harkins]

  Hi David,

On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote:
> Hi Dan,
>
> The lack or EAP authentication would be a non-starter for us to implement
> this in our remote access VPN client.  Why not support EAP authentication?

  What credential are you interested in using with EAP?

  Dan.

> Regards,
> David
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Dan Harkins
> Sent: Friday, October 12, 2012 7:02 PM
> To: ipsec@ietf.org
> Subject: [IPsec] New I-D on IKEv3
>
>
>   Hello,
>
>   I just submitted a new I-D that defines version 3 of IKE. The goals of
> this draft are to make a more easily understood, and simpler protocol
> that has a high degree of probability of achieving interoperability. It
> should be easier to read, easier to understand, and easier to implement.
> To those ends it:
>
>   - severely limits the negotiable parameters and options
>   - no long-term IKE SA, it's one and done
>   - has a simple state machine which, if followed, should ensure the
>  implementation interoperates with other implementations
>   - is a true peer-to-peer protocol
>
>   Please take a look and send me your comments! If you plan on
> implementing this protocol then definitely contact me, I want to
> interoperate with you.
>
>   regards,
>
>   Dan.
>
> ---
>
> Filename:  draft-harkins-ikev3
> Revision:  00
> Title: The (Real) Internet Key Exchange
> Creation date: 2012-10-12
> WG ID: Individual Submission
> Number of pages: 41
> URL:
> http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt
> Status:  http://datatracker.ietf.org/doc/draft-harkins-ikev3
> Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00
>
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] New I-D on IKEv3

[Dan Harkins]

  Hi Paul,

On Sat, October 13, 2012 2:35 pm, Paul Wouters wrote:
> On Fri, 12 Oct 2012, Dan Harkins wrote:
>
>> Subject: [IPsec] New I-D on IKEv3
>
> Some remarks
>
> - stateless IKE
>
> I like not dealing with lingering IKE SA's, but how to tell if a
> connection is dead? idletime on the IPsec SA? How to do DPD?

  That's a great question. There's alot of complexity that gets added
for IKE to deal with DPD and I'd just like to punt that to something
else. Idletime on the IPsec SAs is probably the way to do it.

> When a roadwarrior pops up at IP A, and then at IP B, etc, how do
> we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely
> and don't care about SRC/DST of the ESP packets and just send answers
> the the latest IP-port we saw?

  I think any stale SA would be cleaned up by the "something else" I
referred to above. Figuring out where to send packets may require
some linkage between outer and inner addresses when they get plumbed
into the kernel that would orphan an "old" IPsec SA (and possibly
facilitate it's cleanup).

  Which reminds me, one thing missing from IKEv3 is a "config mode".
That really needs to be there.

> - "Only one instance of the IKEv3 protocol SHALL be run at time between
> any two peers."
>
> What about NAT, I guess you do mean "peers" and not "IPs" but can we
> always tell?

  NAT detection is another thing I left out in my rush to hit the -00
cutoff date. I mean "peers" and the way we can tell is to include a
"this is what I think my address is" payload. The recipient can then
tell whether the other side is behind a NAT and disambiguate multiple
"peers" behind the same IP address to enforce the "only one instance"
requirement.

> - algorithm selection
>
> The responder can look at the initiator SPI and match up its SPI lower
> bits to give its own proposal a slight edge. Could that be problematic?

  The tie is only the case where both sides initiate simultaneously and
that happens when neither side has seen the other's offer. There
just needs to be some way to unambiguously converge on accepted
parameters.

  Of course, an implementation can receive the other side's offer and
respond as if it did not (make a tie that it will win) but a responder will
always have a slight edge because he gets to see the initiator's offer
before exposing his own. Provided that they converge on acceptable
parameters, is this a problem?

> - ID_BLOB_ID
>
> I like this! And already have a use for it
>
> - "and two Traffic Selector payloads (TS)"
>
> In IKEv2 and here I always found it very confusing to talk about
> "Traffic Selector payload" payload and the "Traffic Selector" payload.
> There should really be better terms for that.
>
> - I'm still not a fan of narrowing, see my earlier comments on ipsecme.
>It destroys the concept of a tunnel being "up" or "down". If you
>insist on narrowing, clearly state what should happen for traffic
>selectors outside the narrowed set, DROPed or ACCEPTed plaintext?
>Related: all the IKEv2 text about meaning of the first and second TS
>payload is missing (eg the src/dst of the trigger and the src/dst of
>the negiating SA). Was that intentional?

  It was not intentional to lose important information, it's just that
that section is kind of verbose and I think can be stated more succinctly.
If the IKEv3 text is missing important information, I will try to clean it
up.

> - Why still support AH?

  I have no love of AH but is it up to the key exchange protocol to
kill off an IPsec protocol?

> - What happened to NAT Traversal negotiation? back to vendorids?

  It will be in -01.

> - Should compression be disallowed?

  I am agnostic on the subject and willing to follow the will of the
group.

  Thanks alot for your comments; much appreciated.

  regards,

  Dan.


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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Hi Sean,

On Mon, October 15, 2012 5:00 pm, Sean Turner wrote:
>
> On 10/12/12 2:32 AM, Dan Harkins wrote:
>>
>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
>>>
>>> I'm going to run my proposal and Michael's by the IESG on an informal
>>> telechat to see which one's got the best chance of getting through the
>>> process to resolve the IEEE's request.
>>
>>Can you ask the IESG to just do what it has done in the past? That
>> is,
>> just update the registry to include code points for new curves without
>> any bizarre notes or pointers? No fuss, no mess, just a few new rows
>> in a table.
>>
>>The worst that could happen if the IESG agrees to do that is that
>> someone
>> somewhere might use a brainpool curve with IKEv1. The odds are slim,
>> but they're not zero. And if that happens then so what? Really. So what?
>
> The RFC 5114 example wasn't published to address another SDO request for
> a code point so I don't think it's the same situation.

  That's certainly a distinction but I don't see how that matters. You
could also
note that RFC 5114 added MODP groups as well as ECP groups. Also a
distinction that really doesn't matter.

  Again, the SDO request is a _by-product_ of the opposition to just letting
Johannes' draft update the registry. It is this same opposition that is
creating
these problems about notes and pointers and the concern over whether they
will have the desired effect and what we should do to ensure they do. If this
opposition had not materialized there never would've been another SDO
request.

  It is the same situation, indulge me here a bit:

  What we had was another organization (NIST) came up with some new DH
groups and there was a proposal to add them to both IKEv1 and IKEv2
registries. And now, quite similarly, there's another organization (the ECC
Brainpool) that came up with some new DH groups and there was a proposal
to add them to both IKEv1 and IKEv2 registries.

  When the proposal was made to add the NIST groups to the IKEv1
registry there was no hullabaloo over updating a deprecated protocol's
registry and there was no concern that someone somewhere might use
the NIST groups with IKEv1.

  But when Johannes made his proposal to add the ECC Brainpool curves
to the IKEv1 registry there was all of a sudden a hullabaloo and much
concern that someone somewhere might use the ECC Brainpool groups
with IKEv1.

  So my request to you is to ask that the IESG consider what the process
defined for updating this registry is (it's RFC required) and to note that
there is precedence to update the registry of this deprecated protocol.
So please ask the IESG to just approve a draft (either Johannes' or mine)
for publication as an RFC to update this registry in the same manner that
RFC 5114 updated it (i.e. no notes, no pointers, no nonsense).

   Then there'd be no need for the IESG to have a discussion about the
(de)merits of notes and pointers in registries and how best to ensure that
no one nowhere ever even thinks about using an ECC Brainpool curve in
IKEv1 and that certainly sounds like a better use of everyone's time.

  regards,

  Dan.


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

[IPsec] New I-D on IKEv3

[Dan Harkins]

  Hello,

  I just submitted a new I-D that defines version 3 of IKE. The goals of
this draft are to make a more easily understood, and simpler protocol
that has a high degree of probability of achieving interoperability. It
should be easier to read, easier to understand, and easier to implement.
To those ends it:

  - severely limits the negotiable parameters and options
  - no long-term IKE SA, it's one and done
  - has a simple state machine which, if followed, should ensure the
 implementation interoperates with other implementations
  - is a true peer-to-peer protocol

  Please take a look and send me your comments! If you plan on
implementing this protocol then definitely contact me, I want to
interoperate with you.

  regards,

  Dan.

---

Filename:draft-harkins-ikev3
Revision:00
Title:   The (Real) Internet Key Exchange
Creation date:   2012-10-12
WG ID:   Individual Submission
Number of pages: 41
URL:
http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt
Status:  http://datatracker.ietf.org/doc/draft-harkins-ikev3
Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00



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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

On Fri, October 12, 2012 4:56 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   Again, this could've been just like RFC 5114-- no fuss, no mess,
>> no hullaballo. If precedence has been followed, none of this nonsense
>> would've happened.
>
> It is even easier to just drop the whole issue, and leave brainpool
> curves completely out, no fuss, no mess, no hullaballo. There has been
> precedence for that too, we have had proposals for IKEv1 which have
> been dropped and never gone forward or never even implemented (for
> example my revised hash format, notify message payload format etc).

  You're conflating two different issues. This has nothing to do with
the protocol.

> All additions / modifications etc do require some considerations
> before they are accepted. Things in the documents are not same (for
> example number of groups, the fact that 5114 already defines ECP
> groups for IKEv1 etc), time is not same (IKEv1 has been obsoleted
> almost 5 more years after the 5114 was published) etc.

  But this is not a modification. This is an RFC required change to a
registry. We're talking about making an RFC to update the registry.

>>   I have a draft that will need to get updated and the clock is
>> ticking on that (cut-off date is 22 Oct). I need to know what you
>> want my draft to say.
>
> What is this draft you are refering here? Some IETF draft or some IEEE
> document?

  The draft that is referred to in the subject of this email. The draft that
is going to end up having all these nonsensical notes and pointers and
crap in it. That draft.

>>   Can you ask the IESG to just do what it has done in the past? That is,
>> just update the registry to include code points for new curves without
>> any bizarre notes or pointers? No fuss, no mess, just a few new rows
>> in a table.
>
> How about asking instead that do nothing, do not update the registry,
> and if IEEE has problems with that they can fix their document to
> refer to their own registries, or ask IANA to allocate new registry
> which they can manage and use that...

  We've already been through that. It's not a productive use of time
to bring this up again.

> I think the compromise Sean is proposing (i.e. add them as reserved
> values to the IKEv1 registry, add note to point them to new registry
> which defines them and create that new registry containing them) is
> good proposal, and I do not see why you are so much against it? It
> will allow using the groups in the IEEE, it does add one extra
> redirection, but only implementors should ever need that thus they
> should be able to follow pointers, it makes it clear for IKEv1
> implementors that these numbers are not for IKEv1, which will make
> some people (including me) happy.

  It's not so much that I'm against this, it's that there is this huge
discussion about notes and pointers and whether people will respect
the notes and whether they can follow the pointers and making sure
there is a sufficiently large enough firewall to keep IKEv1 implementers
out while allowing others in... All of this is manufactured. These are
all solutions to problems that we are imposing on ourselves. If we
just decide not to impose those problems on ourselves then there
is no need for these convoluted and ridiculous "solutions".

  H.L. Mencken once said that "puritanism is the haunting fear that
someone somewhere might be having a good time." I think you have
a haunting fear that someone somewhere might actually be working
on IKEv1. And because of this haunting fear of yours you have succeeded
in creating the problems and issues that require this convoluted and
bizarre "way ahead" that we are all discussing.

  All of these problems just go away if we follow process and precedence.
If you will just stop being afraid that someone somewhere might do
something you don't like we can get this nonsense behind us.

  We're discussing a way ahead in this thread. I think that way is clear:
let's just let Johannes follow the path that draft-lepinski-dh-groups
did. A short, simple draft to update both registries without any cruft
and notes and pointers and nonsense. It's easy, it's problem-free!

  Dan.


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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Hi Sean,

On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
> Dan,
>
> Thanks for the backfill (ack that's it's not just for SAE).
>
> Question: If Johannes's draft had gone through for IKEv1 you wouldn't
> have needed to make the request for the code points?

  Yes, that's correct because the code points would just be there and
the other protocols that use this registry would just blissfully start
to refer to them. This whole problem started because some people
decided that it was some sort of process issue to update this registry
(Note: it's not).

  Again, this could've been just like RFC 5114-- no fuss, no mess,
no hullaballo. If precedence has been followed, none of this nonsense
would've happened.

  These notes and pointers that people may or may not pay attention
to are just meta problems and they're all completely manufactured.
They will all just go away if we just follow the path that RFC 5114 blazed.

> Because a clock is apparently ticking on the request I think we need to
> address the request in front of us not the combined issue.  If at a
> later date, the registry is updated to add Brainpool curves then the
> "Group Description" rows for those can be updated.

  I don't understand your proposal. What is "the combined issue"? If
the registry is not updated now and, instead is updated at a later date,
then what is being done now?

  I have a draft that will need to get updated and the clock is ticking on
that (cut-off date is 22 Oct). I need to know what you want my draft
to say.

> I'm going to run my proposal and Michael's by the IESG on an informal
> telechat to see which one's got the best chance of getting through the
> process to resolve the IEEE's request.

  Can you ask the IESG to just do what it has done in the past? That is,
just update the registry to include code points for new curves without
any bizarre notes or pointers? No fuss, no mess, just a few new rows
in a table.

  The worst that could happen if the IESG agrees to do that is that someone
somewhere might use a brainpool curve with IKEv1. The odds are slim,
but they're not zero. And if that happens then so what? Really. So what?

  Dan.

> spt
>
> On 9/21/12 4:42 PM, Dan Harkins wrote:
>>
>>Hi Sean,
>>
>>There's some missing (pre)history and context. Let me try to fill it
>> in.
>>
>>Back in early July, Johannes Merkle sent a note to the list saying he
>> wanted to use the elliptic curves proposed by the ECC Brainpool with
>> IKE and IPsec. He asked a series of questions, one of which was:
>>
>>"Should we include IKEv1 in the specs as well?"
>>
>> I voiced support but there was some opposition along the lines of:
>>
>>* we cannot update the IANA registry of an obsoleted protocol.
>>* it is not appropriate for a protocol other than RFC 2409 to use
>>   the IANA registry created by RFC 2409.
>>
>> Both of these are wrong. RFC 5114 updated this very same registry
>> after RFC 2409 was obsoleted and there was no hullabaloo over
>> that action. And RFC 5931 (EAP-pwd) uses that registry and it
>> got approved for publication long after RFC 2409 was obsoleted,
>> again without any hullabaloo.
>>
>>There is no valid process reason to not just let Johannes's draft
>> update the IKEv1 registry while it's updating the IKEv2 registry
>> (just like RFC 5114 did) and there is precedence which we could
>> just follow to avoid all this mess.
>>
>>In spite of that. it was decided to not update the IKEv1 registry
>> with the Brainpool curves. When IEEE got wind of this, they sent
>> a request, via the IEEE-to-IETF liaison, to please reconsider since
>> they have more than 1 protocol used in 802.11 that reference
>> that registry (i.e. it's not just SAE). The concern was that there
>> may be administrative or regulatory reasons for some entity to
>> desire or require using the Brainpool curves and 802.11 wants
>> to ensure that it can be used everywhere, or at least not
>> prohibited from being used because of a misguided effort by
>> the IETF to kill off use of a different protocol.
>>
>>It is the nature of this reconsideration-- forbid IKEv1 from using
>> the updated registry or create some new registry and forbid IKEv1
>> from using it-- that is causing this whole kerfuffle. IEEE 802.11's
>> long (from our standpoint) revision schedule is not the cause of
>> the problem here.
>>
>>The reason to not just update the IKEv1 registry with the Brainpool
>> curves and to prohibit it's use with these curves is, apparently,
>>

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Hi Sean,

On Thu, October 11, 2012 5:47 pm, Sean Turner wrote:
> Dan,
>
> Thanks for the backfill (ack that's it's not just for SAE).
>
> Question: If Johannes's draft had gone through for IKEv1 you wouldn't
> have needed to make the request for the code points?

  Yes, that's correct because the code points would just be there and
the other protocols that use this registry would just blissfully start
to refer to them. This whole problem started because some people
decided that it was some sort of process issue to update this registry
(Note: it's not).

  Again, this could've been just like RFC 5114-- no fuss, no mess,
no hullaballo. If precedence has been followed, none of this nonsense
would've happened.

  These notes and pointers that people may or may not pay attention
to are just meta problems and they're all completely manufactured.
They will all just go away if we just follow the path that RFC 5114 blazed.

> Because a clock is apparently ticking on the request I think we need to
> address the request in front of us not the combined issue.  If at a
> later date, the registry is updated to add Brainpool curves then the
> "Group Description" rows for those can be updated.

  I don't understand your proposal. What is "the combined issue"? If
the registry is not updated now and, instead is updated at a later date,
then what is being done now?

  I have a draft that will need to get updated and the clock is ticking on
that (cut-off date is 22 Oct). I need to know what you want my draft
to say.

> I'm going to run my proposal and Michael's by the IESG on an informal
> telechat to see which one's got the best chance of getting through the
> process to resolve the IEEE's request.

  Can you ask the IESG to just do what it has done in the past? That is,
just update the registry to include code points for new curves without
any bizarre notes or pointers? No fuss, no mess, just a few new rows
in a table.

  The worst that could happen if the IESG agrees to do that is that someone
somewhere might use a brainpool curve with IKEv1. The odds are slim,
but they're not zero. And if that happens then so what? Really. So what?

  Dan.

> spt
>
> On 9/21/12 4:42 PM, Dan Harkins wrote:
>>
>>Hi Sean,
>>
>>There's some missing (pre)history and context. Let me try to fill it
>> in.
>>
>>Back in early July, Johannes Merkle sent a note to the list saying he
>> wanted to use the elliptic curves proposed by the ECC Brainpool with
>> IKE and IPsec. He asked a series of questions, one of which was:
>>
>>"Should we include IKEv1 in the specs as well?"
>>
>> I voiced support but there was some opposition along the lines of:
>>
>>* we cannot update the IANA registry of an obsoleted protocol.
>>* it is not appropriate for a protocol other than RFC 2409 to use
>>   the IANA registry created by RFC 2409.
>>
>> Both of these are wrong. RFC 5114 updated this very same registry
>> after RFC 2409 was obsoleted and there was no hullabaloo over
>> that action. And RFC 5931 (EAP-pwd) uses that registry and it
>> got approved for publication long after RFC 2409 was obsoleted,
>> again without any hullabaloo.
>>
>>There is no valid process reason to not just let Johannes's draft
>> update the IKEv1 registry while it's updating the IKEv2 registry
>> (just like RFC 5114 did) and there is precedence which we could
>> just follow to avoid all this mess.
>>
>>In spite of that. it was decided to not update the IKEv1 registry
>> with the Brainpool curves. When IEEE got wind of this, they sent
>> a request, via the IEEE-to-IETF liaison, to please reconsider since
>> they have more than 1 protocol used in 802.11 that reference
>> that registry (i.e. it's not just SAE). The concern was that there
>> may be administrative or regulatory reasons for some entity to
>> desire or require using the Brainpool curves and 802.11 wants
>> to ensure that it can be used everywhere, or at least not
>> prohibited from being used because of a misguided effort by
>> the IETF to kill off use of a different protocol.
>>
>>It is the nature of this reconsideration-- forbid IKEv1 from using
>> the updated registry or create some new registry and forbid IKEv1
>> from using it-- that is causing this whole kerfuffle. IEEE 802.11's
>> long (from our standpoint) revision schedule is not the cause of
>> the problem here.
>>
>>The reason to not just update the IKEv1 registry with the Brainpool
>> curves and to prohibit it's use with these curves is, apparently,
>>

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

On Tue, September 25, 2012 4:02 am, Tero Kivinen wrote:
> Dan Harkins writes:
>> I voiced support but there was some opposition along the lines of:
>>
>>   * we cannot update the IANA registry of an obsoleted protocol.
>>   * it is not appropriate for a protocol other than RFC 2409 to use
>>  the IANA registry created by RFC 2409.
>>
>> Both of these are wrong. RFC 5114 updated this very same registry
>> after RFC 2409 was obsoleted and there was no hullabaloo over
>> that action.
>
> When draft-lepinski-dh-groups was discussed in the ipsec-list we were
> most concerned about the format of the KE payloads and so on, and I do
> not think anybody actually even reacted to the fact that it updates
> IKEv1 registry too. At that point it was also 2 years since the IKEv1
> was obsoleted, now it is 7 years, so I do think there is a difference.

  There is no time limit that I'm aware of that suddenly makes an
acceptable process suddenly become unacceptable.

>> And RFC 5931 (EAP-pwd) uses that registry and it
>> got approved for publication long after RFC 2409 was obsoleted,
>> again without any hullabaloo.
>
> Never knew that RFC 5931 is using that same registry. This was not
> pointed out in the IPsec list, thus I think most peoples just didn't
> realize the issue.

  I brought it up at the SAAG meeting back in Vancouver. You were
there.

>>   There is no valid process reason to not just let Johannes's draft
>> update the IKEv1 registry while it's updating the IKEv2 registry
>> (just like RFC 5114 did) and there is precedence which we could
>> just follow to avoid all this mess.
>
> It is time to stop updating obsoleted IKEv1 protocol. Even when there
> has been case where it was approved 5 years ago, that does not mean we
> are going to do it forever.

  I will admit that you are repeatedly making that assertion but it's just
some sort of argumentum ad infinitum/absurdum statement. There is
no reasoning behind your assertion. Just "we must stop!" and "we
cannot continue forever!"

  You essentially admit that there is no process reason to not just
update the registry and there's really no prohibition on other protocols
referring to the registry that was created by another protocol. You
may not like it, but that is not a legitimate reason.

  You snipped out the portion of my email where I noted that I did
not foresee any calamity that would befall us all if the IKEv1 registry
is merely updated in the same way it was by RFC 5114-- just add the
code points without any back pointers or front pointers or ridiculous
notes. So let me ask you directly:

What calamity will befall us all if the IKEv1 registry is just updated
in exactly the same way that RFC 5114 updated the registry?

>>   In spite of that. it was decided to not update the IKEv1 registry
>> with the Brainpool curves. When IEEE got wind of this, they sent
>> a request, via the IEEE-to-IETF liaison, to please reconsider since
>> they have more than 1 protocol used in 802.11 that reference
>> that registry (i.e. it's not just SAE).
>
> I could not find any other protocol than SAE, can you give me
> references to which other IEEE protocols use that registry directly
> (i.e. not through some RFC).

  There is a novel use of an unauthenticated Diffie-Hellman by
the audio/visual streaming protocol (added by TGaa).

  Dan.


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

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

[Dan Harkins]

  Hi Sean,

  There's some missing (pre)history and context. Let me try to fill it in.

  Back in early July, Johannes Merkle sent a note to the list saying he
wanted to use the elliptic curves proposed by the ECC Brainpool with
IKE and IPsec. He asked a series of questions, one of which was:

  "Should we include IKEv1 in the specs as well?"

I voiced support but there was some opposition along the lines of:

  * we cannot update the IANA registry of an obsoleted protocol.
  * it is not appropriate for a protocol other than RFC 2409 to use
 the IANA registry created by RFC 2409.

Both of these are wrong. RFC 5114 updated this very same registry
after RFC 2409 was obsoleted and there was no hullabaloo over
that action. And RFC 5931 (EAP-pwd) uses that registry and it
got approved for publication long after RFC 2409 was obsoleted,
again without any hullabaloo.

  There is no valid process reason to not just let Johannes's draft
update the IKEv1 registry while it's updating the IKEv2 registry
(just like RFC 5114 did) and there is precedence which we could
just follow to avoid all this mess.

  In spite of that. it was decided to not update the IKEv1 registry
with the Brainpool curves. When IEEE got wind of this, they sent
a request, via the IEEE-to-IETF liaison, to please reconsider since
they have more than 1 protocol used in 802.11 that reference
that registry (i.e. it's not just SAE). The concern was that there
may be administrative or regulatory reasons for some entity to
desire or require using the Brainpool curves and 802.11 wants
to ensure that it can be used everywhere, or at least not
prohibited from being used because of a misguided effort by
the IETF to kill off use of a different protocol.

  It is the nature of this reconsideration-- forbid IKEv1 from using
the updated registry or create some new registry and forbid IKEv1
from using it-- that is causing this whole kerfuffle. IEEE 802.11's
long (from our standpoint) revision schedule is not the cause of
the problem here.

  The reason to not just update the IKEv1 registry with the Brainpool
curves and to prohibit it's use with these curves is, apparently,
the concern that someone somewhere might actually use them with
IKEv1. It is not a certainty that that will happen and, furthermore, it
is not apparent to me what calamity will befall us all if somebody did.

  So my preference would be to follow existing precedence and let
Johannes's draft update both registries without any ridiculous notes.
If that were to happen we could let my draft die a natural death and
end the kerfuffle. If that just cannot be then I'll update my draft to
reflect your proposed edits, with the modification that this is not just
for SAE and not just for 802.11. Also, if you want to limit the number
of curves (item #4) you should coordinate with Johannes on his draft
for the IKEv2 registry as well as his TLS draft.

  regards,

  Dan.

On Fri, September 21, 2012 7:19 am, Sean Turner wrote:
> I'd like to discuss the IEEE's request for brainpool code points
> additions in the Group Description registry
> (https://www.iana.org/assignments/ipsec-registry) on this mailing list.
>   I realize it's not in scope of the WG, but all the right people are
> here so I'd like to ask for the wg chair's and member's indulgence on
> this matter.
>
> Here's the summary of events as I remember them:
>
> Stephen and I got an informal liaison from IEEE 802.11 requesting code
> point assignments in the Group Description section of
> https://www.iana.org/assignments/ipsec-registry.  Since then we've
> received the official liaison.  And we figured inviting Dorthy along to
> secir would cut down on some email.
>
> My initial thought was that adding anything to this registry was an
> update to IKEv1 and that was pretty much a no-go because IKEv1 is
> obsolete.  But, the registry is RFC required so that's not strictly
> true.  That is, other code points have been assigned after IKEv1 was
> obsoleted.
>
> The other thing that came to light was that the code points were in fact
> not going to be used by IKEv1 they were being used by another protocol,
> the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol.
>
> I think it's fair to say that at the meeting most people weren't
> thrilled that IEEE plans to reuse the registry.  We discussed setting up
> a new registry or pointing from the existing registry to a new registry,
> but the IEEE folks didn't like that because their spec is apparently not
> up for change until 2015 (Tero has submitted comments on this topic in
> IEEE).
>
> What I thought we came to was that Dan would publish a draft that
> requested the points and that the "notes" column would contain "not for
> IKEv1" - and then we'd talk about it.  Dan submitted the draft
> requesting 14 code points with "not for IKEv1" in the notes column for
> each code point.  I forwarded it to secdir and here we are.
>
> ^
> | summary
>
> | way ahead discussion
> v
>
>  From the discuss

Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

[Dan Harkins]

On Tue, August 28, 2012 11:18 am, Paul Hoffman wrote:
>
> On Aug 28, 2012, at 10:49 AM, Dan Harkins  wrote:
>
>> When the IEEE liaison brought up this issue, your co-chairman
>> said, "Yaron and I should "not* be part of this discussion because
>> the issue is *not* an IPsecME WG issue. It is not in our charter
>> to make additions to the obsoleted-but-still-widely-used IKEv1
>> protocol." He is also the one who insisted on the note that the
>> draft adds to the registry, which sort of makes this not an IKE
>> code point discussion.
>
> I was with you until that last phrase. It most certainly is an IKEv1 code
> point discussion.

  If you insist that the registry say "not for IKEv1" then the
code points are not for IKEv1 and any discussion about code points
that are not for IKEv1 is not an IKEv1 code point discussion.

>>  If this is an IKE discussion, I'd be happy to discuss this on the
>> ipsecme list and I'd be, therefore, happy to remove the note and the
>> corresponding "Insecurity Considerations" from the draft.
>>
>>  But maybe you guys should go off and decide what you want.
>
> What I want is for you to be less snarky in your communication, both
> on-list and in the Internet-Drafts you write. I would also want you to be
> clearer in your drafts when you are talking about IKEv1 or IKEv2: in this
> draft, even in the filename, you kind of hid that.

  Please rephrase your wants into specific comments on the draft that
I can then accept, counter, or reject. And please do not send them to
the IPsecME list because, as you said, this "is *not* an IPsecME WG
issue" (emphasis yours).

> Whether or not you want to do those, I want the ADs to decide whether it
> is appropriate to do more work on IKEv1, such as adding these curves to
> the IKEv1 registries. If they think the work is appropriate, they can also
> say where it should be done.

  They already did; you were there.

  Dan.


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

Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

[Dan Harkins]

  Hi Yaron,

On Tue, August 28, 2012 9:05 am, Yaron Sheffer wrote:
> Hi Tim, Dan,
>
> can you please move this discussion to the ipsecme mailing list
> (copied)? I believe that is a more appropriate venue to discuss IKE code
> points.

  When the IEEE liaison brought up this issue, your co-chairman
said, "Yaron and I should "not* be part of this discussion because
the issue is *not* an IPsecME WG issue. It is not in our charter
to make additions to the obsoleted-but-still-widely-used IKEv1
protocol." He is also the one who insisted on the note that the
draft adds to the registry, which sort of makes this not an IKE
code point discussion.

  If this is an IKE discussion, I'd be happy to discuss this on the
ipsecme list and I'd be, therefore, happy to remove the note and the
corresponding "Insecurity Considerations" from the draft.

  But maybe you guys should go off and decide what you want.

  Dan.

>
> Thanks,
>   Yaron
>
> On 08/28/2012 06:48 PM, Dan Harkins wrote:
>>
>>Hi Tim,
>>
>> On Tue, August 28, 2012 7:28 am, Polk, William T. wrote:
>>> hi Dan,
>>>
>>> Thanks for getting this work underway.
>>>
>>> First observation: I think a reference to RFC 6090 is warranted.
>>
>>Yes, good point. I'll add a reference to it at the start of section 2
>> where
>> the equation for the curves is noted.
>>
>>> Second Observation: 80 bit crypto is on its last legs.  Do we really
>>> need
>>> to specify curves with less than 112 bit strength?
>>
>>There is the notion that "if it's worth protecting, it's worth
>> protecting
>> properly" and I'm not sure of the current usefulness of 80-bit crypto
>> but
>> this is more for completeness. The Brainpool defined them and I'm just
>> asking for a magic numbers to be assigned to all the defined curves.
>>
>>That also is the the answer to the "14 code points, oh my!" comments.
>> Note that we still have over 32,000 code points available so we're
>> talking
>> about taking 4/100th of 1%.
>>
>>> Third Observation: The security considerations section does not address
>>> the security strength of 192 or 384 bit curves.  It feels incomplete,
>>> although I guess most readers can work it out for themselves.
>>
>>I refer the reader to RFC 5639 which mentions the security
>> considerations
>> of the curves. If you like I can also mention something about how the
>> best
>> known attacks run on the order of the square root of the order. Would
>> that
>> be satisfactory?
>>
>>> General observation: my experience is that specifying so many curves
>>> dilutes implementer enthusiasm.  We finally started to get some
>>> interest
>>> in ECC support for FIPS 201 when we pared the list down from six curves
>>> in
>>> three families to two prime curves (P-256 and P-384).
>>
>>That is a very good observation. I guess we should talk to the
>> Brainpool.
>> Their consortium seems to have some large and important companies in
>> it. The concern is that one of the members would promote the use of a
>> particular curve in some operational or regulatory fashion and it's
>> important that the users of the IKEv1 registry be able to work anywhere.
>>
>>> Specifying two alternatives for each security level feels like an
>>> implementer's nightmare.  Are Brainpool implementations general enough
>>> to
>>> handle the normal and twisted curves at a particular level?  If the
>>> implementations are agnostic, maybe that should get noted in yout
>>> insecurity considerations.
>>
>>You're right, it is a nightmare! As it turns out quite a few of my
>> test
>> vectors are wrong. I think implementations will be agnostic and I will
>> mention agnosticism.
>>
>>thanks for your comments!
>>
>>Dan.
>>
>>> Tim
>>>
>>> 
>>> From: secdir-boun...@ietf.org [secdir-boun...@ietf.org] On Behalf Of
>>> Yoav
>>> Nir [y...@checkpoint.com]
>>> Sent: Tuesday, August 28, 2012 7:52 AM
>>> To: Stephen Farrell
>>> Cc: sec...@ietf.org
>>> Subject: Re: [secdir] I-D Action:
>>> draft-harkins-brainpool-ike-groups-00.txt
>>>
>>>
>>> On Aug 28, 2012, at 2:31 PM, Stephen Farrell wrote:
>>>
>>>>
>>>>
>>>> On 28 Aug 2012, at 12:24, S

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Fri, July 27, 2012 12:13 am, Yoav Nir wrote:
>
> On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote:
>
>>
>> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote:
>>> Dan Harkins writes:
>>>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote:
>>>>> the fact that we need to study the protocol details and go into the
>>>>> ASN.1 bits to ascertain that we have a problem, strongly suggests to
>>>> me
>>>>> that non-EC DSA is not terribly important. So if we can have a
>>>> *simple*
>>>>> solution that also deals with this problem, fine. Otherwise, let's
>>>> just
>>>>> focus on ECDSA.
>>>>
>>>>  How does one currently indicate the hash algorithm used for non-EC
>>>> DSA
>>>> in IKEv2 today?
>>>
>>> Same way than IKEv1 does it, meaning it is assumed to be SHA-1.
>>
>>  OK, so you're admitting that there's a problem with non-EC DSA in
>> IKEv2. Good, I agree. I would say the inability for IKEv2 to construct
>> a signature that is valid today according to FIPS 186-3 is a problem
>> and we should address it.
>
> Is that "we" as in the IPsecME group, or "we" the design team? Either way,
> non-EC DSA is hardly used. There are effectively zero certificates on
> https servers using it. People preferred RSA even in the days when RSA had
> to be licensed and DSA was free. Why do we need to fix it now?

  I meant "we" as the WG. I think this design team is working at the
pleasure of the WG anyway.

  I'm not sure why a survey of https servers can accurately gauge the use
of DSA in IKEv2. One could also look at it in the light that the SHA-1-only
nature of DSA in IKEv2 only became a problem recently (as FIPS 186-3
and SP 800-57 say such signatures were valid only through 2010). The
reason we need to fix it now is that IKEv2 cannot produce a valid DSA
signature today and unless IKEv3 is just around the corner I'd say we
should fix it in IKEv2 (and given the sound of crickets I hear every time
I bring up IKEv3 I'm less inclined to think it's just around the corner).

>>> Also I would be more happy to reuse the stuff from PKIX than adding
>>> new registy for hashes. This would simplify the auth payload
>>> processing too as the domain parameters and hash both could be seen
>>> from the same place (i.e. from the auth payload) and then we do not
>>> need to add stuff to this registry when new hash functions are added,
>>> we can just assume someone will allocate oids for them.
>>
>>  The domain parameter comes from the CERT payload not the AUTH
>> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the
>> next aligned ulong there's another 24, that's 32 available but disjoint
>> bits. How do you propose encoding an OID into the AUTH payload?
>
> One way is to just place the ASN.1 structure similar to a certificate
> signature: a sequence containing an OID and a bitstring. That structure
> can be placed there as the "Authentication Data" field. The only issue I
> have with that is that there is no negotiation about support for the
> algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the
> receiver does not even support SHA2-224, but that problem exists also with
> encoding the SHA2-224 in the currently reserved fields.
>
> The advantage is that no specification would need to be updated when a new
> hash function is defined. As long as it has an OID, the spec supports it
> with no change.

  Yes that would work. Since there would be a new AUTH method we could
overload the Authentication Data field. It seems sort of a "6 of one; half
dozen of the other" kind of thing but I guess "we" can decide that.

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote:
> Dan Harkins writes:
>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote:
>> > the fact that we need to study the protocol details and go into the
>> > ASN.1 bits to ascertain that we have a problem, strongly suggests to
>> me
>> > that non-EC DSA is not terribly important. So if we can have a
>> *simple*
>> > solution that also deals with this problem, fine. Otherwise, let's
>> just
>> > focus on ECDSA.
>>
>>   How does one currently indicate the hash algorithm used for non-EC DSA
>> in IKEv2 today?
>
> Same way than IKEv1 does it, meaning it is assumed to be SHA-1.

  OK, so you're admitting that there's a problem with non-EC DSA in
IKEv2. Good, I agree. I would say the inability for IKEv2 to construct
a signature that is valid today according to FIPS 186-3 is a problem
and we should address it.

> Also I would be more happy to reuse the stuff from PKIX than adding
> new registy for hashes. This would simplify the auth payload
> processing too as the domain parameters and hash both could be seen
> from the same place (i.e. from the auth payload) and then we do not
> need to add stuff to this registry when new hash functions are added,
> we can just assume someone will allocate oids for them.

  The domain parameter comes from the CERT payload not the AUTH
payload. In any event there's 1 bunch of 8 RESERVED bits and then on the
next aligned ulong there's another 24, that's 32 available but disjoint
bits. How do you propose encoding an OID into the AUTH payload?

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote:
> Hi Tero,
>
> the fact that we need to study the protocol details and go into the
> ASN.1 bits to ascertain that we have a problem, strongly suggests to me
> that non-EC DSA is not terribly important. So if we can have a *simple*
> solution that also deals with this problem, fine. Otherwise, let's just
> focus on ECDSA.

  How does one currently indicate the hash algorithm used for non-EC DSA
in IKEv2 today?

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Thu, July 26, 2012 11:06 am, Yoav Nir wrote:
> In IKE we only have the bitstring, so we must infer the OID from something
> else.

  Which is why I suggested we take some of the second bunch of RESERVED
bits in the AUTH payload. Not to indicate an OID (not enough bits) but to
just enumerate the valid hash algorithms that can be used with ECDSA.

  That way we know the curve from the subjectPublicKeyInfo (in either
the signer's certificate or raw public key) and the hash algorithm used (from
the 2nd bunch of RESERVED bits). There is nothing to infer. When more
hash algorithms (like SHA3) get defined we just populate the registry that
gets represented in the 2nd bunch of RESERVED bits.

  Dan.



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

Re: [IPsec] ECDSA in IKEv2

[Dan Harkins]

On Tue, July 24, 2012 11:04 am, Yoav Nir wrote:
>  - Flexibility in associating hash functions should not a unlimited. There
> is no reason to allow a 521-bit EC group with MD4 as the hash function,
> or even with SHA2-256 as the hash function. I'm perfectly happy to limit
> that curve to SHA2-512 and SHA3-512.

  There is no reason to "allow" the 768-bit FFC group to be used to
generate a shared secret that is to be authenticated with an ECDSA
signature with a 521-bit curve and have SHA-1 be used as the key
derivation function either, but such a thing is permissible and it
will be permissible in IKEv2 even if we were to prohibit the use of
SHA-256 with a 521-bit curve.

  Any attempt to enforce coherent use of primitives-- e.g. define
what primitives are valid for different security levels, or what certain
combinations of primitives are permissible and what are forbidden--
should only be  done as part of an IKEv3.

  Dan.


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

Re: [IPsec] ECDSA in IKEv2

[Dan Harkins]

  Hello,

  I would like to participate. The problem I see is that the selection of
the hash algorithm has to be decoupled from the indication of the
authentication method. So I propose the following:

1. Determining the Domain Parameter Set

  The curve SHALL be identified by name in the subjectPublicKeyInfo
of the certificate or raw public key.

2. Determining the hash algorithm

  Use some of the RESERVED bits of the AUTH payload to
define a "hash algorithm." I propose using 16 bits and making
it align for shorts so use bits 16-31 and leave 8-15 as
RESERVED.

  Then we should specify that the value of "hash algorithm"
SHALL be zero except for the following new Auth Method:

  13: Elliptic Curve Digital Signature Algorithm

and the value of "hash algorithm" will come out of a new registry
created by IANA whose initial population will be:

  - 1 : SHA-1
  - 2 : SHA-224
  - 3 : SHA-256
  - 4 : SHA-384
  - 5 : SHA-512

  This has a number of benefits:

  - it will work for raw public keys (as Tero is proposing) as well
 as certified ECDSA keys.
  - it will allow for growth too because when SHA-3 algorithms get
 defined they can just further populate the new registry and we
 can unambiguously identify the hash algorithm regardless of the
 expected digest size or the curve.
  - we can support more of the FIPS 186-3 options where a hash
 producing a larger digest than the curve's prime is being used.
  - it doesn't consume a scarce resource unnecessarily.
  - the same approach could be used to fix non-EC DSA which I
 believe is still broken (just define another "generic DSA" auth
 method and use the hash registry this proposal creates).

There remains an open question about what to do with the existing
ECDSA curves and I suggest nothing. There will technically be two
ways to do a NIST P256 signature using SHA-256 (ditto for 384/384
and 521/512). No big deal.

  Dan.

On Tue, July 24, 2012 9:08 am, Yaron Sheffer wrote:
> Hi,
> recent discussion on the list has indicated that there is some interest
> in better supporting ECDSA certificates in IKEv2, and that the existing
> solutions are not very extensible. The discussion was very useful in
> outlining the existing issues and pointing to some possible ways forward.
>
> Paul and I would like to propose setting up a design team with the goal
> of proposing a long-term solution to this problem. Some of the
> attributes of a reasonable solution include:
>
> - Supports currently used and proposed ECDSA certificates.
> - Allows flexibility in defining EC domain parameters.
> - Allows flexibility in associating hash functions with EC groups.
> - Is not limited to 256 values
> - ECDH is out of scope.
> - Non-certificate authentication using raw public keys is out of scope,
> unless it is trivially supported by the proposal.
>
> The solution should be an extension to IKEv2, and should not break the
> protocol. Some of the ideas in
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be
> used as a starting point.
>
> Please respond to us privately or to the list, indicating if you would
> like to participate in the design team, or if you only support the
> effort and would be willing to review the ensuing I-D.
>
> Thanks,
>  Yaron
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote:
>>   If the mapping between curve and hash function is fixed then I don't
>> see what you mean by "not hash-independent but only curve-independent".
>> Seems that there is nothing independent, it's all fixed.
>
> I have the impression that we misunderstand each other. The solution that
> I propose is to define one new auth method
> ECDSA_generic which indicates that
> - the curve shall be taken from the certificate
> - the hash function shall be the minimum SHA-1/2 function matching or
> exceeding the security level of the curve.

  So the signer says "ECDSA_generic" and the curve is determined from the
subjectPublicKeyInfo and one infers the correct SHA-1/2 algorithm from
the curve. OK, so if the curve is the 320-bit brainpool curve then we always
use SHA-384. Got it.

>>   And there are 7 new brainpool curves so that's 7 new auth methods
>> plus 4 new ones to deal with the non-EC version of DSA for a total
>> of 11 new auth methods to go along with the existing 4. 15 different
>> auth methods just for the digital signature standard!
>>
> Not with the approach I proposed: there is only one method ECDSA_generic.
>
> Note, that for DSA (on EC), it would also be sufficient to specify a new
> auth method DSS_key_length_defined_hash
> accompanied with the requirement to choose the hash function as the
> smallest SHA-2 function meeting the minimum
> requirements of FIPS-186-3.

  Well FIPS 186-3 specifically refers to SP 800-57 for "information about
the selection of the appropriate (L,N) pair in accordance with a desired
security strength for a given time period for the generation of digital
signatures."  And SP 800-57 says that, for example, to produce a
signature valid "beyond 2030" it requires a minimum of 128 bits of
strength (table 4) and that when performing digital signatures of 128
bits of security the valid hash functions are SHA-256, SHA-384, and
SHA-512. You want to restrict such signatures to SHA-256 so it's
not really meeting the requirements of FIPS 186-3.

>>   Yes, it is unfortunate. What's also unfortunate is that the 11 auth
>> methods mentioned above (plus the 3 existing ECDSA auth methods)
>> will probably have to be duplicated for SHA-3 thereby eating into this
>> "scarce resource" of an 8-bit registry even further.
>
> We have the choice: Either spending many assignments out of the 256
> available, or to specify a generic auth method
> deviating from the approach previously tken for ECDSA (but being in
> accordance with the approach taken for DSA).

  But the "generic ECDSA" does not solve the problem with SHA-3. As
you said above, "the hash function shall be the minimum SHA-1/2 function
matching or exceeding the security level of the curve." So how do you
support SHA-3? I guess we could assign a bit (clear=SHA-1/2, set =
SHA-3) but that's getting pretty hackish. Or we could have 2 "generic
ECDSA", one for SHA-1/2 and another for SHA-3. Yuck.

  If only this protocol was designed better

  Dan.



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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote:
   If we're gonna recharter, maybe we should just work on an IKEv3
 because
 the problems in IKEv2 are becoming apparent. This "new authentication
 mode"
 suggestion, or the need for a "generic ECDSA" algorithm are just hacks
 that
 should not be necessary for a properly defined protocol. In addition,
 the
>>>
>>> I do not agree. The generic definition of the ECDSA auth method is
>>> analogous to the auth methods defined for RSA and DSA
>>> keys, and thus, is rather the proper (canonical) way to define it than
>>> a
>>> hack.
>>> Of course, the fact than there are already 3 specific auth methods for
>>> ECDSA (which are not canonically defined) makes
>>> specification of a generic ECDSA method more cumbersome.
>>
>>   With RSA the hash algorithm is encoded into the padding so there is
>> no real need to independently agree on a hash algorithm. For DSA,
>
> No, in RSA PKCS#1v1.5 padding (which is currently the only supported
> padding in IKEv2), the hash algorithm is *not*
> encoded in the padding. Only the length of the length of the hash value
> can be determined due to the reserved zero octet
> leading the hash value. For SHA-1 and the SHA-2 hash functions, the length
> also determines the function, so your
> assertion in in some way true for these functions. However, RFC 5996 does
> not restrict the hash function to these. As
> soon as one of the SHA-3 contributions is used, the function can not be
> determined from the padding, as SHA-3
> contributions were required support 224, 256, 384, and 512-bit message
> digests, exactly the lengths generated by the
> SHA-2 functions.

  I see that Scott Fluhrer has already responded to this; I agree with Scott.

>> I disagree. The DSA algorithm definition is hash-specific so the hash-
>> specific ECDSA auth methods are the canonical way. Let me point
>> out, though, that canon law is not necessarily correct and this is an
>> example.
>
> By generic ECDSA methods, I did not mean hash-independent but only
> curve-independent.
>
> At least for SHA-1/SHA-2, the mapping between size of the curve and hash
> function could be fixed in an RFC. The hash
> length shall not be smaller than the bit length of curve parameters
> (FIPS-186-3), and there is no need to choose an
> SHA-2 function longer than the minimum one meeting this requirement.

  If the mapping between curve and hash function is fixed then I don't
see what you mean by "not hash-independent but only curve-independent".
Seems that there is nothing independent, it's all fixed.

>>   So to actually address this in the hash-specific canonical way
>> requires new auth methods for different permutations of DSS with
>> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different
>> permutations of ECDSA with brainpool curves using the 5 different
>> SHA varients. But this is getting, as you say, "cumbersome".
>>
> As said above, I don't see the need to allow, for instance, the Brainpool
> p256 curve to be used with any hash function
> other than SHA-256.

  And there are 7 new brainpool curves so that's 7 new auth methods
plus 4 new ones to deal with the non-EC version of DSA for a total
of 11 new auth methods to go along with the existing 4. 15 different
auth methods just for the digital signature standard!

>>   Of course one can decide not to use the hash-specific canonical
>> technique and come up with "generic DSA" and "generic ECDSA" to
>> address this but then we have the unfortunate state of hash-specific
>> (EC)DSA methods and "generic" methods and now it's getting ugly
>> (and hack-ish).
>>
> Such a co-existence of different approaches would also be the case if a
> curve-independent (but hash-specific) ECDSA
> method was specified, and I agreee that this is a bit unfortunate. But
> this is not a major issue compared to alternative
> of specifying separate methods for each curve in an 8 bit registry.

  Yes, it is unfortunate. What's also unfortunate is that the 11 auth
methods mentioned above (plus the 3 existing ECDSA auth methods)
will probably have to be duplicated for SHA-3 thereby eating into this
"scarce resource" of an 8-bit registry even further.

>>   Instead of either negotiating a complete ciphersuite (the way TLS
>> does) or individual components (the way IKEv1 did), IKEv2 does both
>> and gets the worst of both worlds.
>>
>
> Means to negotiate the hash function could be specified as discussed
> earlier in this thread, but of course this is a
> more significant change. And I am not sure if this is necessary, given the
> clear recommendations of FIPS 186-3.

  I am not advocating the mixing-and-matching of curves and hash
functions of different security levels (and therefore one could argue
to fix them) but it should be noted that IKEv2 allows all sorts of mixing
and matching of ciphers, hash algorithms, and D-H groups of different
security levels to be negotiated-- AES-256 with the 768-bit DH group
authenti

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Mon, July 23, 2012 2:19 am, Tero Kivinen wrote:
> Dan Harkins writes:
>> So instead of being able to use the negotiated hash function to
>> compute an ECDSA signature we're forced to eat through the "scarce
>> resource" of the authentication method registry. Very clumsy, very
>> hackish, very unfortunate.
>
> I disagree it being clumsy or hackish or unfortunate. It is just one
> way of designing the system. Some peole do want to make sure there is
> no way to mix algorithms of different strength. I myself think this
> should be something that is restricted by policy, not by protocol, but
> some people do disagree that and design systems differently. It is not
> necessarely bad or good, it is just different.

  So some people want to do it one way and other's want to do it a
different way. What's hackish is to do both and that's what IKEv2 does.
For (EC)DSA the hash algorithm to use is determined by the auth
method (no way to mix algorithms) but the cipher and D-H group
are not (something restricted by policy).

  Doing it one way or the other might not necessarily be good or bad
but doing it both is.

> Also there is no reason why the ECDSA RFC could not have added a new
> transform type for HASH function, but it instead decided to use fixed
> hash functions for the curves (just like we do for DSA in the IKEv1,
> which always used SHA-1 as hash function when calculating signature,
> regardless what was negotiated in the SA payloads for HASH).

  And in IKEv2 you got rid of the hash negotiation but retained the
SHA-1 only nature of DSA regardless of the PRF being negotiated.
Section 3.8 of RFC 5996 says:

  "DSS Digital Signature  3
  Computed as specified in Section 2.15 using a DSS private key
  (see [DSS]) over a SHA-1 hash."

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote:
>>
>>   The particular curve can be determined from the subjectPublicKeyInfo.
>> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
>> curves.
>
> Actually, this is not strictly correct:
> ANSI X9.62 defies three ways to specify the curve (domain parameters) in a
> certificate (extracted from RFC 5480):
>   ECParameters ::= CHOICE {
>namedCurve  OBJECT IDENTIFIER
>implicitCurve   NULL
>specifiedCurve  SpecifiedECDomain
>  }
> implicitCurve means that "the parameters are explicitly defined
> elsewhere".
>
> So we can safely assume that the parameters are available to a pier
> receiving the certificate of the other one.
>
>
> By the way: While RFC 5480 prohibits the use of implicitCurve and
> specifiedCurve, there are certainly still many
> implementations of RFC 3279 out there which allowed all three methods.

  For a guy who's always reminding everyone about how there are many
implementations of an older RFC I should keep that in mind. Thank you
for pointing that out. But, as you note, RFC 5480 prohibits implicitCurve
and specificCurve so all we have left is namedCurve which is, as I noted,
how the particular curve can be determined from the subjectPublicKeyInfo.

>>   If we're gonna recharter, maybe we should just work on an IKEv3
>> because
>> the problems in IKEv2 are becoming apparent. This "new authentication
>> mode"
>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks
>> that
>> should not be necessary for a properly defined protocol. In addition,
>> the
>
> I do not agree. The generic definition of the ECDSA auth method is
> analogous to the auth methods defined for RSA and DSA
> keys, and thus, is rather the proper (canonical) way to define it than a
> hack.
> Of course, the fact than there are already 3 specific auth methods for
> ECDSA (which are not canonically defined) makes
> specification of a generic ECDSA method more cumbersome.

  With RSA the hash algorithm is encoded into the padding so there is
no real need to independently agree on a hash algorithm. For DSA,
I disagree. The DSA algorithm definition is hash-specific so the hash-
specific ECDSA auth methods are the canonical way. Let me point
out, though, that canon law is not necessarily correct and this is an
example.

  FIPS 186-3 (The Digital Signature Algorithm) specifies that security
strength levels of DSA are a minimum of the security strength of the
hash algorithm and the (L,N) pair from the domain parameter set. If
one wished to achieve a security strength level with DSA that would
be valid, according to NIST, "beyond 2030" one would need to use
SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature"
(authentication method value of 3) so that wouldn't work.

  Given that SP 800-57 requires that 80 bits of strength only be used
through 2010 (and SHA-1 does not provide more than that) and it
is now 2012 it appears that IKEv2 is not capable of producing a
signature of sufficient strength for certain customers (they might not
be your's but they do exist, and there's probably more of them than
there are people clamoring for AES-XCBC MAC).

  So to actually address this in the hash-specific canonical way
requires new auth methods for different permutations of DSS with
SHA-224, SHA-256, SHA-384, and SHA-512 as well as different
permutations of ECDSA with brainpool curves using the 5 different
SHA varients. But this is getting, as you say, "cumbersome".

  Of course one can decide not to use the hash-specific canonical
technique and come up with "generic DSA" and "generic ECDSA" to
address this but then we have the unfortunate state of hash-specific
(EC)DSA methods and "generic" methods and now it's getting ugly
(and hack-ish).

  Instead of either negotiating a complete ciphersuite (the way TLS
does) or individual components (the way IKEv1 did), IKEv2 does both
and gets the worst of both worlds.

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Sun, July 22, 2012 6:53 am, Yoav Nir wrote:
>
> With ECDSA, the hashes are the same sizes as the signatures, so there's no
> room within the signature to encode the hash algorithm. You need to know
> what it is by some other means. So they chose to encode it using the AUTH
> method. Not very economical in terms of protecting the scarce resource of
> auth methods.

  Actually that's not true. The length of the digest of the hash algorithm
is not
the same as the length of the prime of the curve (what I think you mean by
the
"same size as the signatures" since the the signature is R|S). X9.62 says
that
the length of the digest of the hash is a kind of low-water mark of the
desired
security level. If the digest is larger than the length of the prime then
you're
supposed to take the left-most length-of-prime bits of the digest and use
that to compute "s".

  And this points out to another unfortunate design decision of IKEv2.
Instead
of negotiating a fundamental cryptographic primitive like a hash function, it
negotiates a derivative construct like a PRF. So instead of being able to use
the negotiated hash function to compute an ECDSA signature we're forced
to eat through the "scarce resource" of the authentication method registry.
Very clumsy, very hackish, very unfortunate.

  Dan.




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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Sat, July 21, 2012 10:50 am, Yoav Nir wrote:
>
> On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote:
>
>> On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote:
[snip]
>>> I think the way forward is to take this WG and as whether WG would be
>>> willing to recharter and add new items to its charter:
>>>
>>> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be
>>>   done as individual draft, and does not need to be WG item, but if
>>>   we are doing the rest in WG then I think this should also be WG
>>>   item too).
>>> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA)
>>>   in the IKEv2. This may require new standard track RFC defining new
>>>   generic ECDSA method, and might also need solutions how hash
>>>   function is selected for each group.
>>
>>  If we're gonna recharter, maybe we should just work on an IKEv3 because
>> the problems in IKEv2 are becoming apparent. This "new authentication
>> mode"
>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks
>> that
>> should not be necessary for a properly defined protocol. In addition,
>> the
>> issues with the incorrect definition of representation of the result of
>> an
>> ECDH (it's the x-coordinate, not the concatenation of the x- and
>> y-coordinates) that's lead to interoperability issues, and the inability
>> to
>> handle point compression all lead one to the conclusion that this stuff
>> should all be fixed once and for all and fixed cleanly.
>
> In 6 years IKEv2 has gained very little traction. All major vendors offer
> it, but it's still not the default setting for any of them. It would be as
> bad as saying that IPv6 has problems, so we should begin work on IPv8.

  We've been through nearly 40 revisions of this protocol (18 for IKEv2,
another
10 to "clarify" how to use it and then another 11 to do IKEv2v2)  and it
still
needs hacks to add some new elliptic curves-- either N new authentication
modes for N curves, or a new unified and general ECDSA in addition to the
existing 3 for ECDSA (!!!)-- and even still there will be interoperability
issues
because some people represent an ECDH shared secret as x||y and others
represent it as x.

  Notice how the Notify payload is becoming the overloaded payload of choice
to "fix" everything? It's hacked for EAP-only, it's hacked for secure
passwords, and it's the method of choice to hack in new curves. Yuck.

  It's not apparent to me that the reasons for lack of deployment of IKEv2
are in any way similar to those of IPv6 (and, frankly, I would tend to doubt
there is any relationship).

  It may be "bad" to say that we have a problem, but it's worse to deny that
the problem exists. The first step to actually addressing one's problems of
dysfunction is admitting to them. Let me begin:

   "Hello! My name is Dan. We have a problem."

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote:
> Johannes Merkle writes:
>> > Adding them for authentication use (ECDSA use) will most likely get
>> > more opposition. First of all, I am not at all happy how the ECDSA
>> > groups are added to the IKEv2 authentication method. The
>> > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit
>> > registry in IKEv1). This does not matter if we have only few ECDSA
>> > groups with one hash algorithm for each, but when we are adding more
>> > groups it seems to bad idea for each of them having separate number.
>> > Especially if someone later decides that they want to use all ECDSA
>> > groups with SHA 3 too...
>>
>> Today, I responded to Yoav's idea of taking algorithms details from
>> the certificate. At least the EC domain parameters could be taken
>> from it, and for the hash function, a default could be defined per
>> curve. So one new authentication method ECDSA_generic or
>> ECDSA_cert_defined could be sued for any EC domain parameters.
>
> Hmm... so the EC domain parameters can be seen from the certificate? I
> wonder why did the RFC4753 then made separate allocations for each EC
> group?

  The particular curve can be determined from the subjectPublicKeyInfo.
Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool
curves.

  I'm not so sure it makes sense to define a new hash algorithm per curve
though. I would suggest just using the negotiated hash function. That is
going to be used for key derivation and will influence the level of security
that the exchange affords. That is, if you define SHA-384 to use with
brainpoolP384r1 but the two sides end up using SHA-1 for key derivation
then I'm not sure what using SHA-384 for authentication is buying you.

[snip]
>
> I think the way forward is to take this WG and as whether WG would be
> willing to recharter and add new items to its charter:
>
> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be
>done as individual draft, and does not need to be WG item, but if
>we are doing the rest in WG then I think this should also be WG
>item too).
> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA)
>in the IKEv2. This may require new standard track RFC defining new
>generic ECDSA method, and might also need solutions how hash
>function is selected for each group.

  If we're gonna recharter, maybe we should just work on an IKEv3 because
the problems in IKEv2 are becoming apparent. This "new authentication mode"
suggestion, or the need for a "generic ECDSA" algorithm are just hacks that
should not be necessary for a properly defined protocol. In addition, the
issues with the incorrect definition of representation of the result of an
ECDH (it's the x-coordinate, not the concatenation of the x- and
y-coordinates) that's lead to interoperability issues, and the inability to
handle point compression all lead one to the conclusion that this stuff
should all be fixed once and for all and fixed cleanly.

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Wed, July 18, 2012 5:14 pm, Tero Kivinen wrote:
> Dan Harkins writes:
>>   Nobody said anything about "adding everything". That is a complete
>> straw
>> man argument. In fact, it is decidedly not the case that "everything" is
>> being
>> added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so
>> quick
>> to leap to unfounded conclusions you would see this IANA update as the
>> innocuous event that it really is.
>
> Not if you count the authentication methods in to it too. That do
> require quite a bit of work to make sure everything is done correctly.
>
> Especially as IKEv1 exchanges are quite different depending which
> authentication method is used. Adding only the Diffie-Hellman groups
> is much easier, but I understood that the idea was to add both.
>
> And for SPSK there was also text for adding that to IKEv1 too, before
> it was removed. Same is now with the ike-over-tcp, which again has
> IKEv1 text in it.

  EXACTLY!!! That is what I was saying. "everything" is not being added to
IKEv1 and we have documented evidence, you even provided another
example. So your statement that this innocuous addition of code points
to a registry is somehow "adding everything" is just hyperbole.

>>   This is allowing existing implementations to have more flexibility in
>> the
>> ECDH operations they perform to comply with various requirements that
>> may exist in different locales or in different circumstances or
>> situations.
>
> I would think the ECP groups we already have in the IKEv1 should be
> enough for the most common case, i.e. the suite-b uses. Also I still
> do not think that many implementations are going to update their IKEv1
> implementations.

  The brainpool curves have been defined for a purpose that, apparently,
the NIST-defined curves does not satisfy.

  And your statement about "many implementations" is belied by your
behavior. Why would someone be such a vocal advocate of a law that
is not necessary?

[snip]
> So what is wrong with using the already existing mechanisms of using
> groups directly in the SA for that already obsoleted protocol? It
> seems the only reason to add numbers for them is to support non IPsec
> use...

  They are for the situations in which the brainpool curves are necessary.
That is not "to support non-IPsec use". That is not why the brainpool curves
were defined.

>> > This is exactly why new group mode was made a SHOULD in the IKEv1,
>> > i.e. to allow adding new groups without need to changing the
>> > specification or the actual code.
>>
>>   Your recollection differs from the person who actually wrote the RFC.
>> And when that happens one should typically defer to the author. In fact,
>> your statement seems to differ from the RFC which says it SHOULD be
>> supported as a mechanism to define "private groups". The brainpool
>> groups are not private and there is no reason to treat them as such.
>
> Brainpool groups do not have number in the IANA registry, which makes
> them private for IKEv1 use. There is nothing there claiming that you
> can only use new group mode to negotiate groups that are not know for
> anybody else.

  "Brainpool groups do not have a number in the IANA registry". What do you
think the topic of this thread is? Look at the subject above.

  You are arguing against doing something because it hasn't been done yet
and that is illogical.

  You know what? IKEv2 doesn't have any brainpool groups defined in its
IANA registry. Are you against such a code point allocation? If not, then
can I please ask you to be consistent in your positions?

[snip]
> I have never tried to hide the fact that I think IKEv2 is much better
> protocol than IKEv1. IKEv1 do have some security problems (not big
> enough to cause it to fail completely, but they are there). IKEv1 does
> not have standardized support for many things that are there for
> IKEv2. Many IKEv1 implementations uses methods described in the
> expired Internet-drafts for some things, and there are multiple of
> those methods different implementations use.
>
> I think IKEv1 needs to DIE. It is so broken I see no reason for it to
> kept alive anymore. I do not want anybody to add anything to it for
> two reasons:
>
> 1) I am the implementor who might need to implement them in our code.
>Up to this point I have been able to say we do not want to do any
>changes to IKEv1 code.
> 2) It might make people feel like IKEv1 could still be used.
>
> This is my opinion and I do stick to it, and I do continue trying to
> convince others to it too. I see no problem there.
>
> Are you saying that I am not allowed to try 

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Wed, July 18, 2012 3:12 pm, Tero Kivinen wrote:
> Dan Harkins writes:
>> > I would be strongly against for including support for protocol which
>> > has been obsoleted 7 years ago. If people want to use this kind of
>> > groups in IKEv1 they can use the new group mode and negotiate groups
>> > on the fly. There is no need to add them to IKEv1.
>>
>>   In spite of this designation IKEv1 is still widely used and I would
>> posit
>> that it is used more than IKEv2.
>
> It is widely used, but that does not mean we need to keep adding
> everything there. I do not think that is that much more widely
> implemented anymore. I would expect most of the implementations do
> support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough.

  Nobody said anything about "adding everything". That is a complete straw
man argument. In fact, it is decidedly not the case that "everything" is
being
added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick
to leap to unfounded conclusions you would see this IANA update as the
innocuous event that it really is.

  This is allowing existing implementations to have more flexibility in the
ECDH operations they perform to comply with various requirements that
may exist in different locales or in different circumstances or situations.

>>   IKE already has the way to handle new domain parameter sets that are
>> publicly defined and that is through the IANA registry. Your suggestion
>> to
>> use New Group Mode to use brainpool ECC groups would only hamstring
>> IKEv1 and make it harder to use.
>
> I think otherwise, as using new group mode allows using them without
> changing any single line of code, provided the IKEv1 implementation do
> support ECP groups at all (and support the new group mode which is
> SHOULD).

  There is a capability in New Group Mode to accept or reject the proposal
and this is to allow the recipient to verify that the group is acceptable.
Enabling this in IKEv1 for the brainpool curves would be substantially more
code than just using the existing code point interface that all
implementation
have.

> This is exactly why new group mode was made a SHOULD in the IKEv1,
> i.e. to allow adding new groups without need to changing the
> specification or the actual code.

  Your recollection differs from the person who actually wrote the RFC.
And when that happens one should typically defer to the author. In fact,
your statement seems to differ from the RFC which says it SHOULD be
supported as a mechanism to define "private groups". The brainpool
groups are not private and there is no reason to treat them as such.

  Since groups added with New Group mode MUST be assigned private
code points it would result in a case of code bi-furcation because
the same domain parameter sets would be accessed using different
code points. That's unnecessary code complication for implementations
that support both IKEv1 and IKEv2.

> I agree that there might be implementations which do not support it,
> and for example I think we disabled it from our implementation when we
> added IKEv2 support, as we wanted to keep the feature set provided by
> our implemenation about the same regardless whether IKEv1 or IKEv2 is
> used, and IKEv2 do not support such feature.
>
>> It would be a blunt club to force people into doing something that
>> they haven't decided to do on their own (to your apparent chagrin).
>
> I agree on that. I do try to convince to switch to IKEv2, as it is
> MUCH better protocol and works much more robustly and has standarized
> features for things which IKEv1 only has multiple non-standardized
> non-interoperable protocols.

  And bully for you! I wish you much success in your advocacy. Actively
trying to make people's programmatic lives worse because your advocacy
isn't as successful as you'd like is a completely different matter though and
is, I think, inappropriate.

  The fact that you admit you want a blunt club to force compliance
with your wishes speaks volumes.

>>   The IETF does not have a lot of success at forcing people to do things
>> they do not want to do on their own and I think this sort of thing is
>> somewhat inappropriate.
>
> We do not need to keep adding features to the old obsoleted protocoles
> either.

  This is NOT a feature. ECDH already exists in IKEv1. This is allowing
existing implementations, of which they are legion, to use certain
domain parameter sets that may be required or desired in certain situations
and in certain locales.

>>   Why there are two identical repositories to map unsigned shorts to
>> complete domain parameter sets is beyond me but there are. These
>> two repositories have been updated in concert in the past a

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

On Wed, July 18, 2012 11:45 am, Tero Kivinen wrote:
[snip]
>> [Question 1] Should we include IKEv1 in the specs as well? It seems
>> that some people in the WG do not like the idea of updating this
>> obsolete protocol. On the other hand, many applications still use
>> IKEv1 and specifying the use of the Brainpool curves only for IKEv2
>> would exclude these.
>
> I would be strongly against for including support for protocol which
> has been obsoleted 7 years ago. If people want to use this kind of
> groups in IKEv1 they can use the new group mode and negotiate groups
> on the fly. There is no need to add them to IKEv1.

  In spite of this designation IKEv1 is still widely used and I would posit
that it is used more than IKEv2.

  IKE already has the way to handle new domain parameter sets that are
publicly defined and that is through the IANA registry. Your suggestion to
use New Group Mode to use brainpool ECC groups would only hamstring
IKEv1 and make it harder to use. It would be a blunt club to force people
into doing something that they haven't decided to do on their own (to your
apparent chagrin).

  The IETF does not have a lot of success at forcing people to do things
they do not want to do on their own and I think this sort of thing is
somewhat inappropriate.

  Why there are two identical repositories to map unsigned shorts to
complete domain parameter sets is beyond me but there are. These
two repositories have been updated in concert in the past and and there
is no good reason to have them diverge now.

  Dan.


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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

  Hello,

On Wed, July 18, 2012 11:51 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   Absolutely yes. There are still a lot of IKEv1 implementations out
>> there
>> and also there are other protocols that use the IANA registry from
>> IKEv1,
>> namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry
>> has to be added to the IKEv1 registry.
>
> Why would any other protocol use IKEv1 IANA registries? Are you now
> talking about the authentication method registry or the diffie-hellman
> groups registry?

  The "diffie-hellman groups registry".

> It is bad idea to use registry for any other reason than where it is
> created, and adding stuff to IKEv1 IANA registry not for IPsec use,
> but for use for some other protocols seems like quite funny.

  It was created to map an unsigned short to a complete domain parameter
set and that is exactly how it is being used.

> My personal opinion about that is that it is IEEE 802.11-2012 problem
> if they use IANA registry for some other purposes than what it is
> intended for.

  I think your opinion that this is "some other purpose" is wrong.

  Dan.



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

Re: [IPsec] Using ECC Brainpool curves with ipsec

[Dan Harkins]

  Hello,

On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote:
> Hi,
>
> in RFC 5639, we have specified a new set of elliptic curve parameters for
> use in cryptographic applications. Meanwhile,
> support for these "Brainpool Curves" has been included in some crypto
> libraries as openssl (recently) and crypto++.
> However, in order to use the Brainpool Curves with IKE and IPSec, still
> some specifications and IANA registry updates
> are needed. We are now planning to prepare such an RFC to allow usage of
> the ECC Brainpool curves with ipsec.

  I think that's a great idea.

> In order to go forward with this effort, we would like to discuss some
> questions and potential issues. The WG feedback
> on these is most appreciated.
>
> [Question 0] Is the WG interested in shepherding an RFC specifying all
> that's necessary to use the Brainpool curves in
> ipsec? And what category would be preferred, standard track or
> informational.

  I can't speak for the group but I would like to see an RFC that defines the
IANA considerations for using these curves in IKE. Informational is probably
fine unless the answer to question 2 below requires Standards Track.

> [Question 1] Should we include IKEv1 in the specs as well? It seems that
> some people in the WG do not like the idea of
> updating this obsolete protocol. On the other hand, many applications
> still use IKEv1 and specifying the use of the
> Brainpool curves only for IKEv2 would exclude these.

  Absolutely yes. There are still a lot of IKEv1 implementations out there
and also there are other protocols that use the IANA registry from IKEv1,
namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry
has to be added to the IKEv1 registry.

> [Question 2] If IKEv1 is to be considered, the registry for IPSEC
> Authentication Methods (Value 3) needs to be updated,
> because the values for ECDSA are specific for each curve. What policy for
> updating this IANA registry can be assumed?
> IANA currently requires a standard track RFC, but there has recently been
> some discussion on relaxing this, in
> particular,
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html .
> For the corresponding IKEv2 registry (Auth Method), only Expert Review is
> required.

  Hopefully that will be relaxed.

> [Question 3] If IKEv1 is to be considered, it seems reasonable to write
> only one RFC covering IKEv1 and IKEv2. Actually,
> we also plan to prepare analogous specifications for TLS, so an option
> would be to write a common RFC for IKE and TLS
> analogously to RFC 5114. However, according to the update policy of the
> IANA registry EC Named Curve for TLS, such an
> RFC would have to be shepherded by the tls WG. Does this prevent or
> considerably complicate the creation of a joint RFC
> for IKE and TLS? Would preparing separate RFCs for IKE and TLS be
> preferable?

  This seems reasonable. The body of the RFC will probably just be IANA
considerations. The domain parameter sets of the curves are already defined
so you just need to get IANA to allocate magic numbers for their use.

> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256,
> 320, 384, 512 two curves are defined, one
> being the “quadratic twist” of the other – their algebraic structure
> (and hence, security level) is equivalent, but one
> of them allows particular efficient arithmetic. In order to leave the
> choice of the curve for a given bit length to the
> implementation we propose to register IANA values (for Auth method and
> Diffie-Hellman Group) for both curves for each
> bit length. Of course, this doubles the number of number assignments. Any
> objections on this?

  There's approximately 65k available assignments so this shouldn't be a
problem. Why would anyone want to do the untwisted version if the twisted on
is more efficient? Are there any IPR considerations to the twisted version?

> [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but
> also ECGDSA (Elliptic Curve German Digital
> Signature Algorithm) according to ISO 14888-3, which is a slight variant
> of ECDSA. The advantage of ECGDSA over ECDSA is
> that signature generation does not need any inversion modulo the group
> order, which removes the necessity of
> corresponding code. This advantage is particularly interesting when using
> devices with limited computation power and
> storage like smart cards or electronic control units in cars. In
> particular, car manufacturers have expressed their
> desire to deviate from EDSA For this reason, we would like to specify
> values for ECGDSA (with the individual bit lengths
> and curves) as Authentication Method as well. Would the WG support
> inclusion of this additional signature algorithm?

  Unless this got wider acceptance my personal take is: pass.

> [Question 6] In cryptographic applications using elliptic curves, point
> compression (see Section 4.

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi,

  Let me answer David here in a response to Yaron

  To be equally blunt, it is because this PAKE work became extremely
political and I was, and still am, very unhappy with the way it turned
out. Repeating it, this time with an obsoleted protocol, would cause
(more) people to question my sanity-- i.e. doing the same thing and
expecting a different result.

  I'd like to just get a stable reference for this minor change that
has the potential to do good. I don't want to fight over it anymore.

  regards,

  Dan.

On Tue, March 27, 2012 2:13 pm, Yaron Sheffer wrote:
> Hi Dan,
>
> I haven't made up my mind yet whether I support the addition of SPSK to
> IKEv1 or not, because both you and Tero have made some good points.
>
> But this very discussion is a strong proof to me that we need to have
> IETF Review (in the RFC 5226 sense) for this kind of major change to
> IKEv1. Because this is exactly the community that needs to discuss new
> authentication methods, and to weigh their security and other properties
> against the disadvantages of adding yet more stuff to IKEv1. This needs
> to be an open discussion, and I am sure the ADs will use our input when
> they decide whether to sponsor any such proposal.
>
> Thanks,
>   Yaron
>
> On 03/27/2012 06:41 PM, david.bl...@emc.com wrote:
>>>I think we can make things better with a simple addition and I just
>>> want to be able to do that.
>>
>> To ask bluntly - what is the problem with soliciting AD sponsorship for
>> the simple addition?
>>
>> IMHO, "Specification Required" by itself is entirely too weak for
>> security protocols.
>>
>> Thanks,
>> --David
>>
>>> -Original Message-
>>> From: Dan Harkins [mailto:dhark...@lounge.org]
>>> Sent: Tuesday, March 27, 2012 12:23 PM
>>> To: Black, David
>>> Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
>>> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication
>>> Methods (Value 3) registration
>>> policy
>>>
>>>
>>>Hi David,
>>>
>>> On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
>>>> Hi Dan,
>>>>
>>>> One process note:
>>>>
>>>>>It appears that all the PAKE drafts got one "yes" from the
>>>>> sponsoring
>>>>> AD and the remaining votes were "no objection" so it doesn't seem
>>>>> like
>>>>> the IESG is really interested in this topic and, frankly, I think the
>>>>> majority think "that stuff is out of my field of expertise". So my
>>>>> only
>>>>> option is to cajole an AD into sponsoring my draft and hoping that no
>>>>> one
>>>>> else on the IESG objects by saying, "didn't we just do this?"
>>>>
>>>> Speaking from long experience as a chair of many WGs, that sort of
>>>> IESG
>>>> vote tally is typical, even for WG docs (although usually both of the
>>>> responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
>>>> you're being overly pessimistic.
>>>>
>>>>>So let me turn it around, what's wrong with "Specification
>>>>> Required"?
>>>>
>>>> While I know that you're competent to design a solid  protocol, who
>>>> does
>>>> the security review of the next 5 j-random authentication mechanisms
>>>> to
>>>> make sure that they don't have security flaws?  I'd prefer something
>>>> like
>>>> IESG approval that puts the Security Area in the loop to the notion of
>>>> deferring to some form of Expert Review (this is not a slam against
>>>> Tero
>>>> as the expert - wider review usually produces better results).
>>>
>>>That's a really good point. Had it been "Specification Required" all
>>> along XAUTH might've gotten an official code point. And who knows maybe
>>> one of the j-random proposals might be just that. But IKEv1 really is
>>> pretty done. At this point I'm pretty sure that j would be zero.
>>>
>>>I know IKE's being used wrong and I know the people who are using it
>>> wrong don't want to go to IKEv2. They understand what they're doing is
>>> broken (a shared PSK for everyone followed by PAP in XAUTH) but they
>>> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
>>> like going to IKEv2 with SPSK is much more attractive.
>>>
>>>I think we can make things better with a simple addition and I just
>>> want to be able to do that.
>>>
>>>regards,
>>>
>>>Dan.
>>>
>>>
>>
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi David,

On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
> Hi Dan,
>
> One process note:
>
>>   It appears that all the PAKE drafts got one "yes" from the sponsoring
>> AD and the remaining votes were "no objection" so it doesn't seem like
>> the IESG is really interested in this topic and, frankly, I think the
>> majority think "that stuff is out of my field of expertise". So my only
>> option is to cajole an AD into sponsoring my draft and hoping that no
>> one
>> else on the IESG objects by saying, "didn't we just do this?"
>
> Speaking from long experience as a chair of many WGs, that sort of IESG
> vote tally is typical, even for WG docs (although usually both of the
> responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
> you're being overly pessimistic.
>
>>   So let me turn it around, what's wrong with "Specification Required"?
>
> While I know that you're competent to design a solid  protocol, who does
> the security review of the next 5 j-random authentication mechanisms to
> make sure that they don't have security flaws?  I'd prefer something like
> IESG approval that puts the Security Area in the loop to the notion of
> deferring to some form of Expert Review (this is not a slam against Tero
> as the expert - wider review usually produces better results).

  That's a really good point. Had it been "Specification Required" all
along XAUTH might've gotten an official code point. And who knows maybe
one of the j-random proposals might be just that. But IKEv1 really is
pretty done. At this point I'm pretty sure that j would be zero.

  I know IKE's being used wrong and I know the people who are using it
wrong don't want to go to IKEv2. They understand what they're doing is
broken (a shared PSK for everyone followed by PAP in XAUTH) but they
don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
like going to IKEv2 with SPSK is much more attractive.

  I think we can make things better with a simple addition and I just
want to be able to do that.

  regards,

  Dan.


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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   That said, the problem I want to fix-- IKEv1's susceptibility to
>> dictionary attack, it's binding of a PSK to an IP address, and the
>> prevalence of XAUTH because there's no other option-- should be fixed.
>
> All others than the dictionary attack IS ALREADY FIXED. The fixes are
> in the IKEv2. Also the dictionary attack problem will be fixed by your
> IKEv2 SPSK draft.

  Yet there is still this massive deployment of XAUTH + IKEv1.

>> We can say, "stop using IKEv1" but giving someone the option of
>> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
>> just continuing on with a broken XAUTH deployment, we all know what
>> they'll do and it's not doing PAKE + IKEv2.
>
> Yes, we can and should say "Stop using IKEv1".

  Yes we should. But we should not suffer any delusions that we can
force anyone to do anything.

> That is the part I agree with you. I do not want to add any new
> features to IKEv1, as that just makes people to continue use it, and
> not to update to the IKEv2. If PAKE is the stick that causes people to
> move from IKEv1 to IKEv2, that is very good.

  We can't always get what we want and we should be reasonable in
understanding that. If we could wave a magic wand and grant your wish
that would be good; we can't. And given the limits to our power we
have to accept that what will happen is people will continue to use
IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
though, so it is likely that by adding SPSK to IKEv1 we could get people
off of XAUTH and that too would be a good thing.

  So if we weigh the improbable stretch goal of forcing people to stop
using IKEv1 with the probable, more easily attainable, goal of getting
people to stop using XAUTH by giving them an alternative that can pretty
easily be implemented, I still come down on settling for an achievable
goal of goodness and not making that be a victim for an unachievable goal
of betterness.

>> It would be a service to the Internet to provide a fix for this. The
>> IETF has not been successful in forcing people to do things against
>> their will (viz, the history of IPv6) and if we tried here we'd
>> likely fail again.
>>
>>   So let me turn it around, what's wrong with "Specification Required"?
>
> Read the whole original thread and find out there. I do not really
> have any objections for Specification Required, that was what I
> originally proposed. The original thread (I just gave the link to
> first email in the full thread) has emails which explains why people
> felt it was not enough.
>
> Regardless whether it is Specification Required or not, I am still
> objecting if someone tries to add new features to IKEv1. Of course my
> objecting might not have any effect, but I still think it is BAD idea.

  OK, so we're in agreement: "Specification Required."

  Dan.


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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote:
> Dan Harkins writes:
>>   I guess I'd like to register an objection. I wrote a draft a few
>> months
>> ago to address this:
>>
>>  http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
>>
>> That suggested making it "Specification Required". You mentioned that
>> someone was opposed to it being "Specification Required" but didn't say
>> who or what the rationale was behind that opposition.
>>
>>   So I'd like to discuss this a bit. I prefer "Specification Required"
>> and would like to know what the problem someone has with it is.
>
> See the orignal thread in the ipsec-list:
>
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html

  OK, but that says "'Specification Required' or 'IETF Review'", it's
not opposition to "Specification Required".

> What is your objection to the IETF Review?

  Well, I feel it is setting the bar too high for what I want to do.
I had to remove a chunk of text from my PAKE draft fixed a significant,
know, serious, and continuing problem with IKEv1. I was told that
I should write another I-D that includes that text and try to see
what happens. The issue is that requiring IESG review and AD sponsorship
will likely result in me not getting over that bar and getting a code
point assigned.

  It appears that all the PAKE drafts got one "yes" from the sponsoring
AD and the remaining votes were "no objection" so it doesn't seem like
the IESG is really interested in this topic and, frankly, I think the
majority think "that stuff is out of my field of expertise". So my only
option is to cajole an AD into sponsoring my draft and hoping that no one
else on the IESG objects by saying, "didn't we just do this?"

  I don't want to burn up what remaining goodwill I might have with
our ADs by continuing to push this topic.

  That said, the problem I want to fix-- IKEv1's susceptibility to
dictionary attack, it's binding of a PSK to an IP address, and the
prevalence of XAUTH because there's no other option-- should be fixed.
We can say, "stop using IKEv1" but giving someone the option of
implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
just continuing on with a broken XAUTH deployment, we all know what
they'll do and it's not doing PAKE + IKEv2. It would be a service to
the Internet to provide a fix for this. The IETF has not been successful
in forcing people to do things against their will (viz, the history of
IPv6) and if we tried here we'd likely fail again.

  So let me turn it around, what's wrong with "Specification Required"?

  thanks,

  Dan.

>> >   IETF Review - (Formerly called "IETF Consensus" in
>> > [IANA-CONSIDERATIONS]) New values are assigned only
>> through
>> > RFCs that have been shepherded through the IESG as AD-
>> > Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
>> > intention is that the document and proposed assignment
>> will
>> > be reviewed by the IESG and appropriate IETF WGs (or
>> > experts, if suitable working groups no longer exist) to
>> > ensure that the proposed assignment will not negatively
>> > impact interoperability or otherwise extend IETF protocols
>> > in an inappropriate or damaging manner.
>> >
>> > To ensure adequate community review, such documents are
>> > shepherded through the IESG as AD-sponsored (or WG)
>> > documents with an IETF Last Call.
>> >
>> > Examples: IPSECKEY Algorithm Types [RFC4025],
>> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005],
>> TLS
>> > Handshake Hello Extensions [RFC4366].
> --
> kivi...@iki.fi
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[Dan Harkins]

  Hi Tero,

  I guess I'd like to register an objection. I wrote a draft a few months
ago to address this:

 http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt

That suggested making it "Specification Required". You mentioned that
someone was opposed to it being "Specification Required" but didn't say
who or what the rationale was behind that opposition.

  So I'd like to discuss this a bit. I prefer "Specification Required"
and would like to know what the problem someone has with it is.

  thanks,

  Dan.

On Mon, March 26, 2012 9:49 am, Tero Kivinen wrote:
> As described in the IPsecME WG meeting I propose that we change the
> registration policy for the IPSEC Authentication Methods (Value 3) of
> ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From
> RFC5226):
>
> --
>   IETF Review - (Formerly called "IETF Consensus" in
> [IANA-CONSIDERATIONS]) New values are assigned only through
> RFCs that have been shepherded through the IESG as AD-
> Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
> intention is that the document and proposed assignment will
> be reviewed by the IESG and appropriate IETF WGs (or
> experts, if suitable working groups no longer exist) to
> ensure that the proposed assignment will not negatively
> impact interoperability or otherwise extend IETF protocols
> in an inappropriate or damaging manner.
>
> To ensure adequate community review, such documents are
> shepherded through the IESG as AD-sponsored (or WG)
> documents with an IETF Last Call.
>
> Examples: IPSECKEY Algorithm Types [RFC4025],
> Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
> Handshake Hello Extensions [RFC4366].
> --
>
> I will ask IANA to make the change at the 2012-04-15, unless I get
> some objections here in the list.
> --
> kivi...@iki.fi
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] Possible update to isakmp-registry

[Dan Harkins]

On Fri, February 10, 2012 12:13 pm, Yaron Sheffer wrote:
> Hi Paul,
>
> sorry, I don't understand your statement. Yes, IKEv1 is popular but
> (formally) obsolete. It is still our responsibility to ensure that it
> doesn't gain new and insecure extensions in its old age. The way we do
> it is through the normal IETF/RFC-Ed/IANA bureaucratic processes.
>
> Unlike Tero, I don't think people will be adding non-IETF extensions of
> this sort to IKEv1. New crypto algorithms, maybe. But new authentication
> methods? I'd be surprised.

  SURPRISE! It's me. And I want to add a new authentication method
to IKEv1. New, yes; insecure, no. In fact, it makes things _more_ secure
because it obviates the need for insecure extensions that have been added
to IKEv1 and widely implemented, like XAUTH, because it removes the
requirement that a PSK be bound to an IP address and it is resistant to
dictionary attack.

  (And now that I have mentioned this, will you be surprising yourself
by proposing a new authentication method for IKEv1 that is resistant to
dictionary attack?)

  Dan.


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

Re: [IPsec] Avoiding Authentication Header (AH)

[Dan Harkins]

On Thu, January 5, 2012 6:23 am, Tero Kivinen wrote:
> Bhatia, Manav (Manav) writes:
[snip]
>> If a WG ends up mandating AH (when ESP could have been used) then
>> Yes it's a problem for everyone, right from the vendors to the
>> users, who have to now support AH too in their products and
>> networks.
>
> If WG wants to mandate AH, and we cannot convince them otherwise,
> having a document which says so does not help. On the other hand if we
> have stealth WG trying to sneak AH past IPsec community, I think they
> will also conviently ignore this document too.
>
> In summary I do not think there is problem, and I do not think we need
> to say anything about AH right now.

  Indeed! I agree 100%. Me too. +1. Etc.

  Dan.


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

Re: [IPsec] Avoiding Authentication Header (AH)

[Dan Harkins]

  Hello,

On Mon, January 2, 2012 7:43 am, Venkatesh Sriram wrote:
> If ESP and AH continue to co-exist then I see the following happening:
> (i) standard for feature foo1 using ESP-NULL + SW effort + QA effort +
> interop effort(ii) standard for feature foo1 using AH + SW effort + QA
> effort + interop effort(iii) standard for feature foo2 using ESP-NULL
> + SW effort + QA effort + interop effort(iv) standard for feature foo2
> using AH + SW effort + QA effort + interop effort..(iii) standard for
> feature foo'n' using ESP-NULL + SW effort + QA effort + interop
> effort(iv) standard for feature foo'n' using AH + SW effort + QA
> effort + interop effort

  If much of the above is not duplicative then you have bigger problems
that AH.

> Now, i am willing to live with this if the security offered by AH and
> ESP-NULL is significantly different. I dont see why we should have
> this complication if ESP-NULL can do everything that AH has to offer.

  Ran has provided a good list of things that AH can do that ESP-NULL
cannot.

> Why should the operators learn managing ESP and AH when both do the
> same?
> RFC 4301, by declaring ESP as a MUST and AH as a MAY has already set
> the context. I dont see why vendors and everybody else in the food
> chain should spend cycles on AH, if its not bringing anything
> substantial on the table?

  If it's a MAY then don't spend any cycles on it. Implementations that
support it MUST be prepared to interoperate with implementations that
do not.

> I dont think the draft in question says that AH is bad and should be
> deprecated. It merely says that WGs should be circumspect when
> mandating AH since its likely that most people are using ESP-NULL and
> you dont want to unnecessarily add complexity in people's lives for no
> good reason.

  If you want to direct WGs to be circumspect when specifying AH then
why don't you go sit in those WGs and instruct them in what they should
be doing? Or at the very least comment during LC. Honestly, if a WG is
not paying attention to RFC 4301 then what makes you think they're gonna
pay attention to a random individual submission?

  I don't have any particular love for AH but this effort is really
lacking in one thing: a problem to solve. On the one hand, we're being
told that the effort is necessary because WGs developing a "standard for
protocol fool" need to be instructed on how to obtain integrity protection
but we're also being told that discouraging AH is OK because no one (in
NANOG) is using it and it's a MAY anyway. These seem to be somewhat
contradictory to me-- either no one's using it and we have a solution
in search of a problem; or, someone's using it and it would probably be
a problem to restrict its use in the future.

  I detect the strong arm of a weak product management department at
work here. If the engineers are complaining about implementing a protocol
that isn't being used then grow a backbone and tell your customers that
they're not gonna get support for a protocol they don't use.

  regards,

  Dan.


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

[IPsec] I-D Action: draft-harkins-ike-iana-update-00.txt

[Dan Harkins]

  Hello,

  There is a new draft available that some of you may be interested
in looking at. Please send your comments to the list.

  regards,

  Dan.

On 11/17/11 3:18 AM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>   Title   : A Modest Proposal to Update IKE's IANA Registry
>   Author(s)   : Dan Harkins
>   Filename: draft-harkins-ike-iana-update-00.txt
>   Pages   : 5
>   Date: 2011-11-17
>
> The "IPSEC Authentication Methods" registry created by IKE states
> that it can only be updated by Standards Track RFC.  In practice,
> this has not been the case.  This memo proposed to relax that
> requirement.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-harkins-ike-iana-update-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-harkins-ike-iana-update-00.txt
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>


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

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

[Dan Harkins]

  Hello,

On Tue, November 1, 2011 1:56 pm, Paul Wouters wrote:
> On Tue, 1 Nov 2011, Yoav Nir wrote:
>> Raw RSA keys work. If there is an introducer that tells both sides about
>> each other, a shared secret also works. Shared secrets are very secure
>> if you generate them randomly.
>
> PSK's have problems when trying to distisnguish multiple road warriors
> with different PSKs using Main Mode in IKEv1.

  That problem is being addressed:

  http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-auth-05

  regards,

  Dan.


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

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

[Dan Harkins]

  Sounds like TED:

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html

  Dan.

On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote:
> Hi all
>
> For years, one of the barriers to the adoption of IPsec was that
> configuration didn't scale. With thousands of peers, the PAD and SPD would
> become unwieldy, so even where IPsec was deployed it was often built in
> hub-and-spoke configurations, not because policy demanded this, but
> because it was more convenient to configure. Individual vendors have
> incompatible solutions for this, but they only work with that vendor's
> products, and within the same administrative domain.
>
> In this draft, we are proposing that the IPsecME working group take on a
> working item to first define the problem, and then offer solutions that
> will make IPsec scale better and in an inter-operable way.
>
> We plan to hold a side meeting in Taipei, and we welcome comments both
> before and at that meeting.
>
> Yoav
>
> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt
> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] Perfect Forward secrecy

[Dan Harkins]

  Hi Naveen,

  Yoav is right that increasing the size of the secret, and ensuring it
is uniformly random, will mitigate this sort of dictionary attack. And
the 3 drafts he mentions will basically foil it entirely.

  But the attack you mention does not affect "perfect forward secrecy".
That is the property that even with the loss of a long term credential
(like the pre-shared secret learned by dictionary attack) the adversary
is unable to determine the session key from a different run of the
protocol. This property still holds even with a successful dictionary
attack against a pre-shared key.

  regards,

  Dan.

On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote:
> Hi Naveen
>
> If you use a 128-bit or 256-bit truly random shared secret (like you
> should, although probably nobody does), brute force will never work. If
> you use a weaker shared secret, such as something with 20-40 bits of
> entropy, then your offline dictionary attack becomes practical.
>
> For suggested ways of counteracting this, take a look at these:
> http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut
> http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2
> http://tools.ietf.org/html/draft-shin-augmented-pake
>
> On 8/29/11 8:54 AM, "Naveen B N (nbn)"  wrote:
>
>>Hi Scott,
>>Even with the Pre-shared secret, the protocol can't keep up the property
>>of " perfect Forward secrecy".
>>I have assumed the both the server and client use pre-shared secret, same
>>below methods applies to Certificate based
>>Authentication has well.
>>Below steps show why.
>>
>>Subject: Intruder X acts has server only to get the access of auth
>>payload.
>>
>>1)A send IKE_INIT to indented server.
>>2) X[ intruder ] receives the INIT and process just has the protocol and
>>replies with the generated
>>public value for DH. IKE_INT response is from Intruder instead of Server
>>by creating the packet using
>>a raw socket using [ IP spoofing].
>>3)A and X now generate the Sk key which is used to encrypt the next
>>IKE_AUTH message.
>>4)A sends IKE_AUTH and intruder receives the same and he is able to
>>decrypt the message and get access to IDR and Auth payload.
>>5)Intrudes gets hold of the AUTH data and work on it to derive the
>>Pre-shared Secret { eg. Brute force}.
>>6) Since The Pre-shared secret is not changes the Intruder can now behave
>>has the Initiator to server[IDR]
>>And complete the Ikev2 flow.
>>
>>Kindly share your view on the above .
>>
>>Thanks and Regards
>>Naveen
>>
>>-Original Message-
>>From: Scott Fluhrer (sfluhrer)
>>Sent: Friday, August 26, 2011 7:27 PM
>>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
>>Cc: 'ipsec@ietf.org'
>>Subject: RE: [IPsec] DH keys calculation performance
>>
>>
>>> -Original Message-
>>> From: Naveen B N (nbn)
>>> Sent: Friday, August 26, 2011 1:37 AM
>>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav
>>> Nir'
>>> Cc: 'ipsec@ietf.org'
>>> Subject: RE: [IPsec] DH keys calculation performance
>>>
>>> Hi Scott,
>>> if we can take care of the "Forward Secrecy",
>>> When using Asymetric keys from certificates
>>> To negotiate symmetric keys, then certificate
>>> Can be used in place of DH Computation.
>>>
>>> "TO maintain "Forward Secrecy", we have to change the keys from
>>> time to time based on the key length, which can be achieved by re-
>>> negotiating"
>>
>>No, you'd have the change the asymmetric keys all well; with the private
>>key, the attacker can still recover the session (symmetric) keys.
>>
>>Now, it's not impossible to change the public keys; however, it does
>>involve generating a fresh private/public key pair.  With RSA, at least,
>>that's a lot more expensive than doing a single exchange (or, for that
>>matter, several dozen simple exchanges), and so if the point of this is
>>to reduce the total amount of computation, well, that rather misses the
>>point.
>>
>>>
>>> If this is possible then I can present a draft for the same.
>>>
>>> Thanks & Regards
>>> Naveen
>>>
>>>
>>> -Original Message-
>>> From: Scott Fluhrer (sfluhrer)
>>> Sent: Thursday, August 25, 2011 10:18 PM
>>> To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; 'timo.te...@iki.fi'
>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools-
>>> us...@lists.sourceforge.net'; 'ikev2-de...@lists.sourceforge.net';
>>> 'ipsec-tools-de...@lists.sourceforge.net'
>>> Subject: RE: [IPsec] DH keys calculation performance
>>>
>>>
>>> > -Original Message-
>>> > From: Naveen B N (nbn)
>>> > Sent: Thursday, August 25, 2011 12:34 PM
>>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
>>> > timo.te...@iki.fi
>>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools-
>>> > us...@lists.sourceforge.net; ikev2-de...@lists.sourceforge.net;
>>> ipsec-
>>> > tools-de...@lists.sourceforge.net
>>> > Subject: RE: [IPsec] DH keys calculation performance
>>> >
>>> > Hi Scott,
>>> >
>>> > Please find the queries and comments inline ..
>>> >
>>> > Scott>- Transporting keying 

Re: [IPsec] Role of the IANA expert reviewer

[Dan Harkins]

On Mon, August 1, 2011 9:11 am, Paul Hoffman wrote:
> On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote:
>> I have stated my reasons why I consider allocating multiple payload
>> numbers etc for exactly same thing a bad thing.
>
> The three proposals do not do "exactly the same thing": they each have
> different cryptographic and administrative properties. This has been
> widely discussed in the WG.

  Yes, they do do "exactly the same thing", they all implement a zero
knowledge proof to authenticate the peers using a simple password.

  They use cryptography differently to achieve that same result but that
doesn't mean the "cryptographic properties" are different; they're not.
The cryptographic property that the exchanges have is resistance to
off-line dictionary attack, i.e. the advantage an attacker gains is
through interaction and not computation.

  Administrative differences? They all use the same D-H group used in IKE
and they all need to be provisioned with a password. No difference there
either.

  If these drafts had some different properties, or were different in
any meaningful and technical way, then we'd have a "winner" already. But
we don't, and that's because they do the same thing and have the same
properties.

  All we have to show for those delays and the capricious process imposed
on the WG is an implementation problem-- 3 ways of doing the same thing.

  Dan.


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

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Dan Harkins]

  Hi Yaron,

On Fri, July 29, 2011 2:47 pm, Yaron Sheffer wrote:
> Hi Dan,
>
> there are three drafts on the table, and they are NOT identical. Crypto
> protocols, as you know well, are a mixture of cryptography and
> engineering. While the engineering on all three is very similar, the
> cryptography is not.

  I didn't say the cryptography was identical, nor did I say the drafts
are identical (if they were then this "controversy" would be even more
contrived!).

  What I meant was that if your original opposition to my draft was
technical (or non-political, as you say) then we would've seen some
demonstrable technical difference in 1 of the 3 new drafts. We didn't.
They all do a zero knowledge proof in about the same number of rounds
(adding one to IKE_AUTH) with about the same amount of work (+- a modular
exponentiation). They all achieve the same goal in approximately the
same amount of messages with approximately the same amount of work.

  If there was a obvious demonstrable technical difference between the
drafts then the WG would've picked a winner or the AD would've picked
a winner or his designated expert would've picked a winner. But we have
no winner so, as I said, they are "effectively _identical_ from a
technical point of view."

  So there wasn't a technical reason for you to do what you did. We
could've had a standards track solution to this work item if you had
just treated my draft in the same way you treated your own. But no. We
have 3 drafts, an implementation problem, and now your opposition to a
draft to lessen that problem as much as possible.

> I do not wish to offend, but I believe cryptography is better left to
> professional cryptographers. I am not a cryptographer; the primary
> author of draft-kuegler-ipsecme-pace-ikev2 is.

  I'm not offended because I'm not a cryptographer and have never said
otherwise. But neither are any of the editors of the IKEv2 draft and I
don't remember your opposition to the advancement of that draft to RFC.

  Dan.


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

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Dan Harkins]

On Wed, July 27, 2011 10:49 pm, Yaron Sheffer wrote:
> Unfortunately Dan cannot accept that there may be objective, non
> political reasons for the group not to adopt his work. Which is the
> reason why three alternative proposals were published several months
> after his proposed PAKE solution.

  Well there certainly wasn't a technical reason. In fact, after
delaying things for several months what we ended up with were 3
drafts that were effectively _identical_ from a technical point of view.
That is the prime reason that the group (and later the AD) could not
agree on which one to choose.

> As co-chairmen of ipsecme, Paul and I did our best to get the group to
> agree on a single solution, to the point where we both supported Dan's
> criteria for selecting such a solution. Unfortunately we failed: while
> the group supported a PAKE in IKEv2 "in the abstract", there was not
> enough energy to pick a single protocol for this purpose.

  You are on the record opposing PAKE from the start. It seems that
your "best" is best exemplified by your treatment of your own draft
which whisked through the group on to the standards track with no working
group input or, apparently, interest. PAKE got delayed (by you) and
ultimately killed for lack of interest even though there were emails on
the list discussing the 3 drafts.

> Back to the matter at hand: I am opposed to
> draft-kivinen-ipsecme-secure-password-framework. It has served its
> purpose when two of the proposals were changed to add method
> negotiation, and thus enable IKE peers to implement none, one or more of
> these methods. I believe the other justifications for this draft,
> including the preservation of IANA IKEv2 namespaces, are bogus. Adopting
> the rest of the framework would be a useless exercise.

  Speaking as an implementer, this is not a useless exercise. If one
must implement > 1 of these PAKE schemes having them inside of this
framework simplifies things.

> Personally, given that all three current proposals are being advanced as
> Experimental outside the WG, I would argue that we are wasting far too
> much energy on this grand unified framework. And this includes the
> current mail exchange.

  Then don't update your draft! Let it expire and go where dead drafts
go.

  Dan.


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

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

[Dan Harkins]

  Paul,

  The existence of this draft shows a failure of YOUR leadership (and
that of your co-chairman) of the working group. Consensus was achieved
to add an authentication method based on a simple password yet you
seemingly worked to do everything possible to create division in the
working group and then stepped in to declare failure because no
consensus existed.

  We could've had a single standards-track solution to this problem over a
year ago if you had treated the singular draft used to argue for addition
of this work to the charter in the same way that you treated the singular
draft used to argue for addition of "EAP only" authentication to the
charter. The latter (authored by one of the chairmen) was advanced to
standards track after receiving a whopping ZERO comments from the WG and
the former was killed by the chairmen because the only comments on the
list were from authors of competing drafts (after manufacturing the
competition in the first place).

  There was hostility by the IPsecME chairmen to this work item from
the beginning and you worked to ensure its failure in the WG. Now you're
against advancement of Tero's draft to forge the best possible outcome
now? Not a surprise!

  Put that hat back on, along with a sackcloth and ashes, and say "mea
culpa".

  Dan.

On Wed, July 27, 2011 5:12 pm, Paul Hoffman wrote:
> 
>
> On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote:
>
>> I think this is a terrible idea.
>
> +.5. I think is is a bad idea.
>
>> IKEv2 has a way for mutual authentication with a shared key.
>>
>> A concern was raised that this method was vulnerable to guessing if
>> trivial shared keys were configured.
>>
>> There were several proposals for a better cryptographic method.
>>
>> The IPsecME working group failed to choose between them. This is not so
>> surprising, because most participants are engineers, not cryptographers.
>> Even those with some cryptographic background stayed silent because
>> choosing between several cryptographic protocols is hard. IETF last
>> calls and the IESG did not help much either.
>>
>> This draft represents a total shirking of our responsibility.
>
> +.5. I think think it represents a shirking of our leadership's
> responsibility. Our leadership said that they would deal with the issue if
> the WG could not come to consensus, and the WG could not come to
> consensus. Adding a layer of indirection that is mostly transparent is not
> dealing with it.
>
>> Rather than decide on one protocol that is "best" or even arbitrarily
>> choosing one that is "good enough", it proposes to build a framework so
>> that everyone and their dog can have their own method. This is a
>> nightmare for developers: since you can't know what method the peer will
>> support, you have to implement all of them.
>>
>> If this had been a hierarchical organization, some manager would decide
>> which of the methods gets developed (or published) and the others would
>> be relegated to the recycle bin.
>>
>> The IETF is not like that and we seek to reach consensus. That's a good
>> thing, but this time it's leading us to a really bad solution for
>> interoperability, and a really bad solution for implementers.
>>
>> I am opposed to this draft.
>
> +1
>
>
> On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote:
>
>> Yoav Nir writes:
>>> This draft represents a total shirking of our responsibility. Rather
>>> than decide on one protocol that is "best" or even arbitrarily
>>> choosing one that is "good enough", it proposes to build a framework
>>> so that everyone and their dog can have their own method. This is a
>>> nightmare for developers: since you can't know what method the peer
>>> will support, you have to implement all of them.
>>
>> Partially yes, but unfortunately all of the authors of those actual
>> protocols decided that they wanted to continue publishing those drafts
>> as individual RFCs, and each of them used different way to negotiate
>> them, so there was no way to even implement multiple of them.
>
> Is this true? Because each has it's own way to negotiate its use, one
> should be able to implement multiple of the competing proposals as-is,
> yes?
>
>> At least this drafts gives you that option to implement multiple of
>> them if you want. This draft only provides instructions for those
>> other draft authors so they can at least common methods to negotiate
>> the feature and use common method to trasmit data between peers.
>
> True, but it is still punting the problem of us having just one.
>
> --Paul Hoffman
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] DH keys calculation performance

[Dan Harkins]

  Hello,

On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote:
> Thanks Yoav and Yaron  for the suggestions.
>
> Even I was thinking and tried generating and storing the key pair  well
> in the beginning,.  This helped to some extent.
>
>
>
> The secret calculation is also very expensive, but this has to be done
> in midst of the exchange only.

  You could pick one secret x and then for IKE exchanges do this:

0th exchange: y = g^x mod p
1st exchange: y = g^(x+1) mod p
2nd exchange: y = g^(x+2) mod p
.
.
.
nth exchange: y = g^(x+n) mod p

Getting from exchange i to exchange i+1, then, is just a single modular
multiply, which should be "cheaper" for you.

  Knowing n, y, g and p and that y = g^(x+n) mod p does not really give
an advantage (above the discrete logarithm problem) in finding x. That
said, I still would not suggest doing many more than a few of these (and
I am not qualified to quantify that statement) but for a few-- i.e. keep
n small and after n choose a new x and repeat-- it should be OK.

  Maybe this technique will allow you to "cheapen" your exchange a bit.
I think throwing hardware at this problem is your best bet though.

  regards,

  Dan.


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