[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPSEC Minutes 33rd IETF in Stockholm - July 1995




CURRENT MEETING REPORT
Minutes of the IP Security Working Group (IPSEC)
Reported by  Antonio Fernandez (afa@bellcore.com)
         and Mark Schertler    (mjs@tycho.nsa.gov)


The IP Security (IPSEC) Working Group met on Wednesday July 19th from
9:00-12:00 during the 33rd IETF. Paul Lambert chaired the meeting,
which was broadcast on the mbone. The meeting covered the status of the
IP ESP and AH documents, a presentation and discussion about the
Internet Key Management Protocol (IKMP) and a presentation of DNS
Security Extensions (DNSSEC) to provide long term keys on the
Internet.

Martin Patterson announced a SKIP BOF. Several implementations of SKIP
have been developed and alignment of SKIP with ESP and AH is being
discussed. The main purpose of the BOF is to get the people
implementing versions of SKIP together.


IPSEC Document Status

The following IPSEC Specifications have been advanced to Proposed
Standard:

1. Security Architecture for the Internet Protocol
    <draft-ietf-ipsec-arch-02.txt>
2. IP Authentication Header <draft-ietf-ipsec-auth-02.txt>
3. IP Encapsulating Security Payload (ESP) <draft-ietf-ipsec-esp-01.txt>
4. IP Authentication using Keyed MD5 <draft-ietf-ipsec-ah-md5-03.txt>
5. The ESP DES-CBC Transform <draft-ietf-ipsec-esp-des-cbc-04.txt>

The IP Authentication using Keyed MD5 specification before it is
forwarded to the RFC editor will be edited to reflect Hugo Krawczyk's
comments concerning having the prepended key padded with a one (1) and
some number of zeros (0) to a length of 512 bits.

Jeff Schiller, Security Area Director, will provide the official
response to the comments received during the last call period.

Several implementations of ESP and AH are being developed and an
implementor's mailing list has been started. Contact Perry Metzger
(perry@imsi.com) if you are an implementor and would like to be on the
mailing list.


Internet Key Management Protocol (IKMP)

Currently IPSEC is considering two Internet Key Management Protocol
(IKMP) Proposals:

1. Photuris <draft-ipsec-photuris-02.txt>
2. Internet Security Association Key Management Protocol (ISAKMP) <draft-nsa-isa

Paul Lambert reviewed the IKMP goals and requirements. The IKMP
mechanism must support the selection of security transforms and
creation of session keys for ESP and AH. Algorithm, mechanism, and key
exchange independence to provide migration for the future is also a
requirement. IKMP should be general enough to be used by protocols
developed in other WGs.


Photuris

The Photuris editors, Phil Karn and Bill Simpson, were unable to attend
the IETF meeting. In their absense an open discussion of Photuris was
held. Issues raised concerning the Photuris specification included the
need to clarify the relationship between the security association
definitions in Photuris and in the Security Architecture for IP
specification. Another clarification required is how the SIGN exchange
should be encrypted.  The question of how Photuris would be used by a
router acting on behalf of an end system was also raised.


Internet Security Association and Key Management Protocol (ISAKMP)

Mark Schertler, NSA Information Systems Security Organization (ISSO),
presented the Internet Security Association and Key Management Protocol
(ISAKMP).

ISAKMP is a flexible key management architecture that provides a common
mechanism for security attribute negotiation, strong authentication,
and session key establishment. ISAKMP is key exchange, authentication
mechanism, and cryptographic algorithm independent. ISAKMP by providing
a common security association (SA) establishment mechanism can be used
by other protocols developed by the IETF that require SAs. This
architecture follows the Security Architecture for IP, ESP and AH
specifications lead. As was done in the IP Authentication using Keyed
MD5 ESP DES-CBC specifications, a base KMP transform including a
session key generation algorithm, authentication mechanism, and
encryption algorithm must be specified. The Photuris session key
generation algorithm is good candidate for the base KMP transform. This
a possible way to utilize both proposals - ISAKMP as the Internet Key
Management Protocol and Photuris as the base IKMP transform.


The features of ISAKMP included:
1. a fixed field header that contains no security attributes making
header parsing consistent and migration to new security attributes
easier,
2. replay prevention using a time variant cookie
3. initialization exchange to indicate base KMP transform or select
other KMP transforms to protect SA and session key establishment
4. strong authentication mechanism required
5. support for multiple certificate authorities
6. transport protocol independence

Following it's header, ISAKMP seperates security information into
discrete payloads based on the security information's function.  The
key exchange payload has a Key Exchange Identifier (KEI) which
indicates the key exchange algorithm used. KEIs must be specify in a
separate RFC and/or registered with IANA. The RFC would define the
keying information and payload format to be exchange with the
protocol.

The authentication payload identifies the Certificate Authority that
issued the certificate. This is also an IANA issued identifier.  The
Authentication Type field indicates the type of authentication data
(e.g. Certificate format). Finally the payload contains the
authentication data that is used to authenticate the peer entity.

The Security Association (SA) payload contains the security attributes
being offered (request) or accepted (response) for the security
association.  Security attributes can be bundled together into a set
(e.g. encryption - DES, hash - MD5, signature - RSA, etc.) or each
attribute can be followed by a list of the acceptable options (e.g.
encryption - DES, IDEA, 3DES). Either format has a field which
indicates which security service the security attributes support (e.g.
ESP, AH, or OSPF authentication). The SA payload supports the SA
parameters defined in the Security Architecture for IP and allows for
migration to SA parameters defined for future security services and
mechanisms.

ISAKMP defines protocol exchanges to establish Security Associations
(SAs) and create session keys, modify SAs, delete SAs and transmit
notifications (error messages and front-end syncronization).

A concern was raised that the ISAKMP proposal has too much flexibility,
too many combinations will make it impossible to understand all the
security implications. Therefore, only a minimum of flexibility is
required. Responses from the floor stated that we can not have only one
solution (key exchange algorithm). Another statement was that we must
choose one key exchange everyone implements for interoperability, but
we must allow an open migration path and not tie ourself down to a
specific algorithm. The ISAKMP editors stated that ISAKMP is a protocol
that supports many key management architectures, the Photuris key
exchange is an example of a key exchange that fits into the ISAKMP
protocol and can be defined as the must implement for Internet
interoperability.

Development of an ISAKMP prototype has begun and the developers are
open to all suggestions. Initially the prototype will negotiate and
place two types of security associations. The first an Internet SA
utilize either RSA with PGP certificates or RSA with RSA certificates
for it authentication mechanism, the Diffie-Van Oorschot-Wiener STS
(Photuris) for session key creation, DES-CBC for encryption, and MD5
for hashing. The second SA utilize algorithms form the Fortezza Card
which are DSA with Fortezza certificates for authentication, Key
Exchange Algorithm (KEA) for session key creation, Skipjack for
encryption and Secure Hash Algorithm (SHA) for hashing. The developers
welcome anyone would like to develop additional security associations
to contact them.

The prototype is on SunOS 4.1.3, using gcc 2.6.x and running on UDP for
the transport protocol. The schedule is to complete the prototype by
November 17 and post the source code on the NSA Web Site
(http://www.nsa.gov:8080/). The developer's future plans are to
prototype an Internet security solution using ISAKMP, ESP, and AH. A
model of ISAKMP has been developed using the Foresight modeling tool.
This model will be used to perform vulnerability testing prior to
prototype completion.


DMS Security Extensions (DNSSEC)

Donald Eastlake presented work being done on DNS Security Extentions
(DNSSEC) and its relationship to IPSEC work. IKMP will create session
(short term) keys, but there is also a requirement for long term keys.
There are several sources for long term keys, and one is the DNSSEC.
DNSSEC includes provisions for associating long term keys with users
and hosts and also explicit provisions for indicating the protocols
associated with the long term keys. The public (long term) keys can be
signed (e.g. certifed) and stored in the DNS. Thus the long term keys
are available on line. DNSSEC supports a variety of key types requests.
DNS is widely deployed in the Internet and having the entities being
named linked to the domain names is a natural in the global Internet.

Public alpha code will be made available soon (in the next days) by
Trusted Information Systems (TIS).

The Internet-Draft which incorporates implementation experience thus
far is available at:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-04.txt


Future Work Items

Paul Lambert concluded the meeting by presenting a list of possible
future work items, that the IP Security Working Group should consider.

Additional Work Items and Issues:

1. Management of security (ESP, AH, ...)
2. Access control
3. Additional Security Transforms
4. Additional Security Exchanges
5. Multicast Key Management
6. 3rd part security (router like)
7. Naming
8. Cryptographic issues
9. MD5 security issues
10. true anonymity
11. application issues