David Mariblanca (ML/EEM | 1 Apr 11:33 2004
Picon

RE: clarification on IKEv2 with EAP


Hi again,
I would like to raise other questions:
- When generating the AUTH, one input is the "Key Pad for IKEv2", which is supposed to be used in password
based authentications, correct ? What happens when the user authentication is not based in passwords ? In
that case, can this string be omitted as input to the prf, or can be assigned a fixed value instead ?
- If the EAP method being used already provides a message authentication mechanism, does the AUTH have to be
computed anyway ? Or only in the cases where the EAP message is not protected by itself, the AUTH has to be
used ?

Thanks for your time, but I foresee I may come back again with more questions...
Cheers,
David.

-----Original Message-----
From: Tschofenig Hannes [mailto:hannes.tschofenig <at> siemens.com]
Sent: miƩrcoles, 31 de marzo de 2004 14:07
To: David Mariblanca (ML/EEM); 'ipsec <at> lists.tislabs.com'
Subject: RE: clarification on IKEv2 with EAP

hi david, 

the AUTH payload in message 4 (from the responder to the initiator) is not
based on the keying material of an eap method authentication and key
exchange run. hence, it most likely uses public key based authentication. 

ciao
hannes

> -----Original Message-----
(Continue reading)

Pasi.Eronen | 1 Apr 13:08 2004
Picon

RE: clarification on IKEv2 with EAP


Hi,

The "Key Pad for IKEv2" part is always included, even 
if the shared secret is not actually a password entered 
by the user.

AUTH payloads are also always included (the EAP message
authentication protects only EAP messages; the AUTH 
part is needed to authenticate the IKEv2 exchange).

Best regards,
Pasi

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com
> [mailto:owner-ipsec <at> lists.tislabs.com]On Behalf Of ext David 
> Mariblanca
> (ML/EEM)
> Sent: Thursday, April 01, 2004 12:34 PM
> To: 'Tschofenig Hannes'; 'ipsec <at> lists.tislabs.com'
> Subject: RE: clarification on IKEv2 with EAP
> 
> 
> 
> 
> Hi again,
> I would like to raise other questions:
> - When generating the AUTH, one input is the "Key Pad for 
> IKEv2", which is supposed to be used in password based 
(Continue reading)

Pasi.Eronen | 1 Apr 13:18 2004
Picon

RE: clarification on IKEv2 with EAP


David Mariblanca wrote:

> I will give my interpretation of  chapter 16 and please confirm 
> if it is correct.
> - The EAP payloads are sent in the IKEv2 messages without 
> AUTH payloads. The AUTH payloads are sent only in the last 
> two IKEv2 messages, and they correspond to the last two EAP 
> messages, that is, AUTH in message 7 to EAP payload in 
> message 5, and AUTH in message 8 to EAP payload in message 6

No, AUTH payloads do not authenticate the EAP messages, they
authenticate the IKEv2 SA (basically information from the 
first two IKEv2 messages; first paragraph of Section 2.15 
explains exactly what is included in the "<message octets>").

(All EAP messages are also MAC'd with SK_ar/SK_ai, but this is 
not related to AUTH payloads; the integrity protection is 
included in the "SK{...}" notation).

Best regards,
Pasi

David Mariblanca (ML/EEM | 1 Apr 12:29 2004
Picon

RE: clarification on IKEv2 with EAP


Hi, and thanks for the quick reply.
Yes, I was talking about the AUTH payloads generated after the EAP exchange.
I hadn't realize there was already a version 13, I was still using version 12. Anyway, the new one does not
make things completely clear to me yet. I will give my interpretation of chapter 16 and please confirm if it
is correct.
- The EAP payloads are sent in the IKEv2 messages without AUTH payloads. The AUTH payloads are sent only in
the last two IKEv2 messages, and they correspond to the last two EAP messages, that is, AUTH in message 7 to
EAP payload in message 5, and AUTH in message 8 to EAP payload in message 6
- Since the AUTH payloads correspond to the two last messages and they are only sent in the two last IKEv2
messages, if the EAP messages exchanged are more than showed in the diagram, the rest of the EAP messages
before the last two ones are not authenticated with AUTH payloads, even in the EAP method had obtained
previously the key material needed to generate the AUTH (and hence it could be possible to protect
previous EAP messages).

Is this correct ?

BR,
David.

-----Original Message-----
From: Tschofenig Hannes [mailto:hannes.tschofenig <at> siemens.com]
Sent: jueves, 01 de abril de 2004 12:07
To: David Mariblanca (ML/EEM); 'ipsec <at> lists.tislabs.com'
Subject: RE: clarification on IKEv2 with EAP

hi david,

> Hi again,
> I would like to raise other questions:
(Continue reading)

David Mariblanca (ML/EEM | 1 Apr 14:38 2004
Picon

RE: clarification on IKEv2 with EAP


Ok, I see. I did not remember the EAP messages were already integrity protected and encrypted with Sk_a and
Sk_e. Then the AUTH payloads protect the IKE_INIT messages, the ones which were not sent protected since
there was not key material yet to do it, correct ?

-----Original Message-----
From: Pasi.Eronen <at> nokia.com [mailto:Pasi.Eronen <at> nokia.com]
Sent: jueves, 01 de abril de 2004 13:19
To: David Mariblanca (ML/EEM); ipsec <at> lists.tislabs.com
Subject: RE: clarification on IKEv2 with EAP

David Mariblanca wrote:

> I will give my interpretation of  chapter 16 and please confirm 
> if it is correct.
> - The EAP payloads are sent in the IKEv2 messages without 
> AUTH payloads. The AUTH payloads are sent only in the last 
> two IKEv2 messages, and they correspond to the last two EAP 
> messages, that is, AUTH in message 7 to EAP payload in 
> message 5, and AUTH in message 8 to EAP payload in message 6

No, AUTH payloads do not authenticate the EAP messages, they
authenticate the IKEv2 SA (basically information from the 
first two IKEv2 messages; first paragraph of Section 2.15 
explains exactly what is included in the "<message octets>").

(All EAP messages are also MAC'd with SK_ar/SK_ai, but this is 
not related to AUTH payloads; the integrity protection is 
included in the "SK{...}" notation).

(Continue reading)

Tero Kivinen | 1 Apr 15:36 2004
Picon
Picon

Re: 2nd try

Stephen Kent writes:
> We would like to have at least one, mandatory way for two IPsec peers 
> to carry fragments via SAs, when port-specific SAs are employed, 
> hence we need at least one approach that is a MUST. The third 
> recommendation would satisfy the requirement, but the reassembly 
> process may be a hardship for very high speed implementations. That's 

I think we should select the most secure protocol (i.e. case #3) as
MUST, and allow #2 protocol for high-speed implementations as MAY.

This way we would always have one MUST to implement version which
allows secure transport of fragments over port selector SAs, and the
requirements would be same for the IPv4 and IPv6.

> why I suggested this option as a MAY. The reason for making the 
> second recommendation the MUST, for IPv4, is because it satisfies the 
> requirement, and does not seem likely to impose performance 
> penalties. It is only a MAY/SHOULD for IPv6 because there are 
> security problems for v6 when dealing with fragments w/o reassembly, 
> as noted in the analysis.

So for IPv6 there is no MUST to implement protocol at all?

> >If  the implementation takes the conservative approach of keeping it 
> >simple and secure
> >(Vs performance), isn't MUST a bit too strong ?
> 
> Reassembly or reassmebly-like state tracking is not simple, although 

It is not that complicated either. Full reassembly code in the netbsd
(Continue reading)

Paul Koning | 1 Apr 16:58 2004

Re: 2nd try

>>>>> "Tero" == Tero Kivinen <kivinen <at> iki.fi> writes:

 >> Reassembly or reassmebly-like state tracking is not simple,
 >> although

 Tero> It is not that complicated either. Full reassembly code in the
 Tero> netbsd kernel is about 200 lines (not counting code for general
 Tero> queue macros etc), our partial and full reassembly code is
 Tero> about 1000 lines (it does quite a lot more than only partial
 Tero> reassembly).

Reassembly isn't all that hard in software, although it gets more
complicated if you really care about performance when there are a
large number of simultaneous streams.  But reassembly in hardware is
quite another matter.

While I'm no great fan of option #2, I feel that requiring it is a
better choice than requiring reassembly (option #3).

       paul

Bora Akyol | 1 Apr 17:28 2004
Picon

RE: 2nd try


Hi Steve,

This looks good, one question about the fragment SA(s):

If we have several "parallel" SAs to support different levels
of QoS (for the main SAs), do we need to have the same amount
of fragment SAs as the main ones? 

Thanks

Bora

> Conclusions
> 
> There is no simple, uniform way to handle fragments in all contexts. 
> Different approaches work better in different contexts.  Thus I 
> suggest we require support for two approaches, and offer a third, and 
> allow a user or administrator to choose from among these based on 
> topology constraints and security requirements. Hence the following 
> proposed text:
> 
> 1. All implementations MUST support tunnel mode SAs that pass traffic 
> without regard to port field values. If the SA will carry traffic for 
> specified protocols, the two selector sets MUST be used to specify 
> the port fields for the SA: ANY and OPAQUE. An SA defined in this 
> fashion will carry all traffic for the indicated source/destination 
> addresses and specified protocol(s). If the SA will carry traffic 
> without regard to a specific protocol value (i.e., ANY is specified), 
> then the port field values MUST be set to ANY as well.
(Continue reading)

William Dixon | 1 Apr 18:07 2004

RE: IDci and IDcr payloads with NAT Traversal

Tero, I agree with your proposed change as long as the peers detect they are
behind NAT. But as you may both know, this is a general interop issue with
IKEv1 regardless of NATs because so many options are allowed as ID types,
the ID payload being an optional payload anyway, and we don't have en
efficient, standardized way to determine what ID type an initiator must use
with a given responder. The reality then is that the vendor's decision about
their policy system controls what IDs they can reasonably accept and thus
who interops with who, with hacks based on vendor ID recognition and some
internal decisions to handle the rest.

I would hope IKEv2 provides clarity to improve the situation. I don't think
it's reasonable that vendors have to build policy systems such that all ID
types are supported in policy, and must be configured to ensure interop. I'm
not sure if there is a way to get a policy system that initiates using FQDN
names to interop safely with one that responds only with IPv4_ADDR. If
everyone supports everything, sure all this can be manually configured...
Certainly it's impractical for my own client as initiator to be manually
configured differently to talk to any destination I may go to in the
Internet. So we should probably also specify how to handle policy transition
from address-dependent policy to names.

Cheers,
Wm

> -----Original Message-----
> From: owner-ipsec <at> lists.tislabs.com 
> [mailto:owner-ipsec <at> lists.tislabs.com] On Behalf Of Tero Kivinen
> Sent: Tuesday, March 30, 2004 3:55 AM
> To: David Wierbowski
> Cc: ipsec <at> lists.tislabs.com
(Continue reading)

David Mariblanca (ML/EEM | 1 Apr 18:12 2004
Picon

RE: clarification on IKEv2 with EAP


Hi,
well, I am not specially worried about that, but rather to implement extra protections when it's not
needed. The EAP methods I am now thinking about are EAP SIM and EAP AKA, which already provide some
protection mechanisms. If IKEv2, on top of that, gives integrity and encryption to the EAP messages,
maybe we will spend unnecessary resources when using EAP SIM/AKA over IKEv2, if we consider that either
IKEv2 or EAP SIM/AKA levels of protection are secure enough.
But I guess other EAP methods do not provide the same level of protection and that's why IKEv2 has to be
designed in order to not depend on EAP implementations.

In the other hand, after reading your paper (the one you are writing with Pasi) I see very reasonable your
proposal to omit AUTH in message 4: if IKEv2 says that in messages 7 and 8 the AUTH payloads will protect
messages 1 and 2 (respectively), why to send AUTH in message 4 ? Does message 2 need to be authenticated
twice ?

Cheers,
David.

-----Original Message-----
From: Tschofenig Hannes [mailto:hannes.tschofenig <at> siemens.com]
Sent: jueves, 01 de abril de 2004 17:31
To: David Mariblanca (ML/EEM); 'Pasi.Eronen <at> nokia.com';
ipsec <at> lists.tislabs.com
Subject: RE: clarification on IKEv2 with EAP

hi david, 

i am only curious: 
why do you worry about the protection of eap messages? 

(Continue reading)


Gmane