Security Area
Director(s):
o Steve Crocker:
[email protected]
Area Summary reported by Steve Crocker/TIS and Jim Galvin/TIS
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 appendix to this report defines what is meant by ``security'' on the
Internet.
Much of the work of the Security Area is performed in coordination with
working groups in other areas. The Security Area Advisory Group (SAAG)
is a group of security experts which provides both consulting help to
other areas and direct management of working groups within the Security
Area.
The main bulk of the work for the SAAG consists of a set of formal work
items. These work items correspond to working groups within the IETF
Security Area, security-relevant developments within working groups in
areas other than security, and internal SAAG work items which do not
merit the creation of formal working groups but which do need some level
of attention.
Below is the status of each of the working groups officially chartered
or initiated within the Security Area. Immediately following those
reports is an update on other security issues as well as security
related work in other IETF areas.
Authorization and Access Control Working Group (AAC)
The AAC Working Group met on Wednesday afternoon. The need for
demonstrations of the technology was discussed; possible applications
for an authorization API include Prospero, remote execution, database
access, and file transfer. The representation of authorization
information for access control lists and distributed authorization
credentials was discussed. There was some contention on this topic.
At the SAAG meeting is was suggested that some of the work arising from
this working group may be best addressed initially by the PSRG. Cliff
will follow-up on this.
Common Authentication Technology Working Group (CAT)
The CAT Working Group met for two sessions at the Amsterdam IETF,
discussing (in about equal proportion) general CAT issues and FTP
security integration. We reviewed the status of implementation and
specification activities, identified items requiring follow-up work, and
managed to associate individuals and subset groups with several of the
desired items.
The GSS-API base specification, GSS-API C Language Bindings, and
Kerberos Version 5 documents have been submitted, adopted, and published
by the IESG as Proposed Standards.
The DASS document has been submitted, adopted, and published by the IESG
as an Experimental Protocol.
Commercial Internet Protocol Security Option Working Group (CIPSO)
There is a new draft of the CIPSO specification; Steve Crocker will make
sure it gets published as an Internet-Draft.
There are several folks who are unsatisfied with this document,
including both SAAG and PSRG members. There has been some difficulty
getting the issues communicated effectively to Ron Sharp. Steve Crocker
has been tasked with resolving the conflicts.
Internet Protocol Security Protocol Working Group (IPSEC)
The meeting was opened by Al Hoover with an introduction to the IPSEC
Working Group for first time attendees, a review of the approved IPSEC
charter, a review of liaisons between IPSEC and IPng, IEEE, CAT, and
other working groups. A brief discussion of preliminary implementations
related to IPSP was discussed. Absences of IPSEC implementors limited
the scope to a review of the various approaches (SwIPe, NLSP, SP3).
IPSEC would like to target demonstrations of preliminary implementations
(non-interoperable) for the Houston (November) IETF. Demonstrations of
preliminary interoperable implementations is targeted for the March
IETF.
Network Access Server Requirements Working Group (NASREQ)
The NASREQ Working Group meeting was sparsely attended on Thursday
morning. Lacking critical mass, there was little discussion about any
of the outstanding issues. The modified charter and schedule was
reviewed. The chair requested volunteers to help write sections of the
draft. (One person expressed willingness to help, provided he received
approval from his management.) Representatives from the ACCT Working
Group and the AAC Working Group requested more contact and information
flow between the groups.
Privacy-Enhanced Electronic Mail Working Group (PEM)
The PEM Working Group met for one, 2-hour session on Wednesday
afternoon. The meeting opened with reports on implementation status
from seven PEM developers, representing commercial, research, and
academic communities.
Next, the meeting addressed the continuing topic of MIME-PEM
integration. No substantive progress was made on this topic, due to a
lack of written submissions for review prior to the meeting.
Nonetheless, there was a discussion of this topic, based on a very
recent discussion between two of the authors of the relevant
Internet-Draft. A presentation on the use of Distinguished Names versus
Domain Name System names in certificates followed, but was truncated
because of time limitations.
A presentation on the rationale for the current certification system
design was skipped, also due to time constraints. Full text of the
slides for both of these presentations will be included as an appendix
to the meeting minutes. The meeting concluded with a discussion of
triple-DES modes of use for PEM, and a paper exploring this issue was
distributed at the meeting. While there was substantial sentiment for
one of the modes, it was agreed that further analysis is called for.
SNMP Security Working Group (SNMPSEC)
In conjunction with the SNMPv2 Working Group, twelve documents have been
completed and published as Proposed Standards. This work item was
officially closed at the Amsterdam IETF.
TELNET Working Group (TELNET) - Applications Area
There is no security-relevant progress to report from the Amsterdam
IETF.
Router Requirements Working Group (RREQ) - Internet Area
The previous single document has been split into four documents and a
number auxiliary documents. Phil Almquist has responsibility for
finishing the documents and submitting them to the IESG for publication.
Domain Name System Working Group (DNS) - Service Applications Area
A mailing list and subcommittee of the DNS Working Group has been
created. Work on DNS security is expected to begin on the mailing list.
Trusted Network File System Working Group (TNFS) - Service Applications
The TNFS Working Group meets principally under the auspices of the
Trusted Systems Interoperability Group.
No progress to report.
Audio/Video Transport Working Group (AVT) - Transport Area
This activity was to be reviewed to identify the security issues for the
Amsterdam meeting.
No progress to report.
Integrated Directory Services Working Group (IDS) - User Services Area
Privacy constraints exist for the data, but there was no substantial
discussion at this time.
Export Control Issues
Vint Cerf and Steve Crocker need to press forward on drafting a
document.
IP: The Next Generation
A plan for processing a security review of the competing next generation
proposals were to be drafted for the Amsterdam meeting.
No progress to report.
IRC
A document in RFC format exists that purports to document this protocol.
At this time, this work item exists to track this activity.
ITAR Publication
An on-line version of the US International Traffic in Arms Regulations
(ITAR) will be created as soon as it has been published in the Federal
Register, probably as an informational RFC.
Key Management Strategies
A review of key management strategies and activities was to be drafted
for the Amsterdam meeting.
No progress to report. At the SAAG meeting it was asked why this work
item is called out separately from the IP security work item. John will
be asked to address this question in his draft.
Mobile IP Security
John Ioannidis was to report on the relationship between this work item
and the IP security work item at the Amsterdam SAAG meeting; he was not
present at this meeting. Al Hoover will follow-up with John on the
status of this work item.
Random Number Generation Issues
A revised Internet-Draft is overdue. Jeff Schiller will follow-up with
Don Eastlake to arrange a new draft.
Routing Security Plan
No progress to report. Steve Crocker will follow-up with Radia Perlman.
Security Area Architecture
Included at the end of this report is a copy of the summary description
of the security area in the IETF.
Working Group Liaison Checklist
A checklist was prepared and distributed at the SAAG meeting. A copy
will be distributed to the SAAG Interest mailing list for discussion.
APPENDIX
The Security Area
Steve Crocker
The Security Area is concerned with the addition of security services
throughout the Internet protocol stack and throughout the Internet
itself. The term "security" covers a handful of interrelated concepts.
In broad terms, the concept means protection against unauthorized
actions of others. In the Internet community, we're concerned with at
least the following forms of security.
Confidentiality: Protection of information against unauthorized
disclosure. For information that is in transit across the Internet,
this means making sure that only the intended recipient(s) see it.
Integrity: Protection of information against tampering. For
information in transit across the Internet, this means making sure
that the receiver gets what was sent, or at least knows whether the
data that arrives is in fact a true copy of the data that was sent.
Authentication: Verification of the identity of the parties involved
in a transaction. In Internet transactions, this means providing
assurance that the identification of the sender is correct and has
not been forged, and that the actual recipient is the one(s) that
the sender specified as the authorized recipients.
Access Control: Control over who is allowed to access or use various
resources.
This list is not complete. Security is a broad term and covers an
open-ended list of services.
Another dimension to security is who is being protected from whom? A
network, for example, is obliged to provide some degree of protection to
its customers. It may promise its customers that it will not tamper
with nor disclose user information while that information is within its
perimeter. In this case, the network is providing protection to the
users, and the users will either trust or not trust the network to
provide this form of protection.
At the same time, the network needs to be protected from damage,
disruption or penetration by users. Thus the network operator is also
interested in assurance that his assets are protected against
undesirable acts by the users.
Because security cuts across all layers in the protocol stack and hence
affects all areas, the work of the Security Area includes both the
development of protocols within the Area and the assistance of working
groups in other areas. The Security Area Advisory Group (SAAG)
functions as the Area's internal advisory group, much like a
directorate, and also serves as a source of experts to provide guidance
and participation in other areas.
