[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF security report
>From [email protected] Fri Sep 1 19:09:55 1995
Received: from TIS.COM (neptune.tis.com [192.94.214.96]) by postman.osf.org (8.6.9/8.6.x) with SMTP
id TAA08164 for <[email protected]>; Fri, 1 Sep 1995 19:09:54 -0400
Received: from neptune.tis.com by neptune.TIS.COM id aa06599; 1 Sep 95 16:20 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa06595; 1 Sep 95 16:18 EDT
Received: from big-screw.mit.edu(18.72.0.176) by relay.tis.com via smap (g3.0.1)
id xma004617; Fri, 1 Sep 95 16:07:54 -0400
Received: by big-screw
id AA23873; Fri, 1 Sep 95 16:18:03 -0400
Date: Fri, 1 Sep 95 16:18:03 -0400
Message-Id: <9509012018.AA23873@big-screw>
>From: "Jeffrey I. Schiller" <[email protected]>
Sender: [email protected]
To: [email protected]
Subject: IETF Security Area Report (July 17-21, 1995: 33rd IETF meeting)
Cc: [email protected], [email protected]
Status: R
-----BEGIN PGP SIGNED MESSAGE-----
IETF Security Area Report
Jeff Schiller and Jim Galvin
[email protected]
[email protected]
July 17-21, 1995
The Security Area within the IETF is responsible for development of
security oriented protocols, security review of RFCs, development of
candidate policies, and review of operational security on the Internet.
The Area Director is assisted by a Directorate, an advisory entity with
no standards-setting powers. The members of the Security Directorate
are as follows.
Jeffrey I. Schiller <[email protected]>
Ran Atkinson <[email protected]>
Steve Bellovin <[email protected]>
Steve Crocker <[email protected]>
Barbara Fraser <[email protected]>
James M. Galvin <[email protected]>
Phil Karn <[email protected]>
Steve Kent <[email protected]>
John Linn <[email protected]>
Clifford Neuman <[email protected]>
Rob Shirey <[email protected]>
Ted Ts'o <[email protected]>
In addition to the Directorate the Security Area is assisted by the
Security Area Advisory Group (SAAG). The SAAG is an open group that
meets at least once during each IETF meeting as well as electronically
via the [email protected] mailing list. Send a message to the address
[email protected] to join the list.
During the Security Area Advisory Group (SAAG) meeting, the activities
of the Security Area, including the Directorate, are reported and
discussed. In addition, the SAAG meeting provides an opportunity for
open discussion of security issues.
Included below is a summary from those working groups and birds of a
feather sessions with security relevant activities to report and the
Security Directorate meeting summary. In addition, the following topics
were discussed during the SAAG meeting.
o Documents Approved as Proposed Standards
The IESG approved the advancement of five of the IPSEC documents to
proposed standards. With the advancement of these documents the IPSEC
working group will focus on issues related to key management.
The IESG approved the advancement of the two MOSS documents to
proposed standards. With the advancement of these documents the PEM
working group has completed its charter and will be closed.
o Domain Name System Security
The last revision of the enhancements for the DNS to support security
has been released. It will enter working group last call very soon;
no issues are expected to be raised. At the end of the working group
last call the document will be submitted to the IESG to be considered
for publication as a Proposed Standard. An implementation of the
specification is available to U.S. and Canadian sites and individuals
via anonymous FTP (see ftp://ftp.tis.com/pub/DNSSEC/README for
details).
o Key Management
It was noted that the Internet needs two kinds of key management: one
for short-term keys and one for long-term keys. The expected usage of
short-term keys would be on a per connection or per message basis.
Long-term keys, on the other hand, would probably be used to exchanged
short-term keys.
The distribution and management of long-term keys requires the
existence of a global infrastructure. There are two options for the
global infrastructure today: Secure DNS or The Directory (X.500). It
is also possible that something completely different will be needed
and developed.
Key management is expected to get increasing attention in the IETF.
o Internet Security Architecture
Steve Crocker gave an abbreviated version of his presentation to the
IAB the previous evening. He posed a challenge to the community to
improve the network security at IETF meetings. The specific proposal
is to have IPSEC available with manual keying, which would be enough
to make a difference when compared to the current configuration. This
should be available for use in the IETF terminal room by both the
terminals/workstations and laptops. In addition, we should install a
demonstration firewall that is IPSEC friendly. The goal is to make it
available at the next IETF meeting in Dallas (December 4-8, 1995).
The activity of the following working groups and birds of a feather
sessions was reported.
o Secure Socket Layer (SSL) BOF
A consensus developed for the need for a session layer security
protocol. This was predicated on observing that IPSEC is below the
transport layer and the session layer is above it, and that
implementing security in the transport or network layer would require
changes to operating systems. In contrast, session layer security
could be implemented and added non-invasively to existing systems,
thus making security services available to a broad range of
application protocols.
As a result, a working group called Session Layer Security will be
proposed. The Secure Socket Layer specification will serve as the
starting point for the new working group.
o Internet Secure Payments Protocol (ISPP) BOF
This BOF met two times with more than a dozen technology
presentations. Fortunately, the various technologies are much more
similar than they are different.
The consensus was that the IETF should have one or more working groups
in this area. Charters will be proposed and submitted to the area
director for consideration.
o Simple Key Management for IP (SKIP) BOF
SKIP is Sun's proposal for key management on the Internet. It is a
competitor to the Photouris specification being discussed in IPSEC.
It is still undecided as to whether this specification should be
discussed as part of the IPSEC working group or within its own working
group.
Although there appeared to be consensus to move the SKIP specification
onto the standards track, the authors will need to discuss the process
and relationship to IPSEC with the area director and the Chairs of the
IPSEC working group before this can be done.
[Note: Since the IETF meeting took place discussions between the
various parties are proceeding. The likely outcome will be for the
SKIP work to take place within the IPSEC working group.]
o Authenticated Firewall Traversal (AFT)
There are currently four implementations underway with
interoperability testing expected to begin shortly. If the testing is
successful three documents will be submitted to the IESG to be
considered for publication as Proposed Standards before the next IETF
meeting in Dallas.
o Common Authentication Technology (CAT)
The CAT working group discussed topics related to active documents,
including GSS-V2 (to receive another set of specific revisions at the
Internet-Draft level, and then to be recommended for advancement to
Proposed Standards), IDUP (where revised interface specifications and
a new mechanism specification were discussed, with standards
advancement to be considered at the Dallas IETF), GSS-API Negotiation
(new draft discussed), Kerberos mechanism and extensions (status and
comments discussed, new drafts to follow), FTP Security (to be
recommended for advancement to Proposed Standard after inclusion of
clarifying revisions), and a presentation of a new mechanism based on
FIPS PUB JJJ cryptography. Presentations on work in progress included
GSS-API integration into World-Wide Web browsers and servers, loadable
GSS-API multi-mechanism support, and discussion of the use of RFC-1731
as a generic framework for integration of security tokens into
text-based applications. The group also discussed a range of
candidate follow-on topic areas related to authorization, and
identified a subset with apparent common value and feasibility for
proposals and work by group members.
o Web Transaction Security (WTS)
There were three short presentations on related subjects and a review
of the two documents being developed by the working group. With
respect to the requirements specification, several new issues were
raised at this meeting and most, but not all, were resolved. There
was consensus to resolve the remaining issues on the list and then
submit the document to the IESG to be considered for publication as an
information RFC.
Recent changes to the SHTTP document were reviewed and no objections
were raised. An outstanding issue is coordinating SHTTP with MOSS,
which is dependent on the harder (and outside our scope) problem of
coordinating HTTP with MIME. We remain hopeful that we will reach
consensus on a document to propose to advance to Proposed Standard by
the next IETF meeting Dallas.
o IP Security (IPSEC)
The interoperability testing of the recently approved Proposed
Standards was discussed. The majority of the meeting was devoted to
discussing Internet key management and the two working documents on
Photouris and ISAKMP.
o Site Security Handbook (SSH)
Two documents are expected to be available by the first week of
November, which will allow for final revisions to be proposed during
the next IETF meeting in Dallas followed by advancing the documents
onto the standards track as quickly as possible.
The Security Area Directorate met on Monday afternoon for a 2 hour
meeting. In addition to all of the above, the following was noted.
o Intellectual Property Rights (IPR)
The purpose of the discussion was information exchange. Several
protocols are pending in the IESG as a result of unresolved IPR issues
and several protocols from the security area are about to be submitted
to the IESG with unresolved IPR issues. It is uncertain exactly what
the outcome will be of any specific case.
o Key-ed MD5
Key-ed MD5 is being used in a variety of protocols for authentication.
The IETF needs an applicability statement which includes advice on how
often to change the secrets.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMEdqFMUtR20Nv5BtAQELhwP/eTwVc+07AA19P0Q7KdfHxTAaNjnsPBRY
4bb2ekatHDaL5oVH2bbad1DECgOVU2Y0tKBXBNO3Pw1vQiMOV874ZeMIWNtcuxJE
MUcd9PLXekRoIUGmUdQMdnVhGEhb4NWPAi6KXzkWRxLN0wZNG9tyjkb7qLCo0dLe
+98gDe4dO1c=
=2CtY
-----END PGP SIGNATURE-----