From: Rich Salz <rsalz@osf.org>
Date: Fri, 1 Sep 95 20:02:30 PDT
To: cypherpunks@toad.com
Subject: IETF security report
Message-ID: <9509020301.AA17722@sulphur.osf.org>
MIME-Version: 1.0
Content-Type: text/plain


>From saag-request@neptune.tis.com 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 <rsalz@osf.org>; 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" <jis@mit.edu>
Sender: jis@mit.edu
To: minutes@cnri.reston.va.us
Subject: IETF Security Area Report (July 17-21, 1995: 33rd IETF meeting)
Cc: secdir@TIS.COM, saag@TIS.COM
Status: R

-----BEGIN PGP SIGNED MESSAGE-----

                       IETF Security Area Report
                      Jeff Schiller and Jim Galvin
                              jis@mit.edu
                             galvin@tis.com

                            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 <jis@mit.edu>
        Ran Atkinson <atkinson@itd.nrl.navy.mil>
        Steve Bellovin <smb@research.att.com>
        Steve Crocker <crocker@tis.com>
        Barbara Fraser <byf@cert.org>
        James M. Galvin <galvin@tis.com>
        Phil Karn <karn@qualcomm.com>
        Steve Kent <kent@bbn.com>
        John Linn <linn@ov.com>
        Clifford Neuman <bcn@isi.edu>
        Rob Shirey <shirey@mitre.org>
        Ted Ts'o <tytso@mit.edu>

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   saag@tis.com mailing list.    Send  a message  to  the address
saag-request@tis.com 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-----