[RRG] Identifiers & Security Associations

[Randall Atkinson <rja@extremenetworks.com>]

Earlier, Brian Carpenter wrote:
% Don't forget that the address is today also an essential part of
% the data for a cryptographic protection of an end to end session.

Only because we did not (and still don't) have good non-topological
identifiers.  I knew this was a problem for IPsec Security Associations
way back in the early 90s (15+ years ago).  IPsec SAs bind to
IP addresses *only* because the Internet Architecture lacked a
sufficiently rich set of namespaces.

I'll note that web sites are usually thoughtful enough to issue
their X.509v3 certificates bound to fully-qualified domain names,
instead of to specific IP addresses, so that *any* IP address
for that FQDN will work with the one certificate.  (Arguably
this implies a stronger need for DNSsec, but that is out of
scope for this list.)

% In that role it could of course be replaced by some ID inserted
% at a level above IP (as it is in IPSEC over UDP, in effect), but we
% have to provide that at the same time as architecturally removing
% e2e addressing. And if you do that *except* by inserting an alternative
% 32 or 128 bit e2e quantity that looks just like an IP address, you
% create unthinkable amounts of disturbance to upper layer running code.

That claim is NOT obvious to me.

Fixing IPsec SAs to use some new non-topological ID would affect
the ESP/AH code inside the kernel, which could be updated automatically.
It also would affect the IKE code, which also could be updated
automatically.

However, most applications use the IPsec extensions to Sockets API
that NRL initially developed (a sub-optimal API admittedly, but that is
still what most IPsec-aware applications use) -- and that API would
NOT be affected in any way obvious to me.  So I do NOT think that
application software would be affected by the change.

With respect to SSL/TLS, see the other comments above.  So I don't
think existing web applications would need to change either.

Perhaps you were thinking of some security approach other than
IPsec or SSL/TLS ??

Cheers,

Ran
rja@extremenetworks.com




--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg