Subject: [IPsec] Proposal for the secure password authentication method problem

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2011 15:17:46 +0300

As we all know we (as a wg) did fail to pick one secure password
authentication method, and the latest count seems to be that we are
going to have 4 of them.

All of them seem to be mostly same from the IKEv2 protocol point of
view, but each of them are implemented differently. All of the
proposals do have very common structure, i.e. they add some new
payloads and round trips to the IKE_AUTH step and in the end when the
secure password exchange finishes they will send (differently created)
auth payloads and finish the negotiation.

When looking at the protocols it seems to me that we could create one
generic framework for all of the methods, i.e. we could make it so
that all of the methods can co-exists in the same implementation and
they can be configured to be used just like any other feature. I do
not see any point of allocating separate payload numbers, exchange
types, error codes etc for each of them, as that will add much more
complexity to the implementations.

What I propose it that we create one secure password authentication
method framework (SPAM framework) and all those drafts (spsk, hush,
augmented pake, pace) will be changed to use that same framework.

I can write that framework draft if needed.

The framework would be something like this:

1) Add new notification to the IKE_SA_INIT telling which SPAM
   algorithms are supported. This will notification will include tuple
   of 8-bit integers containing the 8-bit SPAM algorith number and
   8-bit password preprosessing technique number. The initiator sends
   all supported algorithms and responder will pick one algorithm
   which is to be used. The other option here is that reponder lists
   which algorithms which it supports and initiator can then use any
   of them.

   Payload format will be:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |   SPI Size    |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Security Parameter Index (SPI)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Notification Data                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where Protocol ID will be 0, SPI Size 0, Notify Message Type TBD, SPI
   empty, and Notification data contains those numbers.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SPAM Alg 1  | Prep Method 1 |   SPAM Alg 2  | Prep Method 2 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SPAM Alg 3  | Prep Method 3 | ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SPAM Algs would be something like SPSK, Pace, AugPake, hush etc.

   Prep methods would be something like none, rfc2759, SASLprep etc.

2) Add new payload to the IKEv2 which will contain all SPAM specific
   payloads. This payload will have following format:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SPAM Alg      | Prep Method   |  SPAM Alg Specific Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                SPAM Algorithm Specific Data                   ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the SPAM Algorithm and Prep method are the selected ones from
   the IKE_SA_INIT, and the SPAM Algorithm Specific Type is the
   payload type specific for each SPAM Algorithm.

   For SPSK the SPAM Alg Specific Types is commit.
   For pace the SPAM Alg Specific Types are ENONCE, PKEi, PKEr.
   For AugPake the SPAM Alg Specific Types are PVi, PVr, Vrfyi, Vrfyr. 
   For hush the SPAM Alg Specific Types are Encrypt, and Protect. 

   The SPAM Algorithm Specific Data contains then data specific to the
   algorithm and the type.

3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the
   extra payloads in them depend on the SPAM algorithm used, and the
   SPAM algorithm used also affects the AUTH payload generation. The
   exchange will similar to EAP, i.e.:
   
   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni,
        N(SPAM_METHODS) -->
                                <--  HDR, SAr1, KEr, Nr, [CERTREQ],
                                          N(SPAM_METHODS)
   HDR, SK {IDi, [CERTREQ,]
       SPAM_PAYLOAD,
       SPAM_PAYLOAD, ...
       [IDr,] SAi2,
       TSi, TSr}  -->
                                <--  HDR, SK {IDr, [CERT,] 
                                         SPAM_PAYLOAD,
                                         SPAM_PAYLOAD, ... }
   HDR, SK {SPAM_PAYLOAD, ...}  -->
                                <--  HDR, SK {SPAM_PAYLOAD, ...}
   HDR, SK {[SPAM_PAYLOAD, ...],
            AUTH}  -->
                                <--  HDR, SK {[SPAM_PAYLOAD, ...],
                                              AUTH, SAr2, TSi, TSr }

   I.e. there can be multiple IKE_AUTH exchanges, each having number
   of SPAM_PAYLOADs in them (from 0 to n, where n depends on the SPAM
   algorithm selected). The first IKE_AUTH request contains normal
   IDi, IDr, SAi2, TSi, TSr. The final IKE_AUTH request contains AUTH
   payload which includes normal data included in AUTH, and the
   algorithm specific data. The final IKE_AUTH response contains
   similar AUTH and SAr2, TSi, and TSr payloads. Final messages may
   also contain extra SPAM_PAYLOADs if needed.

This kind of framework would allow using any of the secure password
authentication methods in a way where they can co-exist in the same
implementation. If the implementation is done properly, then it might
be even possible to make it so that new algorithms can be added
easily.

The proposed protocol is mostly there for start of discussion and the
final version might be different what I outlined above. I have quickly
checked all password method drafts through and I think it should be
quite easy to fit all of the mehods to this kind of framework.

If people think this is good idea, I can write the first version of
the framework draft and submit it as internet-draft quite soon, but
before I start working on this I would like to get some feedback from
others whether this is good idea, and whether authors of those methods
would be willing to convert their drafts to use this framework. If the
authors are not willing to use this framework then there is no point
of creating the framework. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Apr 2011 15:29:05 +0200

> of creating the framework. 

Hi Tero

I have mixed feelings about this. It's better than all four of those drafts advancing separately. OTOH this plug-innable architecture is pretty much admitting defeat. It sets us up to have a situation like EAP, with lots of different methods, and no guide to implementers as to which methods to implement.

But I guess it's the lesser evil.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 09:38:09 -0500

> I have mixed feelings about this. It's better than all four of those drafts advancing separately. OTOH this plug-innable architecture is pretty much admitting defeat. It sets us up to have a situat…

Plugin architecture != no guidance as to required to implement
mechanisms/methods.  Besides, one of the nice things about plugin
architectures is that third parties can fill in voids when specific
methods/mechanisms go unimplemented.

> But I guess it's the lesser evil.

I don't get the hostility to pluggable authentication architectures.
Why on Earth should any of us dictate to users what kinds of
authentication infrastructures they must have?

For far too long we've had too many protocols with completely disjoint
authentication technology support, leading to customers having to
deploy many authentication infrastructures.  Some protocols only
handle PKIX well.  Others only handle Kerberos well.  Others only
handle AAA well.  Yet others have ad-hoc authentication systems.

Forcing customers to deploy multiple authentication infrastructures
means forcing them to setup expensive synchronization for expensive
systems that they shouldn't need.  How is that a good thing?

The *only* way to put a stop to this madness is to make all these
protocols pluggable.  Some of us have been trying to do so for a
while.  We have the following successes to point to:

 - SASL/GS2 -- a new bridge for using GSS-API mechanisms in SASL applications.
 - SSHv2 support for GSS-API-based authentication.
 - Channel binding (RFCs 5056 and 5929), which allows for composition
of security technologies.
 - IKEv2 and KINK (which altogether allow IPsec to support the use of
PKIX, Kerberos and EAP for end-point authentication).
 - ABFAB WG -- a WG working on standardizing an EAP-based,
federation-capable GSS-API mechanism.  I count this as a success
because ABFAB is quite far along.

Other work items in progress that should help round up this picture:

 - PKU2U (a PKIX-based GSS-API mechanism).
 - Additional GSS mechanisms being proposed at ABFAB and/or KITTEN
(there's a SAML-based one and an OAuth-based one).
 - draft-williams-tls-sasl-opt.

We have quite a few protocols that support SASL or the GSS-API straight out:

 - SASL application protocols: LDAP, IMAP, SMTP/SUBMIT, ...
 - GSS application protocols: RPCSEC_GSS/NFSv4, DNS (GSS-TSIG), SSHv2, FTP, ...

We also have protocols that only support PKIX well and everything else
in a half-hearted way, if at all (TLS, I'm looking at you).

Please, let's put an end to the madness and adopt a pluggable approach
to authentication (being careful to ensure channel binding to the
actual security layers whenever the authentication facility's security
layers are not used or when it lacks them).

Nico

PS: "Security layer" is a term from SASL meaning "the layer that
provides integrity and, optionally, confidentiality protection to
application data.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 11:30:23 -0500

> complexity to the implementations.

We already have three generic authentication frameworks: SASL,
GSS-API, and EAP.  Must we add a fourth one?  (We also have a number
of less generic ones, such as the ones in SSHv2, TLS, ...).

Considering that: a) we have EAP in IKEv2, b) there are reserved
numbers for using the GSS-API in IKEv1, and we could make it usable in
IKEv2, c) we have a plethora of EAP methods and GSS-API mechanisms
available now or soon, ...  why create a new framework?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 12:00:47 -0500

>   which algorithms which it supports and initiator can then use any

8-bit?!  BTW, sending SASL mechanism names, or EAP method names, or
GSS-API mechnism OIDs wouldn't be that different from sending 8-bit
mechanism numbers.  But it'd be way better, because you'd be using an
off-the-shelf framework.  Off the shelf is good, for all the reasons I
gave earlier and then some (more mechanisms exist, the frameworks have
a better chance of being pluggable as implemented, code reuse,
specification reuse, ...)

>   exchange will similar to EAP, i.e.:

AUTH payloads should be where channel binding is done, yes.  We should
definitely think in terms of CB here, and if you were to use SASL or
the GSS-API then you'd get the necessary CB functionality right off
the bat.

(Incidentally, your design also reminds me of SSHv2.)

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 12 Apr 2011 11:01:09 -0700 (PDT)

Hi Nico,

> authentication infrastructures they must have?

  We do that when we ship support for some authentication credential
in product. Whether it's a particular EAP method or a TLS ciphersuite
or support for particular authentication method in IKE.

> systems that they shouldn't need.  How is that a good thing?

  That's exactly what this pluggable stuff gets us. GSS, EAP, RADIUS,
and how is authentication happening? Well that's not really decided
yet. But we have these multiple, pluggable, authentication infrastructures
that you have to support before you can even get to the point of thinking
of your authentication credential.

> protocols pluggable.

  Actually I think that is the madness.

  If the EAP in TLS plan goes forward we could have some deployment
of EAP-TLS with the TLS ciphersuite doing EAP and the EAP method used
for that is IKEv2 and using EAP-only as the authentication method and
EAP-GSS inside that!

>                       Some of us have been trying to do so for a

  I think I'm more in the camp of counting ABFAB as an abomination.

  Treating authentication protocols that have been designed for a
particular purpose as some generic mechanism results in much insecurity
in the deployed world (the "let's use TLS" instinct is widespread and it
is seldom deployed correctly. Making them totally pluggable can only make
it worse.

  regards,

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 13:53:44 -0500

> or support for particular authentication method in IKE.

Who ships credentials?  Customers control credentials, not vendors.
(The only exception is default trust anchors, which are a sort of
credential.)

> of your authentication credential.

Pluggable authentication frameworks are NOT the cause of multiplicity
of authentication infrastructures.  You might have argued that if we'd
only ever had one True authentication mechanism then pluggable
frameworks would have been bad, but a) you didn't so argue, b) that
was never the case anyways (SASL mechanisms came first, the framework
later, same for EAP, for example, and Kerberos and PKIX are
contemporaries, and so on).

Reading into what you write above you seem to think that it's not
possible to abstract authentication sufficiently well (for IKEv2's
purposes, in this case).  I disagree.  I'll grant only that there's
only one framework that has gone any of the distance to properly
abstracting authentication, and that's the GSS-API (which I gather you
revile, but preferably you could explain in detail).

> for that is IKEv2 and using EAP-only as the authentication method and

I'm not fond of the proliferation of authentication frameworks.  If
you thought I was, you misunderstood.  I'd rather see one framework
win (which is why we did the SASL/GS2 bridge to GSS-API mechanisms).
We have all the frameworks that we have because historically various
groups created them independently, often as a generalization of the
reality that various protocols were pluggable but without a generic
framework (this is true of EAP and SASL).  And here Tero is proposing
yet another pluggable framework.

Tero's proposal: create a new pluggable authentication framework.
My proposal: pick an off-the-shelf framework.

Your proposal: ??  Force a single authentication mechanism on all?
But you know what will result: eventually others will add
alternatives, and then someone will say "hey! I know, we can
generalize what we have and create a framework", and then we've
repeated history, and badly at that.

What am I missing?  I mean, I get the sentiment and I sympathize (I
wish we had had exactly one pluggable authentication framework, not
N>3 as we do), I do.  We need stronger arguments either way, however.

>  I think I'm more in the camp of counting ABFAB as an abomination.

I'm not really fond of some aspects of it.  I strongly dislike certain
aspects of EAP, AAA, and SAML -- all major components of ABFAB.  But
it fills a void.  And it will work with the infrastructures that
people have.  I don't see anyone coming forth with better
alternatives.  In any case, the ABFAB WG's mechanism fits in an
existing framework, so there are only two possible outcomes: it gets
adopted or it doesn't.  Compare to the possible outcomes if we create
new frameworks: likely more fragmentation of authentication mechanism
support, leading to more redundant authentication infrastructure
deployment or else market failure for the framework and the protocol
consuming it.

> is seldom deployed correctly. Making them totally pluggable can only make

"Results in much insecurity" is a strong assertion and requires
something a lot more concrete than pointing at TLS.  The fact that TLS
is used in weak ways is not really a result of having pluggable
authentication systems -- I'd say it's exactly the reverse because the
lack of suitable password-based authentication mechanisms meant it was
easiest to just send passwords over some secure channel, and that
channel could only really be secured with a PKI, all the while PKI
could not scale to Internet scale, which meant we ended up with what
we have.  Whereas if we'd had composeable authentication mechanisms we
could have had channel binding to TLS eons ago and saved ourselves a
lot of trouble.

The fact is that technology grows organically.  When you analyze the
failures of the past you have to be careful to find the right lessons.
 Here we see what would be a new branch of organic growth, but in this
case we really can and must apply lessons from the past, one of which
is that we shouldn't re-invent wheels willy nilly.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 12 Apr 2011 12:39:14 -0700 (PDT)

Hi Nico,

On Tue, April 12, 2011 11:53 am, Nico Williams wrote:
>> Â We do that when we ship support for some authentication credential

  I said _support_ some credential, not ship the credential. If your
product supports EAP-SIM then what I'm saying is you are "dictating to
users what kind of authentication infrastructure they must have", namely
one that supports SIM cards.

> Your proposal: ??  Force a single authentication mechanism on all?

  No no, not at all. Robust and misuse resistance is my proposal. Using
the best technique directly in the protocol for the chosen credential.
If you want to use certificates then use a certificates in the exchange.
If you want to use a password then use a password in the exchange. But
"lets use X" where X is some pluggable framework is definitely not
my proposal.

  I proposed adding PAKE to IKE because people use passwords for
authentication and that is rife with misuse. "Why not just use EAP?" was
the question. Why not just use this pluggable authentication method?
Well two reasons: 1) it's a pointless encapsulation that also increases
the number of rounds; and 2) because it's pluggability encourages misuse
(i.e. do EAP-MSCHAPv2 in EAP-only IKE).

  I'm a bit undecided on Tero's proposal. I tend to get in trouble when
I ascribe motivation to things people do so I won't do that, but as
someone who actually implements the protocols we design here I think
having n protocols, where n > 1, to solve a single problem with no clear
"winner" means that for interoperability reasons I have to implement
all n and that's a shame. Since Tero actually implements these protocols
too I think he might share that concern.

  It might be possible to get the authors of the competing drafts to
rely on a common method of identifying the intent of the initiator
(currently PACE uses a Notify and SPSK uses the mandatory bit) and
ensure that their protocols all look the same-- send a blob, get a blob,
send another blob, get another blob-- and to mix results from PAKE
exchange into results of the D-H exchange in a uniform manner and we might
get the equivalent of what he's proposing without Yet Another Pluggable
Architecture (which I guess we both agree would be not-so-good).

  Now the drafts are in LC. Maybe a few comments could get the authors
to align their drafts so they look architecturally identical while
implementing different exchanges.

  regards,

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 14:45:00 -0500

> one that supports SIM cards.

Oops, sorry I misread that.

> "lets use X" where X is some pluggable framework is definitely not

"If you want to use certs then use certs... if you want to use
passwords then use passwords ..." implies an authentication framework
with at least two authentication mechanisms (and negotiation!).

So you're for at least one authentication framework.  Only you weren't
aware of it.  Or what did I miss this time? :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 15:00:43 -0500

> too I think he might share that concern.

I strongly disagree with this.  I mean, I agree with not wanting to
implement N>1 or N>2 mechanisms, but that's the beauty of pluggable
frameworks: you publish a plugin SPI and then you can let third
parties ship the plugins that you don't care about.

The only other alternative that works for customers is "protocol
transition", which I'll admit I like as well.  Think of SACRED, kx509,
PKINIT, and so on.  Each of these allows you to use one credential of
one type to obtain a temporary credential of another type.

> Architecture (which I guess we both agree would be not-so-good).

I'm quite skeptical that you (the IPsec WG in this case) can design a
pluggable framework that will only be used for password-based
authentication and which will not grow to be yet another pluggable
framework with all the issues you dislike (including the need to
implement N>1 mechanisms).  And yes, we agree that yet another
pluggable framework would be bad.

I fail to see how Tero's proposal makes any headway.  Customers who
have and want to use AAA will not be able to use it, near as I can
tell, and if you undertake to make it possible to use AAA in Tero's
proposal then you'll be quickly approximating EAP re-invention.  Thus
my skepticism.  It's not pessimism because the obvious solution is to
use an off-the-shelf solution.

> implementing different exchanges.

Which I-Ds are in last call??

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 12 Apr 2011 13:03:40 -0700 (PDT)

Hi Nico,

> aware of it.  Or what did I miss this time? :)

  No I don't think you missed it. The "framework" is just IKE and if
we want to use a credential in IKE we should use it directly and in the
most robust and misuse resistant way possible. In my opinionated opinion,
putting a pluggable framework, like EAP, into IKE was a mistake and
putting in another to use some particular credential would compound that
mistake.

  regards,

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Apr 2011 23:13:13 +0300

Hi,

I'd like to skip through the architectural bits in a hurry, and then 
come back to Tero's proposal. All while rapidly flipping hats :-)

In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 
5998) could get us all we need for password authentication, and 
eliminate the use of insecure "shortened shared secrets" (abused PSK) in 
IKEv2. An implementer could use Dan's EAP-pwd or my EAP-EKE (now both 
published as RFCs) and be done. The WG consensus was that we need 
specific IKE auth methods, because implementing EAP is a pain in some 
situations. I have accepted this consensus and I see no reason to reopen 
this discussion.

[WG co-chair hat off:]

Unfortunately we had just enough energy to decide that we want a "native 
IKEv2" way to do authentication with short secrets; we did not have 
enough energy to pick a winner method. And I don't think we as a WG, or 
the authors of the individual proposals, have the energy to go through a 
"framework" exercise at this point in time. The documents are now in 
IETF LC after having been held up for more than half a year.

Now to Tero's proposal: I'm afraid it is too much of an abstraction for 
what we really need to achieve. I am as unhappy as anybody that we could 
not settle on a single method, but this is water under the bridge. Given 
this situation, we want to minimize the pain for implementors who 
implement 1-2 of these methods (I have abandoned HUSH in favor of PACE a 
while ago, and I somehow don't see anybody implementing all three).

So I don't think we need a whole framework. We just need a way for the 
two peers to negotiate which method(s) they support early enough, i.e. 
in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the 
two other documents' authors to do the same. But I'm willing to be 
convinced to switch to another method if that's the group's preference. 
Other than that, I really don't see the value in uniform "meta-payloads" 
and "super-notifications", or how they would simplify implementations.

Thanks,
	Yaron

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 12 Apr 2011 13:18:39 -0700 (PDT)

Hi Nico,

> use an off-the-shelf solution.

  See that's the whole thing! You can't use AAA because IKE is not a
client-server protocol designed for network access (although some people
try to use it for that). Each side can initiate to the other so each
side needs access to the credential and since there's no way for a AAA
server to initiate EAP to another AAA server you can't use AAA. And if
you can't use AAA then what's the point of using EAP? There isn't one!
It's a pointless encapsulation that increases the number of messages and
invites insecure misuse of IKE. I fail to see any value that a pluggable
authentication framework adds.

  (EAP re-invention might be a good idea. Maybe someone can make it so
a self-described authentication protocol has way of learning an identity
that is useful for authentication purposes. And if a message can get big
enough to be fragmented then maybe defining fragmentation/reassembly
might be a good idea too. Both of those tend to get reinvented with each
EAP method that needs them-- ggrrrrr).

>> Â Now the drafts are in LC. Maybe a few comments could get the authors

  The three PAKE I-Ds:

   - draft-harkins-ipsecme-spsk-auth
   - draft-kuegler-ipsecme-pace-ikev2
   - draft-shin-augmented-pake

  regards,

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 15:37:17 -0500

> putting in another to use some particular credential would compound that

I can understand your frustration with EAP... but look, SSHv2 also has
its own framework and... we ended up adding the option to use another
framework because it was easier that way to add support for all the
authentication mechanisms that we needed in SSHv2.

I predict exactly the same progression will happen here, if you go
down this path.  So what do we gain?  Well, there is expediency -- you
might implement and deploy something very quickly that works for a few
people now who need this now.  Expediency is not a laughable argument,
so I won't be too upset if that's the argument that gets invoked here.

But if we can foresee that this framework will grow and need the same
sorts of mechanisms that are available elsewhere...  why not do it the
Right Way (tm) from the get go?

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 15:48:21 -0500

> EAP method that needs them-- ggrrrrr).

I was just about to say the same thing regarding EAP re-invention :)

I'd just neatly side-step the whole issue by using the GSS-API.  Why?
Because: a) you PAKEs are easy to specify as GSS-API mechanisms, so
going the GSS way doesn't hurt, b) the GSS-API has an abstract API,
which will lead to better PAKE mechanism design (e.g., regarding
principal naming) and also better code design (because the GSS pattern
is eminently reusable), c) if anyone wants AAA you point them to the
ABFAB WG's work (and, if you must, hold your nose).

Tell me: why not GSS?

Oh, and by the way, I can prove that it's fairly easy to specify a GSS
PAKE: just go read RFC5802, which defines one (SCRAM -- not a ZKPP,
but good enough for you to use as a guide).

SCRAM was designed to be specified as simply as possible, with as
little reference to the GSS-API as possible, and with such references
as boiler-plate as possible.  I believe we succeeded.  Moreover, SCRAM
is both, a SASL and GSS mechanism, and this duality was not difficult
to produce because the SASL->GSS bridge was also designed to be as
simple and unobstrusive as possible.

I urge (beg?) you to read RFC5802 _then_ RFC5801. You should find that
RFC5802 (SCRAM) is comprehensible without much reference to GSS-API
and SASL concepts, while RFC5801 (SASL/GS2) requires knowledge of GSS
concepts.  You don't need to implement RFC5801, not even RFC4422
(SASL) in order to implement SCRAM!  That's the best part.

I'm hoping that you'll agree with me that the SCRAM approach,
substituting any PAKE's guts into it, is a good one.

>   - draft-shin-augmented-pake

Thanks.  I'll take a look.  I bet these can all be very easily turned
into SASL and GSS mechanisms ala SCRAM without doing too much violence
to them.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 16:03:24 -0500

On Tue, Apr 12, 2011 at 3:13 PM, Yaron Sheffer <[email-masked]> wrote:
> I'd like to skip through the architectural bits in a hurry, and then come
> back to Tero's proposal. All while rapidly flipping hats :-)

:)

> In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 5998)
> [EAP pain elided -Nico]

Undcerstood.  And from the discussion with Dan I think I've come to
see that there's actually very little difference between what Tero
proposes and what I would consider ideal, which, if I may, would be:

 - Initiator<->Responder: KE payload exchange
 - Initiator->Responder: {SASL/GS2 mechanism name list, [initial
context token for optimistic mechanism choice, with channel binding to
KE]}
 - Responder->Initiator: {Server's SASL/GS2 mechanism name list} |
reply context token for optimistic mechanism choice, with channel
binding to KE
 - Initiator<->Responder: variable number of round-trips, according to
the selected mechanism
 - done

And what do the mechanisms look like?  Easy: look at SCRAM (RFC5802).
SCRAM is a simple successor to DIGEST-MD5.  IKE would need other
mechanisms too, but all of those could be patterned after SCRAM in
terms of specification simplicity.

If you do it this way you needn't even be too aware that you're
actually using the GSS-API framework -- you can ignore it almost
completely.  But the rest of us will get working SASL and GSS
mechanisms out of your IKE mechanisms.  Win-win for all of us.  And if
anyone ever needs AAA?  Point them to ABFAB.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Apr 2011 16:25:08 -0500

And if the mechanism does strong KE then you don't lose a round-trip nor do
channel binding as in my previous example.

The differences between Tero's and my proposal, then are pretty simple:

- the way mechanisms are named;
- names are sent in each mech's messages, not in separate IKE payloads;
- weaker PAKEs, like SCRAM would be used with channel binding to an IKE KE
exchange (while stronger ones simply output key material, avoiding the need
for an IKE KE).

That's it.  Also, my way you'd be using the GSS-API framework, but you
wouldn't have to be aware of that :)

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 13 Apr 2011 09:20:28 +0300

Hi Dan,

as you say below, PACE uses a notification for the initiator to indicate 
its support of the protocol. In fact, both sides get a chance to 
indicate their support.

SPSK uses the Critical (a.k.a. Mandatory) bit for the initiator to 
indicate this support, and relies on an error indication from the 
responder if the responder doesn't like the protocol.

While the SPSK mechanism sort of works in an SPSK-only world, it makes 
the life of implementations that want to support multiple methods much 
harder.

Suppose that Alice wants to talk to Bob. Alice supports PACE, SPSK and 
even EAP-pwd, but has no idea what Bob supports. After the IKE_SA_INIT 
exchange, Alice will know if Bob supports PACE, but will not know if he 
supports SPSK (EAP method negotiation is another can of worms, let's 
leave it for another day). So Alice embarks on the IKE_AUTH exchange 
with only partial knowledge.

If Alice now initiates SPSK (by sending COMi), but it turns out that Bob 
does not support it after all, Bob will reply with an 
UNSUPPORTED_CRITICAL_PAYLOAD. Alice will now have to restart the whole 
exchange with the knowledge of Bob's abilities. This is certainly more 
complex than doing it all within the same exchange. Moreover, since 
authentication never completed, Bob's response is subject to an 
undetected downgrade attack.

Alice would be eternally grateful if an SPSK_SUPPORTED notification were 
added into the IKE_SA_INIT exchange :-)

I'm not sure if there's any valid use for the Critical bit (i.e. for 
non-critical payloads in IKEv2), but negotiating an authentication 
method doesn't appear to be such use.

Thanks,
	Yaron

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 13:24:45 +0300

Yoav Nir writes:
> I have mixed feelings about this. It's better than all four of those
> drafts advancing separately. OTOH this plug-innable architecture is
> pretty much admitting defeat. It sets us up to have a situation like
> EAP, with lots of different methods, and no guide to implementers as
> to which methods to implement. 

I agree on that, and as I stated in my email we did fail in WG...

> But I guess it's the lesser evil.

Thats the idea. I think the worst situation is if all of the 4 drafts
gets published as RFC as they are now and then implementors will be
even more lost which one to implement.

Trying to convince even some of those draft authors to merge their
proposal, or pick one of the others seems to be impossible.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 13:53:08 +0300

> of less generic ones, such as the ones in SSHv2, TLS, ...).

I do not consider this to be generic authentication framework. I
consider this being IKEv2 payload format for encapsulating different
secure password authentication methods to the IKEv2 so those different
methods can co-exist in the same implementation without lots of extra
code. 

> Considering that: a) we have EAP in IKEv2,

Which WG decided was not enough for secure password authentication
because it was not symmetric especially in the implementation side.
The secure password authentication method we are trying to add needs
to be completely symmetric i.e. either end can start sessions without
any problems from the authentication methods point of view.

Most of the IKEv2 implementations only support EAP client side or EAP
server side but not both at the same time. Also if you want to support
EAP server side in both ends of the VPN gateway to gateway
communication you need EAP AAA infrastructure in both ends too, which
is not usually the case or you need to implement the EAP AAA
infrastructure inside the VPN gateway, which also is not usually done.

> b) there are reserved numbers for using the GSS-API in IKEv1, and we
> could make it usable in IKEv2,

If I remember right GSS-API is also asymmetric meaning only there is
clear separation of client and server side, and usually you cannot
assume that if I can act as GSS-API client side and connect to the
server the implementation can also act as GSS-API server side.

I might be wrong on that issue, as I do not know GSS-API that well.

Also getting all those 4 secure password authentication methods
convereted to GSS-API methods is going to require quite a lot of work,
and also binding GSS-API authentication to the IKEv2 authentication
also requires work.

In this system I proposing I do plan to leave those details for the
mehods themselves, i.e. the methods need to describe what kind of
payloads are sent inside the generic payload, and how the AUTH payload
sent inside the IKEv2 needs to be calculated to do the authentication.
The generic framework just offers common way to agree on the method to
be used, and provide generic payload format for transmitting the
methods specific payloads.

> c) we have a plethora of EAP methods and GSS-API mechanisms

Because WG needs to have symmetric secure password authentication
method. We wanted to have one, but unfortunately we failed and now it
looks we are going to have multiple, and those different methods as
written now do not co-exist nicely, and every single one of them do
require modifications to the standard IKEv2. If we create common
payload format which those methods can use, and common way to agree on
which method to use, then the IKEv2 protocol modifications need to be
done only once, and the method specific code can be in separate
module. This module will still tightly integrate to the IKEv2, as it
changes number of exchanges, and adds payloads to the messages, and
also affects how the AUTH payload in the IKEv2 is calculated, but at
least the basic code can be shared between different methods.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 14:09:25 +0300

Nico Williams writes:
> mechanism numbers.

We currently have 4 different methods, and I do think we are going to
be loose one (hopefully two) before they are published as RFCs. I do
not really think there are going to be more in next 5 years. 

> But it'd be way better, because you'd be using an

More is bad. We do not want more. We want less. We would like to have
exactly ONE method, but we could not agree on one, and as document
authors wanted to publish their methods we are now getting four
incompatible, non-interoperable methods which are hard to put in same
implementation as they do not have common method of agreeing which
method to use etc.

Every single one of those methods DO require changes to the IKEv2
library. Most likely you cannot make them really pluggable as they do
change the fundamental parts of the IKEv2, or at least the API between
them and the IKEv2 library is going to be quite complex. Most likely
the API will change a bit depending which method is used, for example
the AUTH calculation do require lots of stuff from the IKEv2 library,
but also lots of stuff from the auth mehtod which means most likely
the easiest way is to give all data IKEv2 has to the method specific
function which will then do the AUTH calculation. This is not going to
be anything generic, but data from IKEv2 that needs to be given to the
method might differ from method to method.

Note, that this changes the IKE_SA_INIT payload, which MUST be kept as
small as possible so it will not get fragmented.

> the GSS-API then you'd get the necessary CB functionality right off

There is no CB there, as the IKEv2 AUTH payload calculation does all
the authentication and the AUTH payload calculation done by all of
those methods MUST meet exactly same security properties that IKEv2
AUTH payload calculation has, i.e. provide same security than what is
explained in the section 2.15 in RFC5996.

This is not really external authentication framework, this is integral
part of the IKEv2 authentication where we just create generic
framework for transmitting those payloads needed by the authentication
method. The authentication method is still doing all the AUTH payload
calculations using the internal data from the IKEv2 (including
InitiatorSignedOctects and ResponderSignedOctects etc). 

> (Incidentally, your design also reminds me of SSHv2.)

The design comes directly from those four different drafts, i.e. I
just checked out what is common with them and created the common
payload format based on that. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 14:30:32 +0300

> purposes, in this case).  I disagree.  I'll grant only that there's

We do have abstract authentication method already in the IKEv2, i.e.
EAP. The problem with that is that it do require infrastructure, which
is bit too difficult to put up when only thing you want to do is to do
shared key authentication between two VPN gateways.

> yet another pluggable framework.

Nope. I am not proposing to create pluggable framework. I am proposing
of getting common parts of the 4 different methods and make them so
they can be used together.

> My proposal: pick an off-the-shelf framework.

That one is not really an option. The options are:

Tero's proposal: make different symmetric secure password
		 authentication methods so they all can be implemented
		 in the same code base.
Other proposal:  do nothing, and publish those four different methods
		 so that you need to manually configure which one of
		 them to use and implement new exchanges, payload
		 formats etc for each of them.

In both cases the methods are still going to be very tightly combined
to the IKEv2, and cannot be separated from there and used elsewhere.
The actual algorithms can be used, but the calculations like:

         found = 0
         counter = 1
         do {
           ske-seed = prf(Ni | Nr, psk | counter)
           ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking")
           if (ske-value < p)
           then
             SKE = ske-value ^ ((p-1)/r) mod p
             if (SKE > 1)
             then
               found = 1
             fi
           fi
           counter = counter + 1
         } while (found == 0)

or 

        skey = F(scalar-op(private,
                           element-op(peer-element,
                                      scalar-op(peer-scalar, SKE))))

        ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")

        AUTH = prf(ss, <msg octets>)

or

      PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),

      AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
      <InitiatorSignedOctets> | PKEr)

are not really generic, they are specific to the IKEv2. This is not
generic authentication framework, this is generic payload format for
the IKEv2 secure password authentication methods.

The reason WG wanted this is that people want to have secure way to
use secure password authentication between boxes. Usually there will
NOT be any kind of backend in either end, and the connection will be
symmetric, i.e. either end can start it. Normal use case will be the
VPN connection between two offices. They do not want any
infrastructure, thus they do not want certificates, they do not want
EAP or AAA etc. Currently they are using normal shared-secret
authentication but in most cases their shared-secrets are not really
random, but some kind of human writtable words so they can be
transmitted over phone, thus they are vulnerable to the off-line
dictionary attacks now.

There are other use cases, but for example remote access scenarios
there are already EAP methods providing same features.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 14:42:16 +0300

> too I think he might share that concern.

Yes. I will most likely need to implement all of the protocols, and as
I am programmer, I am by defination lazy. And as I am lazy that means
I want to make my job as easy as possible. Currently all 4 methods use
different methods to negotiate which method is used, uses different
payload format, uses different exchange types, and uses different ways
for calculating the AUTH payloads.

There are some fundamental differences in the protocols, for example
the way they calculate the AUTH payloads, which we cannot solve with
common code, but the agreement which method to use, exchange types,
payload formats etc are something which share lots of stuff and I do
not want to write the same stuff 4 times, I want to write it once, so
I want to make them same... 

> (currently PACE uses a Notify and SPSK uses the mandatory bit) and

That was my step 1.

> send another blob, get another blob--

As far as I can read the drafts they already all do the that in the
same way. 

> and to mix results from PAKE exchange into results of the D-H
> exchange in a uniform manner

And this is something all of them most likely will do differently, so
I have no high hopes of having one way to do that, so most likely this
code needs to be written 4 times... 

> and we might get the equivalent of what he's proposing without Yet
> Another Pluggable Architecture (which I guess we both agree would be
> not-so-good).

And as I said I do not want to have generic pluggable architecture, I
want to have methods sharing as much common code as possible.

> implementing different exchanges.

Yes, altough I think it is easier if the common stuff is in separate
document, and all others refer to that, as it makes keeping different
versions in sync easier. It would be completely ok for me if all
drafts just incorporated the changes to their drafts, as it would make
my life even easier as then I do not need to write that draft
describing the common stuff (did I mention I am lazy :-), but making
sure they are aligned exactly may make things bit hard. Also
implementors could not be sure that all of them are really aligned,
because they do not refer to common text, meaning implementor need to
check all of the documents and make sure they are aligned before they
can implement them.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 14:47:16 +0300

Nico Williams writes:
> proposal then you'll be quickly approximating EAP re-invention.

If you want to use AAA, you use EAP.

We already have EAP in the IKEv2, there is no need for another method
which supports AAA than that. We also have mutual EAP authentication
as extension and we do have some of those same secure password
authentication methods proposed as EAP methods too.

> Which I-Ds are in last call??

http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/
http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/
http://datatracker.ietf.org/doc/draft-shin-augmented-pake/

and then there are one more which is not yet there:

http://datatracker.ietf.org/doc/draft-sheffer-ipsecme-hush/

and then we have the selection criteria document for background
information:

http://datatracker.ietf.org/doc/draft-harkins-ipsecme-pake-criteria/
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Apr 2011 14:56:32 +0300

> convinced to switch to another method if that's the group's preference. 

So you want exactly what my framework is. I.e. common way to negotiate
the use of methods. 

> and "super-notifications", or how they would simplify implementations.

As an implementors all of those methods seem to use mostly similar
payloads. Also I do not see any reason to use different exchange type
for differnet methods, as they do not really change the way the
IKE_AUTH exchange works.

The meta-payloads make IKEv2 library code easier, as it just needs to
implement parsing, encoding, debug printing etc only one payload. It
does not need to know anything of the internals of the payload data.
It will just give that to the method, which will then parse and
process it further. This means that when we first implement the first
mehod we need to write code to parse/generate those meta-payloads and
thats it. When we add another method later we do not need to touch
that part of code at all, we just add the method specific parsing in
the library doing that stuff.

The payloads coming out from the IKEv2 require all kind of generic
checking that can be shared between these similar payloads, but if
each of them is implemented as separate payload type, then it needs to
be duplicated.

The super-notification is simply just way to make sure the IKE_SA_INIT
packet stays small enough. We do not want to add too many notification
payloads there. On the other hand as we do make OEM toolkit, I do see
that we for example most likely will be implementing multiple of those
methods, which means that it is important for us that those methods
can easily co-exists in the same implementation. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 13 Apr 2011 15:40:44 +0300

Hi Tero,

To clarify (once again): I am NOT moving forward with HUSH. I think it's 
a nice contribution and I'm not aware of any major problems with it, but 
I'd rather concentrate on one PAKE method. I decided to go with PACE for 
the sole reason that it comes with a security proof.

Thanks,
	Yaron

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Apr 2011 11:59:05 -0500

> I might be wrong on that issue, as I do not know GSS-API that well.

I believe you are wrong about that.  Evidence: SCRAM (RFC5802).

If you look at SCRAM you'll see that it's exceedingly simple -- it's a
pre-shared password type mechanism, loosely resembling DIGEST-MD5.

All the GSS aspects of SCRAM are segregated into a small, clean
section.  You'd mostly not have to concern yourself with it because I
volunteer to write that for you :)

> convereted to GSS-API methods is going to require quite a lot of work,

Not at all (see above).  I volunteer to do the GSS bits so you don't have to.

The only change I need you to make for this is to agree to let the
mechanism's sub-messages carry the initiator and responder names.  I
can even give up on how you name the mechanisms (8-bits? fine, so
you'll have an IANA registry).

> and also binding GSS-API authentication to the IKEv2 authentication

For strong mechanisms you just key the IKE_SA from output of the
mechanism.  All we need is for the mechanism to output key material
and a PRF (which can be effectively the same as IKE's PRF, so nothing
new for you).

For weaker mechanisms (like SCRAM) we'd want to do a KE before running
the mechanism and channel binding to the KE.  This is quite simple to
do: just derive a nonce-like value from the KE output (i.e., use the
PRF) and then use that in the mechanism as an input on both sides --
it only needs to match on both sides.  You don't even have to think of
this as channel binding if you don't want to.

The reason I want this is so I can reuse your mechanisms outside IKE.
I'm particularly interested in using them in SSHv2 and Kerberos
pre-authentication.  If your mechanisms' specification is easily
reusable and we can make it cheap for them to be easily reusable, we
all win.  That's the bargain I'm offering you.  I do the work you
don't want to do and I make it so you don't even have to notice that
your mechanisms are actually GSS mechanisms.  :)  All I need is for
the mechanism messages to carry the initiator and responder names, for
strong mechanisms to output a PRF and seed, and for weak mechanisms to
do channel binding (which is trivial).

Deal?

Nico
--

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Apr 2011 13:06:23 +0300

> pre-shared password type mechanism, loosely resembling DIGEST-MD5.

I have not yet read the SCRAM, but based on the discussion on the
secdir list, I think you were missing some points of this discussion
in here too.

All of these 3 (hush is withdrawn as pointed out to me) methods we are
discussing here are ZKPP. IPsecME charter says:

----------------------------------------------------------------------
- IKEv2 supports mutual authentication with a shared secret, but this
mechanism is intended for "strong" shared secrets. User-chosen
passwords are typically of low entropy and subject to off-line
dictionary attacks when used with this mechanism. Thus, RFC 4306
recommends using EAP with public-key based authentication of the
responder instead. This approach would be typically used in enterprise
remote access VPN scenarios where the VPN gateway does not usually
even have the actual passwords for all users, but instead typically
communicates with a back-end RADIUS server.

However, user-configured shared secrets are still useful for many
other IPsec scenarios, such as authentication between two servers or
routers. These scenarios are usually symmetric: both peers know the
shared secret, no back-end authentication servers are involved, and
either peer can initiate an IKEv2 SA. While it would be possible to
use EAP in such situations (by having both peers implement both the
EAP peer and the EAP server roles of an EAP method intended for "weak"
shared secrets) with the mutual EAP-based authentication work item
(above), a simpler solution may be desirable in many situations.

The WG will develop a standards-track extension to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared
secrets. The goal is to avoid off-line dictionary attacks without
requiring the use of certificates or EAP. There are many
already-developed algorithms that can be used, and the WG would need
to pick one that both is believed to be secure and is believed to have
acceptable intellectual property features. The WG would also need to
develop the protocol to use the chosen algorithm in IKEv2 in a secure
fashion. It is noted up front that this work item poses a higher
chance of failing to be completed than other WG work items; this is
balanced by the very high expected value of the extension if it is
standardized and deployed.
----------------------------------------------------------------------

So the major points are:

- Machine to machine communication (i.e. no user)
- Weak password created by admins and entered to the configs
- Symmetric nature, i.e. either end can initiate communications, there
  is no server and client roles
- Needs to be secure against off-line dictionary attacks even against
  active attackers
- No certificate support required
- No AAA infrastructure required

> volunteer to write that for you :)

If I understood your comments in the secdir list correctly SCRAM does
not fill all of those requirements?
-- 
[email-masked]

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Apr 2011 14:09:26 -0500

>   exchange will similar to EAP, i.e.:

If the "SPAMs" are ZKPPs, they surely output key material, so why
bother with KEi/KEr here?  Is it for privacy protection of the ID
payloads below?

>                                <--  HDR, SK {[SPAM_PAYLOAD, ...],

Studying this more carefully, I think this is close to fully
generalizable -- in a way where I could borrow the spec to make GSS
mechs out of this instead of the other way around.  The only things
missing (channel binding, generic ID payloads, GSS flags conveyance)
could be added separately.  Also, I'd want to very cleanly separate
the "SPAM" negotiation from the "SPAM" messages.  (Did I mention that
SPAM is a trademark? :)

I'll think about this some more.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Apr 2011 16:20:52 +0300

> bother with KEi/KEr here?  Is it for privacy protection of the ID

You really need to ask that from the authors of the methods, I just
took all of the methods and created common structure over them. All of
them do normal IKEv2 IKE_SA_INIT before they start do anything else.

They all do normal IKEv2 Diffie-Hellman and create (unauthenticated)
encrypted channel between the nodes and then create AUTH paload using
the SignedOctets from the IKEv2 in addition to their own stuff to
authenticate that channel.

The good think is that they do it that way, as it means there is very
little actual changes to the IKEv2 because of that. If they would
create keying material needed to encrypt and mac the IKE_AUTH
payloads, then those changes would be much bigger to the generic IKEv2
code than what now seems to be needed. 

> could be added separately.

You have to remember that we do NOT want to change the standard IKEv2
parts of the protocol, i.e. SAi1, KEi, Ni, SAr1, KEr, Nr, IDi, IDr,
SAi2, TSi, or TSr payloads in any way.

We just want to make sure the methods can transmit their stuff with as
little coding as possible. Also all of the methods use different way
how to calculate the AUTH payload. 

> Also, I'd want to very cleanly separate

I know, and most likely will put something else in the draft if we
ever get that far...

I should have realized that any solution proposal to the spam problem
is like opening can of worms, so I should have used some other term
:-)

-- 
[email-masked]