Subject: Re: [Ipsec] each side uses different authentication method?

From: Yoav Nir <[email-masked]>
Date: Wed, 01 Mar 2006 09:49:49 +0200

It means that one side (call it A) presents a certificate and signs with
the private key, while the other side (call it B) does not present a
certificate and signs with the shared secret.

At the ICSA bake-off we called this "hybrid mode".

IMO it does not make sense at all. To get this done, you need to have
all of the following:
1. B has no certificate, but trusts the CA.
2. There is a shared secret that is so good, that A trusts that anyone
who has it, must be B.

If condition #2 holds, why do they need PKI? They can use the shared
secret. If it doesn't, how can A know that B is indeed B?

>From a pure security POV, this only makes sense if A trusts that only B
(and A) know the shared secret, but B does not. B needs to see a
certificate to believe that A is really A. I just don't think this is a
real-world scenario.

So why did they put this in? I think it has more to do with psychology
than security. There is a general feeling among vendors that PKI is very
hard to implement, because of difficulty in distributing and storing the
certificates, especially to clients. So the client should authenticate
with a shared secret (or EAP). This is not a recommended practice since
it's open to dictionary attacks, but people still do it.

The user remembers the shared secret, so in their mind, it will never be
compromised on their end. The gateway, on the other hand, may have
backups, or other gateways centrally managed and having the same shared
secret. Having the gateway authenticate with a certificate gives users
that warm and fuzzy feeling that this is indeed the gateway.
Psychologically, people think of the shared secret as belonging to the
user, so it's not a good way to authenticate the gateway.

杜春燕(DU Chun-yan) wrote:
> Hi,
>
> In section 2.15 of RFC4306，"There is no requirment that the initiator and responder sign with the same cryptographic algorithms.""In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate."
> How could it be possible?  Does it mean that each side firstly uses the share secret key and then uses signature method, namely doing authentication twice to complete IKE_AUTH exchange?
> Thanks for help.   
>
> 	
>
>
> 　　　　　　　　DU Chun-yan
> 　　　　　　　　[email-masked]
> 　　　　　　　　　　2006-02-28
>   

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Mar 2006 16:15:03 +0200

> 1. B has no certificate, but trusts the CA.

Like company installed laptop. 

> 2. There is a shared secret that is so good, that A trusts that anyone

Like group shared key...., note that A only trusts that B is part of
group having that key. 

> secret. If it doesn't, how can A know that B is indeed B?

Because everybody in the group B knows the shared key they can fake to
be each other at will. If only shared key authentication would be used
then anybody in the group B could also act as man in the middle
between the another one in the group B and the real server A.

If the members of group B uses certificates to authenticate the server
A, this rules out the man in the middle attack, i.e. B can be sure
that the communication is protected from the others in the group B
too. The server A still cannot say who of the group B is really
connecting, but in some environments that does not really matter, as
long as the one connecting is part of group B.

For example that kind of setup could be used to protect the connection
between the laptop and the DHCP-server. By verifying the certificate
of the DHCP-server the laptop really knows that the server is real
DHCP server. By verifying the shared key of B the DHCP-server knows
that this is approved machine, to whom he can give IP-address from the
normal pool. This requires very little of enrollment as the laptops
only needs to have the CA-certificate and the shared key, but they do
not need to enroll their own private key and get certificate for it. 

This kind of asymmetric authentication isn't that much useful in the
shared secret - certificates case, but it is needed in the EAP -
certificates case. Also adding special case that would forbid using
different authnetication methods in other cases would simply added
more code, it was easier to simply allow it in all cases. 
-- 
[email-masked]