[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Final editing changes to IKEv2
How about this: The client will send the AUTH payload as soon as it
can, this can be before or after the EAP-success message, depending on
protocol and implementation.
The server will cache the AUTH payload as soon as it is received. It
will only verify the client's AUTH and send the {AUTH, SAr2, TSi, TSr}
when both conditions are met: (1) The EAP success has been received
from the EAP state machine, and (2) The AUTH payload has been received
from the peer.
If we go against draft-ietf-rfc2284bis-09 and use OTP or GTC to
transfer cleartext passwords (which is OK because the channel is
encrypted) there is no key and the client can send the AUTH payload in
message #5, and the whole exchange can be done by message #6. If some
method generates a key, but the EAP state machine cannot figure it out
before getting the success message, then there is no choice, and we
need an extra roundtrip after the success message.
Does this sound reasonable?
On 19/03/2004, at 18:59, Tschofenig Hannes wrote:
> hi jari,
>
> in the past people have worried a lot about the number of roundtrips.
> so far
> there was no protocol example where the keys have to be exported before
> receiving the eap-success message. ikev2, however, seems to be one.
>
> to be more specific the following two variants are on the table (if we
> use
> eap-aka as an eap method within ikev2):
>
> Variant I:
>
> AUTH payload sent by the initiator before receiving the EAP success
> message.
>
>
> Initiator Responder
> ----------- -----------
> HDR, SAi1, KEi, Ni -->
>
> <-- HDR, SAr1, KEr, Nr, [CERTREQ]
>
> HDR, SK {IDi, [CERTREQ,] [IDr,]
> SAi2, TSi, TSr} -->
>
> <-- HDR, SK {IDr, [CERT,] AUTH,
> EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)
> }
>
> HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC), AUTH}
> -->
>
> <-- HDR, SK {EAP-Success, AUTH,
> SAr2, TSi, TSr }
>
>
> Variant II:
>
> AUTH payload sent by the initiator after receiving the EAP success
> message.
> consequence: one additional roundtrip
>
> Initiator Responder
> ----------- -----------
> HDR, SAi1, KEi, Ni -->
>
> <-- HDR, SAr1, KEr, Nr, [CERTREQ]
>
> HDR, SK {IDi, [CERTREQ,] [IDr,]
> SAi2, TSi, TSr} -->
>
> <-- HDR, SK {IDr, [CERT,] AUTH,
> EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC)
> }
>
> HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)} -->
>
> <-- HDR, SK {EAP-Success, AUTH}
>
> HDR, SK { AUTH } -->
>
> <-- HDR, SK { SAr2, TSi, TSr }
>
>
> you mention that 'Changing the protocol document is not a good idea'.
> which
> protocol document do you mean?
> a) draft-ietf-rfc2284bis-09.txt or
> b) draft-ietf-ipsec-ikev2-12.txt
>
> are there modifications required to either (a) or (b)? i don't think
> so.
>
> is there something in the text of (a) which addresses our issue here?
> (b) is vague about when the auth payload has to be sent. hence it
> would only
> be a clarification.
>
> hence, this issue seems to be more applicable to the state machine.
> pasi or
> some other state machine authors might want to comment on this issue.
>
> i agree with yoav that responders should be prepared to handle both
> cases.
> if the eap client is integrated into the ikev2 implementation then the
> additional roundtrip can be avoided. your concern about the two
> different
> eap client implementations might not be an issue in most cases
> (particularly
> if i think about the non-standardized api which caused me some
> troubles -
> but that's another story).
>
> ciao
> hannes
>
>
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
>> Sent: Friday, March 19, 2004 3:29 PM
>> To: Yoav Nir; Pasi Eronen
>> Cc: ipsec@lists.tislabs.com
>> Subject: Re: Final editing changes to IKEv2
>>
>>
>>
>> (EAP WG co-chair hat on)
>>
>> I think it would be good if we could avoid having two
>> different EAP clients depending on whether EAP is used
>> in IKEv2 or for, say, 802.11 authentication.
>>
>> The behaviour of EAP is defined in
>> draft-ietf-rfc2284bis-09.txt (recently approved by
>> IESG) and draft-ietf-eap-statemachine-02.pdf (completed
>> WG last call). As Pasi states, the client state machine
>> currently exports keys only after having received the
>> success packet.
>>
>> Pasi, I think in this case this behaviour is only what
>> the state machine says, not something that is required
>> in the protocol document that IESG approved. Or?
>>
>> Changing the protocol document is not a good idea, but
>> is there a way to change the state machine so that it
>> would provide the client side key sooner? Would this be
>> possible without impacts to either the protocol definition
>> or the interface towards methods or 802.11 state machines
>> and protocols (which we spent a lot of time to get right)?
>>
>> If yes, maybe we should consider what Yoav says below.
>> If no, I think the right thing is to add the roundtrip
>> and not create differently behaving EAP implementations
>> depending on for what purpose they are...
>>
>> --Jari
>>
>> Yoav Nir wrote:
>>> How about this:
>>>
>>> The responder (gateway) sends the AUTH and the child-sa
>> response in a
>>> response message following the initiator (client) AUTH payload.
>>>
>>> If the client has the EAP machine integrated, this is
>> before receiving
>>> the EAP success. If it isn't then we may need an extra
>> round trip. If
>>> the client can't tell that the EAP neg has ended until she gets the
>>> EAP-success (imagine a protocol where the server sends
>> several personal
>>> questions), then the extra round-trip in necessary.
>>>
>>> I think in the general case the extra round trip will not
>> be necessary,
>>> but gateways will be required to support both cases.
>>>
>>> Is this OK?
>>>
>>> Yoav
>>>
>>>>
>>>> Hi,
>>>>
>>>> Having the responder send the AUTH payload and EAP-Success
>>>> in the same message is OK. However, this does not solve the
>>>> initiator's case. "As soon as it can" is still a bit ambigous,
>>>> and in draft -12 the initiator sends the AUTH payload _before_
>>>> receiving EAP-Success. But EAP peer state machine currently
>>>> "exports" the key only _after_ receiving EAP-Success.
>>>>
>>>> So it seems that we need to either slightly change how EAP works
>>>> or add another roundtrip. Both options are certainly feasible,
>>>> but IMHO the latter requires less work...
>>
>>
>>
>