Subject: Re: [IPsec] Last Call: <draft-kivinen-ipsecme-secure-password-framework-01.txt> (Secure Password Framework for IKEv2) to Informational RFC

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Aug 2011 17:42:45 +0300

Yaron Sheffer writes:
> it doesn't matter exactly what negotiation is used, as long as two peers 
> can offer multiple methods in IKE_SA_INIT, and find out which auth 
> methods they have in common, if any. This is true for PACE, and also for 
> version -04 of SPSK, i.e. before it adopted your framework.

Yes all drafts now have negotiation method happening in the
IKE_SA_INIT, which is good. 

> Regarding IANA allocation, I would like to quote from RFC 5226:
> 
> "The designated expert is responsible for initiating and coordinating 
> the appropriate review of an assignment request.  The review may be wide 
> or narrow, depending on the situation and the judgment of the designated 
> expert.  This may involve consultation with a set of technology experts, 
> discussion on a public mailing list, consultation with a working group 
> (or its mailing list if the working group has disbanded), etc.  [...] 
> Designated experts are expected to be able to defend their decisions to 
> the IETF community, and the evaluation process is not intended to be 
> secretive or bestow unquestioned power on the expert."
> 
> I certainly do not want to turn the IANA allocation into a "fight". I do 
> think the community needs to be consulted.

As we have seen from the ipsec list the community does not seem to
care too much, but I myself as a member of the community and also the
person responsible for the IANA registries do care.

I have stated my reasons why I consider allocating multiple payload
numbers etc for exactly same thing a bad thing.

As it seems that IKEv2 might be used with other things than IPsec too
in the future (KARP, 802.15.4, 802.11ai etc) I do see challenges in
the IKEv2 IANA registries.

Even if those use cases are not IPsec they most likely will reuse most
of the registries from the IPsec. We could overlap their numbers with
each other, but on the other hand that can cause confusion, so it
might be better to make sure they do not have overlapping numbers,
i.e. use of unique numbers for different things and mark those as
reserved in the registries which do not use them.

This is bit what IKEv1 and IKEv2 did, for example we are not using
payload numbers 1-32 as they are reserved in IKEv2 registry as IKEv1
used them. Same way our exchange numbers 0-33 are reserved etc.

I am not sure whether we are doing that in the future or not. I want
to think more about this and see the actual protocols before deciding.

But on the other hand I want to keep our options open, which means I
do not want to fill our registries with multiple registrations for the
exactly same thing.

Can you explain me what problems will it cause if the
draft-kuegler-ipsecme-pace-ikev2 is changed so it uses the
draft-kivinen-ipsecme-secure-password-framework framework just like
other secure password method drafts have already done?

In my understanding there will be 2 extra bytes in the IKE_SA_INIT
notification phase to indicate the PACE inside
N(SECURE_PASSWORD_METHODS) and there will be one extra byte (or two
depending how you do it) in the ENONCE and PKEi/PKEr payloads.

So in total the technical differences will be 7 extra bytes. Is there
anything else?
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Aug 2011 09:11:32 -0700

> person responsible for the IANA registries do care.

You are *not* responsible for the IANA registries. RFC 5226 says:

   It should be noted that a key motivation for having designated
   experts is for the IETF to provide IANA with a subject matter expert
   to whom the evaluation process can be delegated.  IANA forwards
   requests for an assignment to the expert for evaluation, and the
   expert (after performing the evaluation) informs IANA as to whether
   or not to make the assignment or registration.

. . .

   Designated experts are expected to be able to defend their decisions
   to the IETF community, and the evaluation process is not intended to
   be secretive or bestow unquestioned power on the expert.  Experts are
   expected to apply applicable documented review or vetting procedures,
   or in the absence of documented criteria, follow generally accepted
   norms, e.g., those in Section 3.3.

I do not believe that you can defend a decision to reject registrations based on what is in RFC 4306. If you disagree, please show which text you are referring to.

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

> to think more about this and see the actual protocols before deciding.

This should be a WG/IETF decision, not that of a single person.

> do not want to fill our registries with multiple registrations for the

See above.

> So in total the technical differences will be 7 extra bytes. Is there

Regardless of what the authors of this document do, that question is not relevant to whether or not you, as the designated expert, give them a codepoint.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 1 Aug 2011 12:29:13 -0700 (PDT)

On Mon, August 1, 2011 9:11 am, Paul Hoffman wrote:
> 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.

---

From: Sean Turner <[email-masked]>
Date: Tue, 02 Aug 2011 08:47:14 -0400

>> person responsible for the IANA registries do care.

WRT who is responsible ...

Technically, IANA is responsible for maintaining the registries in 
accordance with the registration rules documented in the RFC that 
creates/defines the registry.

The IANA experts (who are appointed by the IESG) are responsible for 
reviewing requests for additions and modifications in the registries 
that they are designated for.

The IETF/IESG is ultimately responsible for the registry as (most of 
them) are a product of the IETF process.

> I do not believe that you can defend a decision to reject registrations based on what is in RFC 4306. If you disagree, please show which text you are referring to.

My understanding is that Tero is stating early that he would deny the 
requests based scarcity of code points, which is allowed per RFC 5226:

   Possible reasons to deny a request include:

       - scarcity of code points, where the finite remaining code points
         should be prudently managed, or when a request for a large
         number of code points is made, when a single code point is the
         norm.

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

But, they're for the same "thing": extension(s) to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared
secrets.

spt

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Aug 2011 16:12:18 +0300

>    or not to make the assignment or registration.

Ok, perhaps using word of being responsible for the IANA registries is
wrong as IANA will be responsible for the actual registries, but it is
my understanding that designed expert is support to help IANA to keep
the registries usable. 

> I do not believe that you can defend a decision to reject
> registrations based on what is in RFC 4306. If you disagree, please
> show which text you are referring to. 

If I have to be able to defend all my decisions to reject things based
on the RFC4306 only, there is no way I can reject anything as the only
text in there is text which says:

----------------------------------------------------------------------
   Note: When creating a new Transform Type, a new registry for it must
   be created.

   Changes and additions to any of those registries are by expert
   review.
----------------------------------------------------------------------

So if someone sends IANA a request (note, you do not even need
Internet-Draft or RFC) saying that he made typo in his code and wrote
53 instead of 3 for his 3DES algorithm number and now wants to make
new allocation saying that 53 means ENCR_3DES, then I do not have any
way to say that this should not be allowed to IANA, as RFC4306 does
not give such option. 

Or if someone wants to change numbers like Diffie-Hellman Group
Transform ID 19 to mean completely something else than what it means
now (which actually did happen, and during that discussion area
directors managed to convince me that it would be better to accept
that change of existing codepoint, and not allocate new codepoint for
this new use).

What is the point of having designated expert if there is nothing he
can do than to follow RFC creating the registries, especially when
those RFCs do not give any specific instructions?

My undestandating has been that as the RFCs creating the IANA
registries do not include exact rules for allocations then it is
designated experts responsiblity to interpreted what could have been
said in the RFC in question for those allocations.

This would mean things like "do not make changes to existing code
points which are not needed", "do not make duplicate allocations for
existing code points without good reason" etc.

In some cases it is needed to do that kind of things, like there was
in the ECP group i.e. some of the existing vendors had already used
the number in question that way and it was seen that those vendors
were important enough and slow enough that they would never update
their products to new numbers if such numbers would be allocated.

In some cases there is no need to break those unwritten rules. This is
the case where I do not see real reason to break those unwritten rules
which say "no duplicate codepoints for the same thing".

Of course people who are unhappy with the work of the expert are
allowed to appeal to the IESG about every decision the expert makes.

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

Note that I did not claim that three proposals are "exactly the same
thing", I said that the payload types they allocate are "for the
excatly same thing", i.e. transfering secure password protocol
specific data between the peers.

In RFC4306 we do not have separate KE payload allocated for each
different key type (one for ECP, one for MODP etc). Same goes with the
CERT/AUTH etc payloads. The RFC4306 usually allocates one payload
number for one specific purpose and if multiple different formats for
the same thing is needed then there is subtype inside this payload.
This is true for KE/IDi/IDr/CERT/CERTREQ/AUTH/TSi/TSr/CP payloads at
least. SA/N/D payloads hava protocol ID inside which then changes the
values going after it. Actually only the Ni/Nr/V and EAP payloads do
not have subtype inside, and in EAP case there is subtype, but it is
inside the EAP payload.

I.e. the current RFC4306 use of payloads do use subtypes a lot and
those subtypes change the payload format inside the main payload.

We do have two numbers for the same payload in the RFC4306 case,
especially for TSi/TSr and IDi/IDr, but this is because both of those
payloads (i.e. TSi/TSr and IDi/IDr) can happen in the same message,
and we wanted to remove the ordering restriction from there, meaning
instead of relying on the payload order to decide which of them is
initiator payload (TSi/IDi) and which is responder (TSr/IDr) we have
separate numbers for them. On the other hand we also use Ni/Nr for
nonces, but they only have one payload number allocated for them as
they can never happen in the same message, thus it is easy to see
which one is which.

There are similar reasons why there is no need to allocate separate
exchange type for each of the protocols (all of them follow the
similar payload exchanges which are already done for the EAP, and we
didn't allocate separate exchange type for IKE_AUTH when used with
EAP, so we should not do it here too).

To come back to the "The tree proposals do not do exactly same thing",
I do also consider the tree proposals do the same thing; they provide
solution to exactly same problem. They do have technical differences,
but they provide solution to the same problem, which I do consider
meaning they are do same thing.

> This should be a WG/IETF decision, not that of a single person.

How on earth can you interpret statement saying "I am not sure whether
*we* are doing that in the future or not." to indicate that it will be
a single persons decision?

I *as a community member* and as a designated expert do want to think
more about this before giving my input about this in future, and I do
not want to close our options now.

Also the WG will most likely be closed before those decisions needs to
be done. If I will get asked input from IANA as designated expert, I
will of course ask input from the community (ipsec-list) too, but the
list has not been as active as you would like to get input for
different things lately.

Note, also that those documents will most likely come from the other
working groups and go through their own WGLC and then go to the IESG,
and they might have separate IANA registries and separate designated
etc.

This part of the discussion is bit early, but as it is the problem
that I can see that the designated expert of the ikev2 registries
might see in the future (how far in future is different thing), and I
happen to be the designated expert now, I want to think about this
early, not only after the problem is there.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 07:24:03 -0700

On Aug 2, 2011, at 5:47 AM, Sean Turner wrote:

> My understanding is that Tero is stating early that he would deny the requests based scarcity of code points

For a registry of this size with so few codepoints allocated so far (and so many reserved code points that can be allocated later) that could easily be extended later, this would be an example of premature scarcity.

> mutual authentication based on "weak" (low-entropy) shared

This line of argument would allow Tero to not allocate code points for SHA-3, because it does the "same thing" as SHA-2. Let's not go there.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 07:43:05 -0700

> my understanding that designed expert is support to help IANA to keep

Absolutely. And, you have done a fine job of that so far (certainly better than I could have done). In my mind, keeping serious proposals for IKEv2 functionality out of the registry does not keep it useful.

> text in there is text which says:

You can reject whatever you want, subject to IETF review. This thread is that review, ahead of time. I am disagreeing with your apparent decision to reject these ahead of time.

> specific data between the peers.

And SHA-3 will do "exactly the same thing" as SHA-2: will you not allocate code points for it? :-)

> those subtypes change the payload format inside the main payload.

Sure, but that is because we knew which values we wanted when we wrote IKEv2. Today, we are talking about extensions.

> meaning they are do same thing.

Thank you for giving the fuller explanation of your thinking. However, I still don't think that justifies rejecting ahead of time the idea that each gets its own IANA allocation: it just argues more effectively for your current draft on how to negotiate them. I think those two are completely separate discussions, which is why I changed the subject on this thread.

> a single persons decision?

The "I" part. The expert reviewers for some IANA registries seem to think that they are the ones who do this consideration, and your use of "I" instead of "we" concerned me. (This could be an English/Finnish thing...)

> not want to close our options now.

Yay! We are in agreement then.

> list has not been as active as you would like to get input for

If you have questions about what you are doing as expert reviewer, by all means please start discussions on this list, regardless of whether it is a WG or not.

> and they might have separate IANA registries and separate designated

And this list should discuss that as well.

> early, not only after the problem is there.

Assuming you mean "we" instead of "I" there, we are in complete agreement.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Aug 2011 19:00:48 +0300

> And SHA-3 will do "exactly the same thing" as SHA-2: will you not allocate code points for it? :-)

If we knew as much about algorithms as we do about protocols, yes. But we don't. We don't know what algorithm will be considered secure in 2020, and that is why there's a (rough?) consensus in the IETF that algorithm agility is a "good thing".

There is no such consensus that protocol variants are a good thing. I think it's just the opposite. Although I don't think it's Tero's job to stop the publication of three documents that are "for the same thing". That should be done by the community.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Aug 2011 16:23:20 +0300

Paul Hoffman writes:
> Absolutely. And, you have done a fine job of that so far (certainly
> better than I could have done). In my mind, keeping serious
> proposals for IKEv2 functionality out of the registry does not keep
> it useful.

I have not tried to keep any proposal out from the IKEv2, I wanted the
proposals which do about same thing, and which already have separate
mechanism to negotiate which of them is used, to use same numbers for
the payloads / exchange / authentication types in the IKE_AUTH phase.
The only differences in the for example for the exchange type would be
to use number 35 as exchange type instead of allocating new number.
Same thing with payload number, i.e all three proposals would be using
same payload number for their own payloads.

All three of the protocols can still be used, I just wanted them to
use same numbers for same things as this is how IKEv2 does for those
registries.

We have IKE_AUTH, not IKE_AUTH_PSK_CERT, IKE_AUTH_EAP_FIRST,
IKE_AUTH_EAP_INTERMEDIATE, IKE_AUTH_EAP_LAST. Creating two new
exchanges IKE_PACE, IKE_PACE_AUTH is not how IKEv2 does things
normally, especially as the IKE_PACE combined with IKE_PACE_AUTH looks
very much like IKE_AUTH done with EAP, except that it uses secure
password method specific payloads instead of EAP payloads.

Also as I said in EAP we do have one EAP specific payload we use to
transmit all EAP specific data inside the IKE_AUTH. We do not have
multiple EAP specific payloads transmitting differenet EAP payloads in
IKEv2. We could have EAP_REQUEST, EAP_RESPONSE, EAP_SUCCESS,
EAP_FAILURE payloads in IKEv2 instead of using just one EAP payload.
Especially as the IKEv2 code needs to check into the code inside to
see whether it is EAP_SUCCESS or EAP_FAILURE.

IKEv2 way of allocating IANA numbers have been so that it tries to
save numbers especially on the 8 bit registries. 

It is very different when you compare what we have done for example in
the Encryption Algorithm Transform IDs registry. That registry is
16-bit registry with 1022 numbers for IANA to allocate, and there we
have for example 9 numbers allocated for different AES variants (CBC,
CTR, CCM_8, CCM_12, CCM_16, GCM_8, GCM_12, GCM_16, GMAC).

> You can reject whatever you want, subject to IETF review. This
> thread is that review, ahead of time. I am disagreeing with your
> apparent decision to reject these ahead of time.

That would be fine, if you would defend your disagreement with
technical reasons, but you seem to be just rejecting about the fact
that any numbers could be rejected even with technical reasons.

I have given out my reasons why I want all of those methods to use
same number space (i.e. want to keep the registry clean, do not want
to allocate duplicate numbers for same things (not same protocols, but
for example same kind of payloads), want to keep allocations in the
same way other allocations in IKEv2 has been done etc).

I have listed some of those in my previous emails, altough it might be
that I have not formulated all of them very throughly and those
reasons might have been scattered in different emails, and I have
mostly concentrated in the most technical aspect, i.e. the small
number space of payload numbers, and keeping the more political ones
(like following the similar way of doing allocations than what is done
in the IKEv2 RFC) in the background.

> allocate code points for it? :-)

SHA-3 will get code point, as will any other reasonable cipher/hash.
Actually SHA-3 will most likely get 3 + 3 code points as this is how
things are allocated in IKEv2. I.e. it will get 3 code points in the
PRF registry for 256, 384 and 512 bit sizes and it will also get 3
code points in the Integrity Algorithm Transform ID registry.

Those registries are 16-bit registries, and they have 1022 numbers for
IANA allocation and 64511 for private use. I do not see any reason to
limit allocations for SHA-3 in that registry as that is not small
registry, and the way we normally do allocations there is to encode
the size to that number.

I would most likely be against if someone would like to create new
Transform Attribute Type for HASH Length attribute (similar than what
we now have for Key Length arttribute for encryption cipher), and then
said that we only allocate one SHA-3 attribute and mandate it to be
used with that new HASH Length attribute type with values indicating
whether it is 256, 384 or 512 bits. My reason would be that it is so
much different than current IKEv2 allocations for hashes.

On the other hand if SHA-3 family will support any random bit lengths
and someone wants to support SHA-3-1, SHA-3-2, SHA-3-3, ...
SHA-3-1023, SHA-3-1024, then I would exactly propose using the method
above instead of allocating 1024 numbers to the SHA-3.

And in both cases I would try to convince the people doing that work
way before it comes to IANA allocation phase, and I would again be
telling that my reasons might still be same if it comes to IANA
allocation phase (as I did in this time).

> Sure, but that is because we knew which values we wanted when we
> wrote IKEv2. Today, we are talking about extensions.

We are talking about extensions which know EXACTLY which subpayloads
they want to support. For two of the drafts there is exactly one type
of payload they send, for one there is two different payloads in both
directions. And everything what goes inside the payload is going to be
method specific anyway, so if someone make yet another secure password
method then they format their payload as they like.

> Thank you for giving the fuller explanation of your thinking.
> However, I still don't think that justifies rejecting ahead of time
> the idea that each gets its own IANA allocation: it just argues more
> effectively for your current draft on how to negotiate them. I think
> those two are completely separate discussions, which is why I
> changed the subject on this thread.

If we do not negotiate the methods at all (as some of them didn't)
then there would be no other option than to allocate each of them some
separate numbers, as that would be only way to distinguish them.

So to have *a* way to know which method is used, is requirement for
the shared allocations.

Note, that method does not need to be same for all drafts, there just
needs to be some way to know which method is used. All current methods
already have a way to know which method is used, altought the way is
not same.

> The "I" part.

I cannot speak for the whole working group / IETF, which is why I said
that I am not sure what we (meaning the WG / IETF) are doing in
future. 

> The expert reviewers for some IANA registries seem to think that
> they are the ones who do this consideration, and your use of "I"
> instead of "we" concerned me. (This could be an English/Finnish
> thing...)

The "I" part refered to my own thinking, the "we" part refered to the
community who decides. I do not think collective thoughts are that
common yet (at least here in Finland), so I usually think I will be
using I when I refer to my own thoughts...

Saying "We are not sure whether we are doing that" would indicate
majestic plural for my ears, which might have been even worse...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Aug 2011 16:55:19 +0300

Yoav Nir writes:
> There is no such consensus that protocol variants are a good thing.
> I think it's just the opposite. Although I don't think it's Tero's
> job to stop the publication of three documents that are "for the
> same thing". That should be done by the community. 

I am most definately not trying to stop any of the documents.

I am trying to make sure that the documents can go forward and get
IANA allocations done in a nice and consistent way, which will also
make it easier for implementors to implement one or multiple of those
methods.

The actual numbers used inside the protocols does not affect the
actual protocols that much, especially as there are no numbers in any
of the documents yet (i.e. you cannot say changing the numbers would
break interoperability with early implementations).
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Aug 2011 17:00:13 +0300

>make it easier for implementors to implement one or multiple of those

Fully agree. But I also think that it *is* up to the community to stop
these three from moving on, and choose only one of them instead.

Since we haven't found any expert who will say that one is definitely
better than the others, almost any selection method will do.

Sean and Paul rolling a big fuzzy die at the SAAG meeting in Tai-Pei is
one good way to do this.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Aug 2011 20:09:17 +0300

Hi Yoav,

as a coauthor on one of these documents, I find your proposal below 
positively insulting. There were three author teams, and you should give 
them credit for having rational reasons for publishing these documents 
and moving them through the IETF progress.
Rolling a dice is a lazy solution that wouldn't result in an outcome we 
can justify. OTOH, an open cryptographic review of the three options 
most certainly would. Until such a process takes place, I would rather 
we have three Experimental protocols.

Thanks,
Yaron

On 08/03/2011 05:00 PM, Yoav Nir wrote:
>
> On 8/3/11 4:55 PM, "Tero Kivinen"<[email-masked]>  wrote:
>
>> Yoav Nir writes:

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Aug 2011 21:07:46 +0300

On Aug 3, 2011, at 8:09 PM, Yaron Sheffer wrote:

> most certainly would. 

The way I've heard it, such a review did take place without the desired results.

Managers sometimes need to make decisions even without complete knowledge. And in such cases that decision can seem to be based on a hunch or rolling the die. It's better than this decision not to decide, because it shifts the burden to developers.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Aug 2011 21:43:48 +0300

The IETF prides itself on an open process, and I would expect such a 
review to take place in an open and documented manner. Even if the 
bottom line is, "they are all the same". A named individual should take 
responsibility for the outcome.

And if vendors are so interested in a PAKE solution, well they could 
always sponsor a starving cryptographer for a few days' work, for the 
benefit of the community. In fact I can think of at least one VPN vendor 
who actually employs cryptographers.

Thanks,
Yaron

---

From: Sean Turner <[email-masked]>
Date: Wed, 03 Aug 2011 14:58:18 -0400

> I am most definately not trying to stop any of the documents.

To make it clear.  Tero came up with the framework.  I told the authors 
to adopt to it.

spt