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

Text File | 1993-02-17 | 7KB | 161 lines

Security Area

Director(s):


   o Steve Crocker:  [e-mail]


Area Summary reported by Steve Crocker

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.

Security Area Advisory Group (saag)

The main bulk of work for this Group consists of a set of formal work
items.  These work items correspond to four types of activities.


  1. Working groups within the IETF Security area.  These are marked as
     ``Security.''

  2. Working groups in allied organizations that function as part of the
     IETF Security Area.  These are marked either ``PSRG'' for the
     Privacy and Security Research Group, or ``TSIG'' for working groups
     within the Trusted Systems Interoperability Group.

  3. Security relevant developments within working groups in areas other
     than security.  These are marked according to the relevant area,
     viz., Applications, Internet Services, Network Management, OSI
     Integration, Operational Requirements, Routing, Transport and
     Services, or User Services.

  4. Internal work items.  These are topics which do not merit the
     creation of a formal working group but which do need some level of
     attention.  These are assigned to a saag member and followed for
     one or more saag meetings.  These are marked as ``SAAG''.


The Security Area Advisory Group met during the first and last working
group period of the Santa Fe IETF. The first meeting is used to
coordinate the activities for the week and the second meeting is used to
report on the activities that have occurred.

During the week, of the twenty-three open work items on Monday, five
work items were closed and four new work items were opened.  Eight work

                                   1





items received no attention.  The key activities for the week to report
are all working groups in the Security Area:  SNMP Security, Common
Authentication Technology, and Privacy Enhanced Mail.

SNMP Security (snmpsec)

There are three documents which have been reissued.  There are four
implementations, three of which have been demonstrated to interoperate
with each other.  The final actions are cleaning up the documents,
reviewing them, and submitting them to the IESG for consideration as
Proposed Standards.

One of the important technical issues to be discussed was the choice to
be made between message digests:  MD4 and MD5.  It is clear that MD5 is
the right choice for standards actions or something that you want to
invent for some stability.  MD5 does run slower by some amount than MD4,
but the overall equation makes a fairly modest impact.  There will
probably be a lot of performance measurements showing up, but it is
pretty clear that performance is not the critical issue.

This decision effects a number of other working groups, each of which
had decided to adopt whatever choice is made by SNMP Security.  These
include the 822 Extensions and PPP Extensions Working Groups.

Common Authentication Technology (cat)

The basic idea is you have a set of applications that want access to one
or more authentication mechanisms, for example Kerberos or the
Distributed Authentication Security Service (DASS). There is a common
program interface, a general security services application program
interface, that has been defined such that these applications can be
written to be neutral with respect to which mechanism is actually
employed.  The binding with a mechanism takes place at some later time,
currently compile time.

The feature of the mechanisms currently proposed is they depend upon a
global identification scheme, i.e., you have a name that exists outside
the context of the machine you are trying to connect from or connect to.
The name identifies a set of credentials that area forwarded on your
behalf.  This raises the question of what happens when there is an
application of the technology on a machine on which your credentials do
not exist, for example a terminal server at an IETF meeting.  Does it
makes sense for one of the underlying mechanisms to be the use of
passwords?

This opened up the discussion in multiple directions, but the critical
question is what is the ambition level of the CAT technology, with
respect to a much larger set of issues in security, authentication,
identification, and in particular with respect to authorization.  For
now, CAT will continue down the path it is on.  There will be subsequent
activity to serve these larger functions.

There is a set of documents in preparation.  Two Internet Drafts exist
that describe the interface, a basic functional description, and

                                   2





specific C structures.  An Internet Draft exists for each of Kerberos
and DASS.

Privacy Enhanced Mail (pem)

There was a great deal of controversy during the Atlanta meeting, but a
number of meetings and interactions have occurred since then, resulting
in substantial progress and resolution of major issues.  It is worth
noting there was a booth and demonstrations at INTEROP, where multiple
interoperating implementations were heavily attended during the whole
period.  It was a big success for everybody.

The key decision that came out of the meetings following Atlanta was to
open the range of policies.  There had been a single policy coming into
existence emphasizing very high assurance that the binding of the name
and public key in the certificate actually represented a real person and
had not been forged.  The controversy was focused on whether or not the
high assurance was appropriate in all cases.  The resolution was to push
the notion of assurance down one level in the certificate validation
hierarchy and create what are now called Policy Certification
Authorities, which are bound together by a policy neutral administrative
function called the Internet Certificate Authority.  The current
candidate policies are a continuation of the high assurance policy, a
mid-range policy, some support for residential users, and support for
persona users.

There will be two bodies of software available.  There is an
implementation Trusted Information Systems has been developing for some
time, that will include modifications to MH and a general purpose
filter, which will be distributed in source code form with an object
version of the cryptography supplied by RSA Data Security Incorporated
(RSADSI). RSADSI will separately make available a limited size tool kit,
in source form, on a you-build-it basis.  Neither of these is intended
for commercial applications.



                                   3