Subject: [Ipsec] EAP_ONLY_AUTHENTICATION; is it still valid?

From: Satoshi Inoue <[email-masked]>
Date: Tue, 23 Aug 2005 15:10:44 +0900

Hi all,

While I was trying to figure out how to do EAP w/o CERT, I found
description on EAP_ONLY_AUTHENTICATION notification payload in
draft-eronen-ipsec-ikev2-eap-auth-03.txt. Is this notify (or I-D I
may say) still a valid type in terms of IKEv2 standard track?

Relating to this topic, I'm a bit confused with the sequence below;
IKEv2 w/ EAP sequence (just copied from IKEv2-17).

    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 }

    HDR, SK {EAP}              -->

                               <--    HDR, SK {EAP (success)}

    HDR, SK {AUTH}             -->

                               <--    HDR, SK {AUTH, SAr2, TSi, TSr }

If CERT is not used with EAP, how do we derive the AUTH payload in
message 4?

Thanks,
Satoshi Inoue

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 24 Aug 2005 12:00:03 +0200

hi satoshi, 

> Hi Hannes,
> 
> Thanks for your response.
> 
> On Tue, 23 Aug 2005 10:33:33 +0200
> "Tschofenig, Hannes" <[email-masked]> wrote:
> 
> > what do you mean by valid? 
> 
> I wanted to know whether it's gonna be a proposed standard or not.

we, the authors, would like to see this work moving forward. we have
also received positive feedback about this work for this work. 

> Or at least, whether it's well confirmed/clarified by the list.

since the ipsec working group does not exist anymore it will not be a
working group item. 

> The
> value for this notify type is not assigned yet, that's another
> worry for me.
sure. that would happen as part of the iana registration. 

> 
> > with ikev2 the responder uses pk-based authentication to 
> the initiator.
> > if the cert payload is not included in message 4 then the 
> initiator is
> > assumed to know the certificate (based on the identity of the
> > responder). 
> 
> Okay. Let me focus on EAP w/o using certificates. If
> EAP_ONLY_AUTHENTICATION is considered as a proposed standard (or
> well confirmed/clarified), shouldn't the message 4 of AUTH payload
> be optional in IKEv2-17 too?
it does not need to be. if the responder supports this extension then
the corresponding functionality will be triggered. 

> 
> Another thing, isn't it possible to include this notify payload in
> IKEv2-17, or at least, in clarification document?

ikev2: no. 
clarifications document: i don't think that this was the idea of the
clarifications document.

> I do not want to
> see too many separated RFC/I-Ds for IKEv2, like it was in IKEv1.
i see. 

> 
> > with draft-eronen-ipsec-ikev2-eap-auth-03.txt the auth payload of
> > message 4 is delayed to a later message (see section 3 of
> > draft-eronen-ipsec-ikev2-eap-auth-03.txt). 
> 
> AUTH payload of message 4 is omitted, not delayed.

well, the auth payload sent by the responder to the initiator is sent in
a later message exchange after the eap authentication was completed. 

> AUTH payload of
> message 7 and 8 is derived from EAP generated key, right?
yes, see the following paragraph in section 3:  

"
   Both the initiator and responder MUST verify that the EAP method
   actually used provided mutual authentication and established a shared
   secret key.  The AUTH payloads sent after EAP Success MUST use the
   EAP-generated key, and MUST NOT use SK_pi or SK_pr.
"

ciao
hannes