Subject: [Ipsec] Identities types IP address, FQDN/user FQDN and DN and its usage in pershared key authentication

From: Surya Batchu <[email-masked]>
Date: Wed, 26 Jan 2005 22:35:29 -0800 (PST)

Hi
 
In pre-shared key authentication mode (no RSA/DSA certificates), what are the advantages of one identity type over another? What are the appropriate deployment scenarios for these different identity types?
 
Surya

---------------------------------
Do you Yahoo!?
 Yahoo! Search presents - Jib Jab's 'Second Term'

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

---

From: Surya Batchu <[email-masked]>
Date: Thu, 27 Jan 2005 09:56:06 -0800 (PST)

If ID type 'ID_IPV4_ADDR' is used, it is necessary for receiving implementation to cross check source IP address of IKE message with the value in received ID payload?  If there is a mismatch, some implementations seem to be rejecting the IKE negotiation. Why is this necessary? Does it provide any additional security? In my opinion,  it is good enough if ID payload value matches with locally configured 'acceptable remote ID values'.  Please give your comments.
 
Surya

Surya Batchu <[email-masked]> wrote:
Hi

Surya

---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 28 Jan 2005 10:32:31 -0800

In pre-shared key authentication mode (no RSA/DSA certificates), what are
the advantages of one identity type over another? What are the appropriate
deployment scenarios for these different identity types?

SRINI> All of them are equal from security perspective. Only requirement is
that the ID should be unique in a VPN. ID field identifies the IPsec device
or client and it should remain same across multiple IPsec sessions.
Typically, identity type IP-ADDR is used, if the device/client has static
public IP address. Other identity types can be used in any scenario. 

Srini

---

From: "Nicolas Jacottin" <[email-masked]>
Date: Fri, 28 Jan 2005 14:12:35 -0500

Dear Srni,

The main advantage of using FQDN for pre-shared key auth. against IP address
is scalability. I mean if you have to deploy 10 users-to-site or
site-to-site connections it's not a concern as soon as you don't have PAT in
between. Therefore, it's interesting to implement preshared key auth. based
on FQDN when:

+ you have a large number of IPSec tunnels (machine or user). You can use a
RADIUS server that will take care of the authentication and the storage of
Users/machine account  based on the name and domain. It's offer also the
possibility to implement accounting if you use L2TP over IPSec for providing
dynamically an IP address to the end tunnel.  Note that IKEv2 is , I think,
able to provide a standardized way also to implement the dynamic
provisioning of an IP address to the tunnel end-point.

+ when a end-point of a tunnel is hidden by PAT, it's become harder to
become aware of the right IP address and even more difficult if the device
obtains an IP address via DHCP. Note that when there is NAT in between NAT-T
takes good care of your IPSec connection.

So the use of IP address for the authentication is useful if you don't have
a large number of tunnel because it's the simplest way to implement it. It's
really depends of the topology and what are you willing to achieve. If you
need further information let me know.

Nicolas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Srinivasa Rao Addepalli
Sent: vendredi 28 janvier 2005 13:33
To: 'Surya Batchu'; [email-masked]
Subject: RE: [Ipsec] Identities types IP address,FQDN/user FQDN and DN
and its usage in pershared key authentication

Srini

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Jan 2005 15:07:30 +0200

> takes good care of your IPSec connection.

There is no requirement for the ID_IPV4_ADDR or ID_IPV6_ADDR to match
any of the addresses of the host (not before, after or inside NAT,
host or anything). As long as the IP-addresses are unique among your
clients you can use whatever you like. You can even start allocating
for the first client ID_IPV4_ADDR of 0.0.0.0, and then next with
0.0.0.1, and so on. When the SGW will see thet ID_IPV4_ADDR it will
use it to fetch the policy and authentication data and use those to
verify policy and to authenticate the other end.

For example it is completely valid from the IKEv2 point of view to
create each client a certificate with the IP-address from the INTERNAL
network used inside the office (probably from 10.0.0.0/8 net), and
assign each client one of those IP-addresses in the DHCP/Radius
server.

Then when client connects outside making the VPN tunnel from laptop to
the SGW, it can use the same ID_IPV4_ADDR identity and the certificate
to authenticate itself, and the SGW can after verifying the
certificate start doing proxy-arp or similar so that laptop can act
just like it would be in the internal office network.

For some reason some people consider this bad, but it is completely
valid and allowed by the IKEv2. I agree that the first case where
using ID_IPV4_ADDR can be much better handled with ID_KEY_ID, and in
some cases it is much better to use ID_FQDN or IP_RFC822_ADDR, but
there is no requirement in IKEv2 which says any of the ID payloads
needs to match any data in the insecure outer IP-header (actually
doing any of those checks can break NAT-T). 
-- 
[email-masked]