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 protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
