[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Secure legacy authentication for IKEv2

I see a number of problems with the SLA proposal posted as an I-D,
and have a counterproposal.

The SLA proposal says that message 1 is unmodified and Message 2 contains
the responder's AUTH payload, moved from message 4. There are a number
of problems with this. Message 3 contains the list of roots trusted by
the initiator as well as the desired responder identity (the Me Tarzan,
You Jane variation). The responder uses those values to decide what
identity to respond with. We would either have to disallow that flexibility
when SLA was used or move those values to message 1. If we move them
to message 1, we lose the protection from passive eavesdroppers.

Further, a responder must know whether it is going to use legacy
authentication or regular authentication after receiving message 1, which
has few clues and therefore a responder could not accept either type.
This could be fixed by putting a capability indicator in message 1.

In this protocol, the initiator decides what form of legacy authentication
it wants to do and the responder can accept or reject that choice. This
is the reverse of what happens with EAP, where the responder decides
what form of authentication it expects sometimes based on the claimed
user identity. This means that if some users of a particular piece of
software use challenge/response tokens and some use username/password,
it would be up to the user to communicate to the client software what
sort of capability he has rather than waiting for the responder to prompt
for something.

All of these problems can be worked around (but we would have to decide
how before we would have a spec), and the limitations may be
acceptable, but I believe they are unnecessary. I believe a smaller
modification to the protocol avoids these problems.

The changes I would propose (derived closely from Stephane Beaulieu's proposal)
are to leave the first two messages alone, replace AUTH and CERT in message
3 with an EAP exchange in messages 4 & 5 (and if more needed, 6 & 7, etc),
and deferring the completion of the child SA establishment from message 4
to the last message. Or more precisely:

No change to message 1.
No change to message 2.
Message 3: AUTH and CERT payloads are removed - perhaps an optional
indication of legacy auth methods supported.
Message 4: SAr2, TSi, TSr removed; EAP payload added
Message 5: EAP payload
Message 6: SAr2, TSi, TSr

(where extra pairs of messages can be inserted between 5 and 6 if more
than one EAP round trip is required).

If a legacy auth method that produces a shared key is used, the next
to last message should have an AUTH payload generated using that key.
The purpose is to protect against man-in-the-middle attacks. Defense
is only possible of the legacy auth method generates keying material,
and using that key for creating an AUTH payload is simpler than other
proposals that mix that keying material into the keys for the SAs.

Note that a (perhaps controversial) aspect of this proposal is that
the initiator identity remains in message 2. This has the advantages
that it minimizes changes to the protocol and may avoid a round trip
in the EAP protocol because the responder doesn't have to separately
prompt for username. It has the disadvantage that it presumes that
with all legacy authentication methods there is some expression of
the user's identity that can be prompted for in a uniform way. I
can't think of any case where that wouldn't be true.

What do people think?


Typical protocol run for the legacy auth case where we're just
prompting for a username and password would be:

       HDR, SAi1, KEi, Ni   -->
                            <--    HDR, SAr1, KEr, Nr
       HDR*, IDi, [IDr,]
            SAi2, TSi, TSr} -->
                            <--    HDR*, IDr, [CERT,] AUTH, EAP(pwd)
       HDR*, EAP(pwd)       -->
                            <--    HDR*, SAr2, TSi, TSr}