[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Final editing changes to IKEv2
Hannes,
(I do worry about number of roundtrips.)
When I said that changing the protocol document would be
a bad idea, I was referring to draft-ietf-rfc2284bis-09.txt
which has already been approved by IESG; changes to draft-
ietf-eap-statemachine-02.pdf or draft-ietf-ipsec-ikev2-12.txt
would, however, still be possible, as long as they don't
break something else. And I do think making EAP behave the
same way in different contexts is valuable.
About the solution: I'm ready to go either way on this issue,
and of course if its possible we should use the smaller number
of roundtrips. But at this point I'd wait for Pasi, who is one of
the authors of the state machine document, to comment on whether
he thinks the change would have impacts elsewhere, e.g., 802.11
interface. Pasi?
I will also post a note of this discussion to the EAP WG mailing
list in case other folks wish to comment.
--Jari
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...
>>
>>
>>
>