Re: On revised identity (was "Moving forward...final edits...)

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Feb 06, 2003 at 08:03:43PM -0800, Michael Choung Shieh wrote:
> 
> 2. FOR type 3 (hash and URL), is it dangerous that the gateway will try to
> do http with innocent party with instruction of unauthenticated peer?

Well, the server can have an access list of what web servers it will
allow itself to contact on the instruction of an unauthenticated peer,
but it does add additional complexity to the implementation and the
configuration load of the IPSEC product.  In addition, if vendors
leave the default ACL such that any arbitrary URL will be visited by
the server, yes, that could lead to some very entertaining
opportunities from the point of view of potential attackers.

However, it's actually worse than that from the client's perspective.
In some cases, the client will not have access to the internet
beforehand.  For example, the VPN solution in use by my company,
AT&T's Managed Tunnel Service, has two modes.  In one mode, an
existing Internet connection is used to connect to the MTS server, and
the client does have the capability to make arbitrary HTTP requests
before the VPN connection is made.  In the other mode, the client is
calling (over the POTS network) a modem bank, and is not permitted,
for obvious reasons, to have general internet access before completing
the initial setup with the VPN.

So in this case, it cannot possibly work from the perspective of the
client, since in this case the client doesn't have even an IP address
(because DHCP or the Configuration payload negotation hasn't happened
yet).  In the case of AT&T Managed Tunnel Services, the VPN gateway
could chose to use different ID types based on how the initial
connection was made, but that would add complexity to its
architecture/implementation --- and so I wonder if an implementor
might simply chose not to use hash/URL at all, and just simply send
the entire certificate chain each time.

(In other cases, some company's security organizations have
regulations that say that a laptop is may not make -- and must be
configured to not allow --- arbitrary connections over internet while
it is connected to the VPN.  Whether or not the I/T security folks
would be happy with the Road Warrior's laptop making unsecured
connections to the Internet *just* *before* connecting through the VPN
is a different questions.  I suspect some might get heartburn over
this issue, customers will probably demand that whether or not
hash/URL scheme can be allowed at all must be a site configurable
option.)


Basically, a hash/URL scheme can be made to work (and could be added
to either the existing ikev1/ikev2-04 framework, or in the revised
identity draft. ).  It is essentially a trade-off between complexity
(in terms of needing an http client engine in an ipsec implementation
plus some specialized rules about when it is and isn't OK to use it,
and what URL's are OK to contact) and the benefit of decreasing the
size of the IKE messages.

Comments about whether this particular engineering trade-off is worth
it is welcome.

						- Ted