Subject: [Ipsec] Questions about draft-eronen-ipsec-ikev2-multiple-auth-00

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Oct 2005 11:01:04 +0200

Hi.

I have several questions about this draft.

1. Having multiple authentication exchanges means you have several AUTH 
payloads. Are all of them signing or hashing the same string 
(message||nonce||ID)?

2. Suppose you use multiple EAP methods that do not generate keys. Are 
all the AUTH payloads signed with SK_pi and SK_pr?  If the answer to 
both questions is yes, then the AUTH payload will be identical between 
exchanges.

3. If we're going to allow multiple authentication exchanges, why not 
also allow them to be separated by time (without the 
"ANOTHER_AUTH_FOLLOWS" notification) and then we will be able to do 
repeated authentication without tearing down all existing tunnels?

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Oct 2005 17:04:30 +0300

> payloads. Are all of them signing or hashing the same string 

I would guess so, as the draft does not say anything about that. 

> both questions is yes, then the AUTH payload will be identical between 

Yes. Perhaps there should be something to differentiate them?

> repeated authentication without tearing down all existing tunnels?

If I understood correctly what you asked, that would require
completely new exchange to be defined.

Actually I am not sure if even this draft should be using the normal
exchange type, or whether it should have different exchange type
number also.

Anyways I also think that whole N(MULTIPLE_AUTH_SUPPORTED) notifies
are compeltely useless, and should be removed. There is no need for
them as all the new things happen in the notification payloads. There
is no need to negotiate this feature. 

It would be completely different matter if the other end could somehow
tell what authentication methods it wants the other end to use, but as
it cannot with this protocol, then there is no need to negotiate
support for this.

So only thing that is needed is the N(ANOTHER_AUTH_FOLLOWS). If the
other end does not support it, then it will simply finish the exchange
without waiting for another auth, and as those ANOTHER_AUTH_FOLLOWS
only gives extra authentications to the other end it does not really
matter.

I.e even if the client things that multiple authentications are
needed, but if the server is happy after the first one, there is no
reason for the client to tear the IKE SA down because of that.

I am still not sure if this whole support is needed, those two AAA
servers still needs to have some kind of trust relation ship, i.e. the
NAPT AAA / NAP's Tunnel Endpoint needs to trust that 3rd Party AAA and
3rd Party Tunnel Endpoint do the second authentication correctly, and
that they give valid values for to be used in the trafficl selectors
etc (if I understood the scenario correctly). The 3rd party could
simply also send the information needed for billing to the NAP too.

This just again adds quite a lot of complexity to the protocol and
HUGE amount of different options that needs to be tested. Currently
you need to test 6 different authentication methods (psk-psk,
cert-cert, psk-cert, cert-psk, eap-psk, epa-cert), and after this you
need to test lot of different combinations to make sure everything
works.
-- 
[email-masked]