Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/93nov/area.security.93nov.txt

Text File | 1994-02-23 | 12KB | 284 lines

Security Area

Director:


   o Steve Crocker:  [e-mail]


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.

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 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.

Following the SAAG minutes is a status report for 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.



Security Area Advisory Group (SAAG)

During the monday afternoon meeting, Steve Crocker led a discussion on
Internet security architecture issues.  Topics included application
support for security, transport/network layer support for security,
identification of zones of trust, and firewalls.

The discussion included the following points.


   o Are firewalls the best (or at least one of the best) approaches to
     security?  Consider that applications today expect to be
     end-to-end, i.e., in general they are not firewall friendly.  If
     firewalls are a direction of the IETF/Internet, then there should
     be a statement of this principle so that we build all future
     protocols with it in mind.

   o The PSRG is working on a security architecture document.  It
     explicitly addresses end-to-end security services and mechanisms,
     while a hybrid approach involving firewalls appears to be more
     common.  In any case, a discussion of firewalls would be useful.

   o Firewalls were compared to the installation of burglar alarms in
     homes.  In particular, most people install alarm systems in
     response to a burglarly, as opposed to installing them as a
     preventative measure.  Is it possible that if environments (or
     protocols) protected themselves they might not need a firewall?
     Firewalls are a ``convenient'' security measure to install in the
     short-term.


In addition to the architecture discussion, Steve Kent presented a
status of the PSRG security architecture document, Bill Simpson
expressed a desire for additional authentication mechanisms in PPP, in
particular Kerberos, and it was noted that although Triple-DES will be
discussed within the PEM working group, it is applicable in many
contexts and may need broader exposure.


Authorization and Access Control Working Group (AAC)

The AAC Working Group discussed a revised framework for representing
privilege attributes and restrictions for distributed authorization
credentials and access control list entries.  The new framework
addressed concerns raised at the Amsterdam IETF. Attributes are now
assigned to one of three classes:  privilege attributes, restrictions,
and aggregates.  The contents of the security context used as input to
the authorization API was discussed next.  The security context should
be filled in initially by the authentication mechanism (e.g., GSSAPI)
and might be subsequently augmented by other security mechanisms.  The
security context could include verified authentication and authorization
information, and might separately specify unverified information and
delegated credentials.  The form of the arguments and return values of
the authorization API was discussed next and will be further refined.
To close, the group discussed the drafting of a document to provide
network application developers with guidelines for supporting
authorization in their systems.


Common Authentication Technology Working Group (CAT)

The CAT Working Group met for two sessions in Houston.  The status of
ongoing activities was reviewed, including a reworked GSS-API
implementation for Kerberos V5 beta 3; this implementation, and an
Internet-Draft describing its GSS-API mechanism characteristics and
token formats, are scheduled to become available later this year.  Some
interface clarifications and extensions (e.g., a new GSS_Inquire_context
primitive) were discussed as inputs to Internet-Draft successors to RFCs
1508/1509, targeting inclusion in eventual Draft Standard versions to
supplant those RFCs and comprise a ``Version 2'' GSS-API. Related topics
to be discussed further on the mailing list include multi-mechanism
credential management and error reporting.  Piers McMahon gave a
presentation on SESAME's multi-mechanism implementation, and distributed
a paper for comment.  Sam Sjogren and Steve Lunt led a discussion on the
FTP Security Internet-Draft, to be updated shortly and to be used as the
basis for an interoperability test (using Kerberos V4 technology)
planned for March 1994.  Representatives from the NASREQ Working Group
described their currently-contemplated architecture, as input to
determining how the CAT Working Group and technology might support their
needs.  Ran Atkinson gave a presentation on the Internet Authentication
Guidelines Internet-Draft, receiving and soliciting comment from the
working group.


Internet Protocol Security Protocol Working Group (IPSEC)

There are several known experimental implementations of IP Security, two
of which demonstrated their approach during the Houston IETF.
Demonstrations of preliminary interoperable implementations is targeted
for the next IETF. Key management is still an open issue.  The
implementations include:


   o I-NLSP - Rob Glenn
   o swIPe - Phil Karn
   o KeyRing - Rob Hagens
   o TANDU/Cryptonette - Charlie Kaufman
   o LAN Guardian - Mike O'Dell
   o SP3 - Paul Lambert


Jim Zmuda and Phil Karn gave demonstrations of their implementations.
Jim's implementation was based on the ISO 11577 specification for
Network Layer Security Protocol (NLSP) and used the NLSP specification
of a Security Exchange Protocol (SAEP) for key management.  The
implementation demonstrated by Phil Karn was based on Phil's KA9Q
software running on a portable computer (80386 based).  This
demonstration ran between Houston and Phil's home.  Key management was
based on the manual entry of DES key variables.


Network Access Server Requirements Working Group (NASREQ)

A very brief presentation of distributed authentication was presented as
a possible future subject for the working group to consider.  The
possibility of changing the charter was discussed, and the following
elements were described as a possible direction:


   o Finish the NAS Requirements document and submit it for
     consideration as an Informational RFC following the Seattle IETF.

   o Revise the RADIUS protocol definition and submit it for
     consideration as an RFC after review at the Seattle IETF.

   o Move KAP/PKAP to the Point-to-Point Protocol Extensions Working
     Group (PPPEXT) and/or to a working group in the Security Area.

   o Focus the attention of the group on distributed authentication in
     support of shared dialin between organizations.  This will likely
     have other implications and should have significant support from
     security area folks to be successful.



Privacy-Enhanced Electronic Mail Working Group (PEM)

The meeting covered implementation status reports, discussion of
potential electronic notary services, PEM-MIME integration, certificate
servers, and triple-DES.

Only MIT and TIS implementation efforts were represented, but other
implementations are proceeding in various countries.

Dave Solo provided a presentation on various ``notary-style'' validation
services for non-repudiation (see slides following the PEM minutes):
simple time stamping, enhanced non-repudiation, document registration,
archival signature validation, assurance issues, validation of other
attributes.

Two MIME-PEM designs now exist:


   o MIME-PEM ``lite'' (Jeff Schiller)
   o MIME-PEM ``full-bodied'' (Steve Crocker)


These two proposals have different consequences and reflect some
divergence in goals within the PEM and mail communities.

Christian Huitema (INRIA) proposed a certificate server proposal for PEM
to facilitate retrieval of certificates and CRLs with locally managed,
simple databases.  The index for search is the user's mailbox name.
This calls for operators of the hosts that provide the user's mailbox to
provide this responder facility.  However, mail services such as
CompuServ and MCIMail are unlikely to provide this service.  A new
record type may need to be created to allow indirection to other than
the user's actual mailbox provider.  Also, this proposal is based on
TCP, but not all prospective PEM users are reachable by TCP, e.g., users
of non-IP nets or firewall.  There was a suggestion to add this facility
to FINGER instead, to minimize firewall problems.  It was proposed that
email-based access should be baseline, with real-time access an optional
additional service.

Triple-DES was discussed briefly.  At issue is the best method of using
triple-DES in CBC mode.  Burt Kaliski had circulated a summary of his
findings, but he was not present for discussion.  This remains an open
topic.



TELNET Working Group (TELNET) - Applications Area

There is a draft specification combining both authentication and
encryption security services.  Implementations of the specification will
be present for the next IETF.

In addition, the draft document specifying the use of Kerberos Version 5
as a TELNET authentication option has expired.  It will be resurrected.



Router Requirements Working Group (RREQ) - Internet Area

Due to lack of progress on the documents this work item was officially
closed as a Security Area concern.  If the working group is
reconstituted to continue work then the security area will re-open this
work item.  In the time since the Houston IETF, this document has
received renewed attention within the IESG and is now under the control
of the Internet area.



Domain Name System Working Group (DNS) - Service Applications Area

The DNS Security sub-group of the DNS working group met to identify the
threats, security services, and requirements of interest to the DNS. The
requirements will be distributed to the mailing list for discussion
until November 30, 1993.  After that time, strawman proposals may be
distributed until January 31, 1993.  The group will evaluate all
proposals with the goal of creating one proposal at the next IETF.

It was decided to create a DNS security working group.  In parallel with
the activities above a charter will be drafted for review and submission
to the IESG.

Export Control Issues

There was some consensus that there exists rumors that at least some of
the rules regarding export may change soon.  This work item exists to
track this activity.  (In the time since the Houston IETF meeting, no
changes in United States policy have been announced.)

IP: The Next Generation

An IPng Directorate has been formed to track and evaluate the IPng
proposals.  Steve Bellovin is a member of the directorate representing
the security area.

Mobile IP Security

There is a draft document describing what is identified as a weak
security mechanism and how it can be used until IP security is available
to provide strong security.  Phil Karn will distribute this description
to SAAG for review and comment.

Random Number Generation Issues

A revised Internet-Draft was distributed for comment.  It has been
published as an Informational RFC.


Routing Security Plan

This work item was re-assigned to Sandy Murphy at the Houston IETF. She
will prepare a draft document summarizing the authentication and
integrity issues in routing for the next IETF.