[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Does IPsec undermine PKI?
BACKGROUND
I am a DOD contractor who is very interested in the potential that IPsec
may have for supporting privacy of patient information in the DOD
military medical information environment. Since the DOD medical
community must interface with commercial healthcare providers, the use
of IPsec VPNs (initially in a gateway-to-gateway configuration between
commercial sites and military sites) is appealing.
I have recently read the ARCH, AH, ESP, and ISAKMP drafts and I am still
digesting the concepts. I have recently started following the mailing
list.
The questions I have below, come from an IPsec end-user perspective,
rather than from an implementation perspective, so I hope that this
message is appropriate to the mailing list, and appreciate any
responses.
ISSUE
The DOD is currently in the process of standing up a PKI. Some DOD
applications are being planned to use the PKI for using X.509
certificates for authentication and encryption purposes. One DOD group
is planning a particular application which requires user authentication
and data encryption. Two paragraphs, presented below, are excerpts of a
point paper providing recommendations for implementation of this
particular application.
The paragraphs make some statements that don't seem to be quite accurate
to me. I was wondering if someone could comment on these statements and
on my questions that follow.
EXCERPTS FROM THE POINT PAPER
2.2 IPSec can create a Virtual Private Network (VPN) between any
interoperable routers or firewalls on an internet. This process takes
place in the end location routers and is transparent to the intermediate
routers in the internet. Authentication of the sites taking part in the
session is inherent in that they share a secret key. Manually keyed
IPSec has been implemented in industry in both routers and firewalls.
The DMC is currently testing this capability using [brand-name] routers.
Encryption is supported in hardware in the larger routers and in
software in the smaller routers. IPSec uses IETF Requests for Comments
(RFCs) as standards. Automatic symmetric key exchange protocols for
IPSec will be standardized later this year to support the encryption
process. However, with the limited number of current users the manual
method is acceptable and manageable. The [brand-name firewall] at the
[central site] is also capable of manual key IPSec encryption. The
[other brand name firewall] also supports manual IPSec and will be
adding the automatic key exchange this year. We can expect a number of
vendor firewalls and routers to come out with standard automatic key
exchange IPSec capabilities in 1998. Interoperability is a key issue in
that the solution must be vendor neutral and therefore be standards
based and tested for interoperability. The interoperability issue is
always difficult and costly to test.
2.2.1 The IPSec methods used to establish sessions between end points
differ from those that are used in PKI. PKI operates at the application
level and IPSec operates at the IP level. The automatic key exchange
algorithms use different hash algorithms (MD5 in IPSec and Secure Hash
Algorithm in PKI) to sign the certificates containing the public and
private keys. This would become an issue if a large number of sites had
to access the [application] server and manual keys became unmanageable.
There are industry certificate issuers that would fulfill this role for
IPSec. Use of IPSec would have the effect of under minding the PKI
initiative.
MY QUESTIONS AND COMMENTS
1. I don't have much problem with para 2.2, above.
2. In generic terms, does a PKI really provide the capability to
establish sessions between end points?
3. Isn't IKE (ISAKMP) the IPsec component that is responsible for
establishing sessions between end points, and doesn't IKE operate at the
application layer?...I just read para 2.5.1 in the ISAKMP draft, it
states that ISAKMP can be implemented over any transport protocol or
over IP itself...and MUST include send and receive capability for ISAKMP
using UDP on port 500. So, it looks to me like it could be an
application layer service? What's the correct answer?
4. I know that AH and ESP operate at Layer 3. The ISAKMP Draft
(drafts-ipsec-isakmp-09.txt) shows a picture in section 2.2 of the draft
as to the placement of ISAKMP in a network architecture, however the
text does not really seem to point out what layer it operates in.
5. Para 2.2.1 above eludes that IPsec supports only MD5 in automatic
key exchange algorithms. My understanding is that IPsec compliant
implementations must support MD5, SHA-1 and Null authentication
algorithms and for encryption DES and Null encryption. So I would
assume that the automatic key exchange algorithms would support
attributes for these as well.
6. The statement, above, about IPsec "undermining the [DOD] PKI
initiative" seems to stem from the author's implied belief that PKI also
provides the underlying security algorithms responsible performing the
authentication and encryption. My question is simply how do IPsec and
PKI coexist and what is the demarcation of functionality between the
two?
7. My observation is that a public key infrastructure is a "utility"
that serves certificates. This utility is independently linked to the
functions of IPsec. In fact, isn't PKI a utility that is independently
linked to any security-based application? I would restate the above
statement as, "The choice of PKI implementation may have the effect of
undermining a security initiative because there is relatively little
standardization among various PKI implemenations." It seems the
challenge is to the vendor community to make industry standards work.
Therefore it is my hopes that vendors implementing IPsec will make their
products at least compatible to mainstream PKI implementations...there
is nothing in the IPsec specifications that is stopping them from doing
so...is there?
Thanks.
David W. Perry
SRA International
TriService Infrastructure Management Program Office
Follow-Ups: