[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of IPSEC Key Management
In reviewing the messages that note the failure to converge on a
key management protocol, I was motivated to send this message about some
recent experiences that may be relevent to the discussion.
Most of my key management experience over the last 18 years has
been with protocols designed to establish a traffic key for a security
association that would, in turn, last for some time. The duration often
might be a day, for an association protecting traffic in bulk between to
systems (or between two sites using perimeter-based security) , or it might
be on the order of a few minutes, corresponding to the duration of a TCP
connection. Under these circusmatnces, a multiple-message exchange
required to establish an SA and corresponding key were not a burden, becaue
the cost of these messages was amortized over a fair number of subscriber
traffic packets.
Times have changed, and the range of uses for which we require
traffic keys has broadened. For example, in work we have been doing with
regard to mobile IP security, there is a desire to have a per-transaction
key, but there is no opportunity to perform ANY messages exchanges to put
this key in place. Moreover, the frequency of the transactions might be as
high as once per second, according to the mobile IP specs, which rules out
most public key computations. Under these constraints, a basic SKIP-like
key generation approach is appropriate, since it requires no
per-transaction exchanges and the precomputation feature of SKIP allows the
per-transaction key generation time to be minimal. Thus we have chosen to
use the SKIP technique (though not the SKIP syntax) for key management in
this context.
In another project we have been dealing with secure communication
between routers, and among other routing infrastructure components. We
have found instances in this program where minimal message exchange key
establishment protocols, and fast (minimal computation) public key
exchanges are appropriate. here too, SKIP-like functionality is
attractive, though not strictly required.
Finally, as the use of multicast increases in the Internet, one of
the features that was originally advertised for SKIP, support for
multi-sender, multicast based on stream ciphers, may become important. I
don't know if SKIP is essential for this, but I've yet to see good
solutions for this application and it would be nice to keep our options
open here.
Most of the applications and communication patterns we deal with
today are well served by the sorts of key management protocols some of us
have dealt with for a number of years, and which ISAKMP represents quite
well. However, I do see some applications where SKIP-like key management
is attractive, and some contexts for which this form of key management
seems uniquely well suited. Thus I would hate to see us lose this facility
in a final, single standard for key management. IPSEC may not require this
form of key management, or may not require it for most applications that we
see today, but it's a tool that would be nice to have available in our
arsenal. Moreover, it's availability might allow us to use IPSEC in some
circumstances that otherwise would require us to develop other security
and.or key management protocols.
So, in summary, I'd like to suggest that we try to adopt a key
management solution that preserves as many options as possible, in
recognition of the constantly evolving nature of the Internet and the
applications that drive its evolution.
Steve
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@TIS.COM
Subject: Re: Status of IPSEC Key Management
In-Reply-To: Your message of "Fri, 06 Sep 1996 22:59:35 CDT."
<v02130500ae569a3e904e@[128.89.30.29]>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Sat, 07 Sep 1996 11:30:43 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609090724.aa08819@neptune.TIS.COM>
Stephen Kent writes:
> Moreover, the frequency of the transactions might be as
> high as once per second, according to the mobile IP specs, which rules out
> most public key computations. Under these constraints, a basic SKIP-like
> key generation approach is appropriate, since it requires no
> per-transaction exchanges and the precomputation feature of SKIP allows the
> per-transaction key generation time to be minimal.
Steve;
In a large internet, key lookup will be required, the result of which
will be that SKIP will have no advantage whatsoever in terms of number
of message exchanges compared with other techniques.
Perry
From: Ran Atkinson <rja@cisco.com>
Date: Sat, 7 Sep 1996 19:20:56 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipsec@TIS.COM
Subject: Steve Kent's note
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609090726.aa08842@neptune.TIS.COM>
I really appreciate Steve Kent's recent note. Its among the most
thoughtful and precisely written notes on this list recently.
I would urge folks to carefully read his note and consider its points.
Ran
rja@cisco.com
speaking only for myself
--
Date: Sun, 8 Sep 1996 07:51:23 -0700 (PDT)
From: Aviel Rubin <rubin@usenix.org>
Message-Id: <199609081451.HAA03572@usenix.ORG>
To: rubin@bellcore.com
Subject: ANNOUNCEMENT AND CALL FOR PAPERS - 1998 USENIX Security Conference
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
*************************************************************************
ANNOUNCEMENT AND CALL FOR PAPERS
7th USENIX Security Symposium
January 26-29, 1998
Marriott Hotel-- San Antonio, Texas
Sponsored by the USENIX Association, the UNIX and Advanced Computing
Systems Professional and Technical Association
In cooperation with: The CERT Coordination Center.
Important Dates for Refereed Papers
Papers due: September 9, 1997
Author notification: October 8, 1997
Camera-ready final papers due: December 9, 1997
Registration Materials Available: End October, 1997
(Authors, see "How to Submit a Refereed Paper" below.)
Program Chair
Avi Rubin, Bellcore
Program Committee
Carlisle Adams, Nortel
Dave Balenson, Trusted Information Systems
Steve Bellovin, AT&T Research
Dan Boneh, Princeton University
Diane Coe, Mitre
Ed Felten, Princeton University
Li Gong, JavaSoft
Peter Honeyman, CITI, University of Michigan
Hugo Krawczyk, IBM Watson Labs
Jack Lacy, AT&T Research
Hilarie Orman, DARPA/ITO
Mike Reiter, AT&T Research
David Wagner, University of California, Berkeley
Readers
Katherine T. Fithen, CERT
Trent Jaeger, IBM Watson Labs
Invited talks coordinator: Greg Rose, Qualcomm
Conference home page: <http://www.usenix.org/sec/sec98.html>
OVERVIEW
The goal of this symposium is to bring together researchers,
practitioners, system programmers, and others interested in the
latest advances in security and applications of cryptography.
This will be a four day symposium with two days of tutorials,
followed by two days of refereed paper presentations, invited talks,
works-in-progress presentations, and panel discussions.
TUTORIALS Monday and Tuesday, January 26-27
Tutorials for both technical staff and managers will provide
immediately useful, practical information on topics such as local and
network security precautions, what cryptography can and cannot do,
security mechanisms and policies, firewalls and monitoring systems.
If you are interested in proposing a tutorial, contact the tutorial
coordinator, Dan Klein: phone (412)421-2332 email <dvk@usenix.org>.
TECHNICAL SESSIONS
Wednesday and Thursday, January 28-29
In addition to the keynote presentation, the technical program includes
refereed papers, invited talks, a work in progress session, and panel
sessions. There will be Birds-of-a-Feather sessions the last two
evenings. You are invited to make suggestions to the program committee
via email to <security@usenix.org>.
Papers that have been formally reviewed and accepted will be presented
during the symposium and published in the symposium proceedings,
published by USENIX and provided free to technical session attendees.
Additional copies will be available for purchase from USENIX.
SYMPOSIUM TOPICS
Refereed paper submissions are being solicited in areas including but
not limited to:
* Adaptive security and system management
* Analysis of malicious code
* Applications of cryptographic techniques
* Attacks against networks/machines
* Computer misuse and anomaly detection
* Copyright protection (technical solutions)
* Cryptographic & other security tools
* File and file system security
* Network security
* New firewall technologies
* Security in heterogeneous environments
* Security incident investigation and response
* Security of Mobile Code
* User/system authentication
* World Wide Web security
Note that this symposium is not about new codes, ciphers, nor
cryptanalysis for its own sake.
Papers must represent novel scientific contributions in computer
security with direct relevance to the engineering of secure systems
for the commercial sector.
HOW TO SUBMIT A REFEREED PAPER
(Please read carefully.)
The guidelines for submission are a bit different from previous
years. Authors must submit a mature paper in postscript format.
Any incomplete sections (there shouldn't be many) should be
outlined in enough detail to make it clear that they could be
finished easily. Full papers are encouraged, and should be about
8 to 15 typeset pages. Submissions must be received by
September 9, 1997.
Along with your paper, please submit a separate email message
containing the title, all authors, and their complete contact
information (phone, fax, postal address, email), including an
indication of which author is the contact author.
Authors will be notified of acceptance on October 8, 1997.
All submissions will be judged on originality, relevance, and
correctness. Each accepted submission may be assigned a member
of the program committee to act as its shepherd through the
preparation of the final paper. The assigned member will act
as a conduit for feedback from the committee to the authors.
Camera-ready final papers are due on December 9, 1997.
If you would like to receive detailed guidelines for submission
and examples of extended abstracts, you may send email to:
<securityauthors@usenix.org>
or telephone the USENIX Association office at (510) 528-8649.
The Security Symposium, like most conferences and journals,
requires that papers not be submitted simultaneously to another
conference or publication and that submitted papers not be
previously or subsequently published elsewhere. Papers
accompanied by non-disclosure agreement forms are not
acceptable and will be returned to the author(s) unread.
All submissions are held in the highest confidentiality prior
to publication in the Proceedings, both as a matter of policy
and in accord with the U.S. Copyright Act of 1976.
There will be one or two prizes awarded for best paper(s).
WHERE TO SUBMIT
For reliability, please send one copy of your paper to the program
committee via each of two of the following methods. All submissions
will be acknowledged.
o Preferred Method: email (Postscript) to:
<securitypapers@usenix.org>
o Alternate Method: postal delivery to
Security Symposium
USENIX
2560 Ninth St., Ste. #215
Berkeley CA 94710
U.S.A.
Phone: (510) 528-8649
o Fax: (510) 548-5738
Vendor Exhibits
Demonstrate your security product to our technically astute attendees
responsible for security at their sites. We invite you to take part
in the Vendor Display. The informal, table-top display allows you to
meet with attendees informally and demonstrate in detail your security
solutions.
Contact CynthiaDeno
Email: cynthia@usenix.org
Phone: 408.335.9445
Fax 408.335.5327
Works-in-Progress Session (WIPs)
The last session of the symposium will be a Works-in-Progress session
consisting of five minute presentations. Speakers should provide a one
or two paragraph abstract to the program chair by 6:00 pm on January
28, 1998 at the conference. These should be provided in person, not via
email. The chair will post the schedule of presentations by noon on the
29th. Experience at other conferences has shown that usually, all of
them are accepted. The five minute time limit will be strictly enforced.
INVITED TALKS
There will be several invited talks at the conference in parallel with
the refereed papers. If you have suggestions for possible speakers,
please send them to <security@usenix.org>.
REGISTRATION MATERIALS
Materials containing all details of the technical and tutorial
programs, registration fees and forms, and hotel information will be
available at the end of October 1997. To receive the registration
materials, please contact:
USENIX Conference Office
22672 Lambert Street, Suite 613
Lake Forest, CA USA 92630
Phone: (714) 588-8649
Fax: (714) 588-9706
Email: <conference@usenix.org>
Information can also be found under the Conference home page:
<http://www.usenix.org/sec/sec98.html>.
Date: Mon, 09 Sep 1996 07:07:40 -0400
To: Stephen Kent <kent@bbn.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Status of IPSEC Key Management
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609090731.aa08969@neptune.TIS.COM>
Interesting. Different strokes for different folks.
At 10:59 PM 9/6/96 -0500, Stephen Kent wrote:
>
> Times have changed, and the range of uses for which we require
>traffic keys has broadened. For example, in work we have been doing with
>regard to mobile IP security, there is a desire to have a per-transaction
>key, but there is no opportunity to perform ANY messages exchanges to put
>this key in place. Moreover, the frequency of the transactions might be as
>high as once per second, according to the mobile IP specs, which rules out
>most public key computations. Under these constraints, a basic SKIP-like
>key generation approach is appropriate, since it requires no
>per-transaction exchanges and the precomputation feature of SKIP allows the
>per-transaction key generation time to be minimal. Thus we have chosen to
>use the SKIP technique (though not the SKIP syntax) for key management in
>this context.
We have a similar application, maybe not quite the frequency, and for
various reasons we are working with application level security; most likely
S/MIME enveloping each transaction data set.
> In another project we have been dealing with secure communication
>between routers, and among other routing infrastructure components. We
>have found instances in this program where minimal message exchange key
>establishment protocols, and fast (minimal computation) public key
>exchanges are appropriate. here too, SKIP-like functionality is
>attractive, though not strictly required.
I have always been intreged with the idea of a SKIP-like functionality for
SNMPv2. Of course in our earlier discussions, SNMP usage is typified as an
intra-enterprise problem.
> Finally, as the use of multicast increases in the Internet, one of
>the features that was originally advertised for SKIP, support for
>multi-sender, multicast based on stream ciphers, may become important. I
>don't know if SKIP is essential for this, but I've yet to see good
>solutions for this application and it would be nice to keep our options
>open here.
What about the GKMP draft, how does that look? I am bothered by the
apparant one master key for a multicast group for the SKIP approach. How
is it shared? How is someone dis-associated at the proper time? How do
you re-key if sync lost?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212