Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/cat/cat-minutes-95jul.txt

Text File | 1995-10-18 | 30KB | 625 lines

CURRENT_MEETING_REPORT_


Reported by John Linn/OpenVision

Minutes of the Common Authentication Technology Working Group (CAT)

The minutes were compiled by John Linn (OpenVision) based on notes taken
by John Linn and Richard Graveman (Bellcore).

The CAT Working Group met for two sessions at the Stockholm IETF. Topics
related to active documents included 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 Mechanism (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 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.



General Discussion


FTP security:  All technical issues known to be pending against the
current FTP security specification (draft-ietf-cat-ftpsec-08.txt) have
been resolved.  A new version, including a clarifying protocol flow
diagram, will be issued after the meeting and placed in working group
Last Call for advancement to Proposed Standard.  The alternate proposal,
draft-ietf-cat-altftp-00.txt, has been retracted from standards-track
contention.

Telnet/GSS-API: A Telnet/GSS-API draft has been produced by Trusted
Information Systems (TIS), announced on the telnet-ietf list and
providing authentication and encryption.  One technical issue is that
the ``must encrypt'' bit is sent in the clear.  A procedural issue is
that no forum is currently active in the IETF to resolve issues related
to this draft:  the former TELNET Working Group had been shut down and a
new telnet security working group was going to be started under Ted
Ts'o's leadership, but this has not yet taken place.  Ted solicited
volunteers to assist on this.  The telnet mailing list,
[e-mail], will be revised for discussion of this draft.


Base GSS-API-V2 Discussion


The documents are draft-ietf-cat-gssv2-03.txt and
draft-ietf-cat-gssv2-cbind-01.txt.

It appears that we are quite close to preparing GSS-V2 to be recommended
for advancement; one more pair of Internet-Drafts is anticipated
following discussion at the meeting.

Summary of GSS-V2 function changes made vs.  RFC 1508:


   o Credential management:  Add_cred(), refined discussion of credential
     semantics, especially with regard to multi-mechanism issues and
     default references

   o Name object routines:  Import/Export_name_object()

   o Status queries:  Inquire_context(), Inquire_names_for_mech(),
     Inquire_cred_by_mech()

   o Buffering support:  Wrap_size_limit()

   o Context export:  Import/Export_sec_context()

   o Anonymity support

   o Generic host-based service name type

   o Additional OID support facilities

   o New GSS_S_GAP_TOKEN status for sequence integrity; additional
     choices for some calls among existing major_status codes


There was apparent consensus among the attendees at the meeting that
these changes constitute incremental modifications in response to
implementation experience, and the fact that GSS-V2 is
backward-compatible for GSS-V1 callers was recognized as significant;
the current belief, however, is that GSS-V2 will enter the standards
track at the Proposed Standard rather than Draft Standard level because
of the fact that implementations are lagging the specifications and that
we are not now in a position to demonstrate multiple, interoperable
GSS-V2 implementations.

GSS-V2 Status and Issues:

No criticisms of the current content were posted during recent working
group ``pseudo-last call''.  The following points need to be reflected
in the high-level specification:


   o Add_cred():  high-level specification needs specific changes to
     align with C bindings, regarding the following:  copy vs.  in-place
     credential modifications; returning of separate times for initiate,
     accept usage; clarification that mech_set describes full accumulated
     set.

   o Acquire and insert OID assignments.

   o Make sure that return of a token from GSS_Delete_sec_context() can,
     like token return from GSS_Init_sec_context() and
     GSS_Accept_sec_context(), be optional from the viewpoint of a
     mechanism as well as of a caller.

   o Reflect credential element terminology per revised C bindings.

   o Discussion later in the meeting regarding the FIPS JJJ mechanism
     proposal pointed out that GSS-V2 should state that mechanisms
     providing no per-message services should return errors if GSS_Wrap()
     or GSS_GetMIC() is called, rather than quietly returning tokens that
     actually provide no protection.

   o Include ``prot_ready_state'' facility (see next section,
     ``CONTINUE_DEFERRED Proposal'').

   o Incorporate clarifying text regarding possible combinations of
     anon_state and mutual_state, describing the four possible cases:

      -  anon_state == FALSE, mutual_state == FALSE: initiator
         authenticated to target.

      -  anon_state == FALSE, mutual_state == TRUE: initiator
         authenticated to target, target authenticated to initiator.

      -  anon_state == TRUE, mutual_state == FALSE: initiator
         authenticated as anonymous principal to target.

      -  anon_state == TRUE, mutual_state == TRUE: initiator
         authenticated as anonymous principal to target, target
         authenticated to initiator.


Note:  authentication as the anonymous principal does not necessarily
imply that credentials are not required in order to establish a context.


CONTINUE_DEFERRED Proposal

Bob Blakely (IBM) presented a summary of a paper previously distributed
to the mailing list, suggesting a GSS-API interface extension to enable
protection and buffering of data messages for later transfer while a
security context's establishment is in GSS_S_CONTINUE_NEEDED status, to
be used in cases where the caller side already possesses the necessary
session key to enable this processing.  Citing a specific example, Bob
noted that such a facility would be useful in order to apply lightweight
Kerberos authenticators for high transaction rate LU 6.2 applications.

Following some controversy, apparent consensus was reached among
attendees that a modification towards this goal is acceptable as an
addition to the GSS-V2 specification.  Following some refinement, the
current specific proposal is that a new state Boolean (similar to
anon_state), called prot_ready_state, be added to the return signatures
of GSS_Init_sec_context() and GSS_Accept_sec_context().

This state Boolean is valid when the major_status is either
GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both
initiators and acceptors) can assume that per-message protection (via
GSS_Wrap/Unwrap and GSS_Get_MIC/Verify_MIC) is available and ready for
use if either:  prot_ready_state == TRUE, or major_status ==
GSS_S_COMPLETE, though mutual authentication (if requested) cannot be
guaranteed until GSS_S_COMPLETE is returned.

This achieves full, transparent backward compatibility for GSS-API V1
callers, who need not even know of the existence of prot_ready_state, and
who will get the expected behavior from GSS_S_COMPLETE, but who will not
be able to use per-message protection before GSS_S_COMPLETE is returned.

It is not a requirement that GSS-V2 mechanisms ever return TRUE
prot_ready_state before completion of context establishment (indeed, some
mechanisms will not evolve usable message protection keys, especially at
the context acceptor, before context establishment is complete).  It is
expected but not required that GSS-V2 mechanisms will return TRUE
prot_ready_state upon completion of context establishment if they support
per-message protection at all (however GSS-V2 applications should not
assume that TRUE prot_ready_state will always be returned together with
the GSS_S_COMPLETE major_status, since GSS-V2 implementations may
continue to support GSS-V1 mechanism code, which will never return TRUE
prot_ready_state).


Store-and-Forward Support (Including IDUP)

This topic discussed the active IDUP drafts
draft-ietf-cat-idup-gss-02.txt, draft-ietf-cat-idup-cbind-01.txt, and
draft-ietf-cat-pim-00.txt.  BNR is implementing IDUP with IDUP-PEM, and
intending to follow with an implementation layered on MSP; presentations
on the IDUP topic were given by Carlisle Adams and Dragan Grebovich of
BNR. It was suggested that the drafts be evaluated at the Dallas meeting
for advancement purposes, and that those members of the set judged to be
ready then be recommended to advance to Proposed Standards.

Changes in the IDUP drafts were summarized.  The lifetime of an IDUP
environment is tied to the lifetime of the credentials which establish
it.  Multiple stages of protection exist, and protected and unprotected
cases are distinguished.  Receipt (receiver controlled) and evidence
(for non-repudiation) facilities, with associated generate and process
calls, are new.  No receipt_token is now emitted by End_Unprotect.

A straw poll suggested that about 10-15 attending working group members,
a significant constituency of interest, have been reading the emerging
IDUP drafts, even though on-list discussion has been relatively quiet.
Denis Pinkas (Bull) had made prior comments by e-mail, and Dave Solo
(BBN) expressed the following concerns at the meeting:  concern with the
split of token and protected data into separate objects as implying the
need for protocol parsing by callers and possible conflict with MSP;
non-support for labeling and assured freshness; desire for greater
evidence support below the interface in a mechanism-independent manner.

IDUP C-bindings:  A new Internet-Draft was issued after the Danvers
meeting, aligned with GSS-V1 rather than GSS-V2; it was suggested and
accepted that support for at least the GSS-V2 Add_cred call would be
valuable in support of multi-mechanism credential sharing between IDUP
and GSS implementations.  Credential management is currently unchanged
from GSS-V1.

New major_status codes were added for evidence and receipt processing.
IDUP processing is divided into four stages:  acquire credential,
establish security environment, per-unit protection, and completion.
Groups of function calls operate on credentials, environments, per-IDU
processing, special-purpose (receipt, evidence), and support functions.
Environment-related changes are small in this draft; per-IDU calls
include small changes for protection and unprotection; no recent changes
have been made in credential or support calls.

The goal of the PEM IDUP mechanism is to support IDUP using PEM data
elements, not (necessarily) to emit a full PEM message verbatim.
IDUP-PEM creates a PEM header, optionally encrypting the IDU. An
IDUP-PEM caller must do any canonicalization, application of delimiters,
and PEM 6-bit encoding; IDUP does the security part of PEM. Bob Blakley
stated that it is desirable to decouple security from the rest of the
application, leaving integration into a specific protocol up to the
applications, but observed that the IDUP-PEM approach requires that the
application be aware of the underlying mechanism.  Open question for
list discussion:  is IDUP-PEM suitable as a basis to implement MOSS?


Loadable Multi-Mechanism Support

Bob Blakley presented the proposal.

This proposal is motivated by a desire to support and dynamically
configure GSS-API installations with independent modules corresponding
to multiple mechanisms, making it possible to install new mechanisms
without recompiling or relinking applications.  Operating systems could
be shipped with a multi-mechanism support framework, and mechanism
modules could be provided separately and loaded.  A PostScript document
was distributed to the list before the meeting; Bob plans to follow with
an Internet-Draft version reflecting comments.

In the proposal, a set of new calls add, delete, and replace mechanisms
and add name types.  These calls comprise a management interface,
ordinarily called at system startup and by callers separate from the
applications which will later call GSS-API services; they are not
intended for use once mechanisms, credentials, and contexts are active
within a system.  One element in the proposal, a facility to indicate
supported name types, is useful to GSS-API callers and is provided in
the GSS-V2 specification.

It was suggested that an implementation of the GSS-API Negotiation
Mechanism, which dispatches to other mechanism modules in any event,
might be an appropriate module to export the management interface.
Questions came up about the scope of the proposal (single process vs.
entire system), about whether its feasibility is OS-dependent, and about
how much of its functionality could be achieved by using dynamic
linking.  Bob Blakley stated that he had planned an implementation based
on OS/2's framework-layer dispatch facility, within which each
application links to its own copy of a framework library; it appeared,
by analogy, that comparable UNIX integration in a multi-process
environment would require kernel modifications.

Two issues were raised:  the current proposal is based on GSS-V1
specification, and an observation that there may be export control
issues with the ``plug in'' capability.  As with many export
discussions, this one terminated inconclusively:  suggestions included
restricting the strength of cryptography which a mechanism module
provides for GSS_Wrap() and masking the confidentiality request
indicator within the framework layer if required.


GSS-API Integration Into World Wide Web Browsers and Servers

Doug Rosenthal (EINet) presented this talk, similar to one which he had
given earlier in the week at the Web Transaction Security Working Group
(WTS) meeting.  He observed that the Web is one, but not the only,
application important for electronic commerce; he believes that use of
common security technologies and credentials across Web and other
applications is a valuable goal.  Web-applicable GSS services are
authentication, confidentiality, integrity, and (potentially)
signatures; he observed that credential sharing between GSS and IDUP
mechanisms provides important value which can be exploited through
GSS-API integration, as will availability of the GSS-API Negotiation
Mechanism.

For Web integration, Doug's approach uses a new URL type (gss-http);
entire transactions are protected.  A URL is used to identify the target
service by name.

EINet is integrating GSS-API with winWeb and macWeb browsers and NCSA
httpd server, using BNR's SPKM toolkit.  The pilot implementation uses
EINet CA services; work is underway on adding access control on
authenticated user IDs.  Kerberos integration, and an Internet-Draft on
the integration approach, are planned.

Doug asserted that SSL's cryptography could be used to construct a
GSS-API mechanism.  S-HTTP is Web-specific, so did not appear to be a
candidate GSS mechanism, although S-HTTP could conceivably be written
with GSS-API.

The current approach is GSS-based rather than GSS-IDUP, and Doug
believes that most current Web requirements can be satisfied with GSS.
Coexistence with IDUP will be valuable to secure other applications
(e.g., mail) using common credentials.


GSS-API Negotiation Mechanism

An Internet-Draft (draft-ietf-cat-snego-00.txt) on a Simple GSS-API
Negotiation Mechanism has been posted, and Denis Pinkas led its
discussion.  An OID identifies a mechanism, and mechanism designers may
optionally define subordinate OID arcs to indicate options (e.g.,
algorithm choices) for use within their mechanisms; mechanism
specifications are to define behavior for the default option (mechanism
OID alone) and for any options subordinate to the mechanism.  An annex
to the Internet-Draft defines additional interface calls to allow
callers to set and query the sets of mechanisms and options which are to
be input to the negotiations in which they participate.

A new token (the negotiation token) is used; the negotiation mechanism,
like other mechanisms, is itself identified with an OID. The negotiation
model is two-way:  the initiator proposes one or more mechanism/option
sets; the target accepts no more than one set and may optionally return
data specific to the selected mechanism along with its reply.  The
target's preferences have precedence within the set proposed by the
initiator.  The negotiation itself is not protected and thus subject to
attack.  Bob Blakley pointed out that initiators should therefore make
sure that the value selected by the target was represented in the list
which the initiator proposed.  Ted Ts'o pointed out that with use of
options lists may get long; also, mechanism designers may take the use
of negotiation into account or ignore it and design their mechanisms for
stand-alone use.  Bob Blakley suggested that a ``template'' of mechanism
options would be useful.


Kerberos Mechanism and Kerberos Extensions

The RFC 1510 etype/keytype issue has been resolved, and no significant
discussions are currently active against this specification.  Looking
towards advancement of RFC 1510 (Kerberos) to Draft Standard, Cliff
Neuman (ISI) will issue a revised Internet-Draft (planned for August),
including a few clarifications plus the new text regarding keytype.

Public-Key Cryptography for Initial Authentication in Kerberos
(draft-ietf-cat-pk-init-00):  Several points need to be resolved on this
draft before advancement.  Comments are being discussed re underlying
assumptions; corrections and protocol changes have been proposed.
Issues include how a key is to be derived for generation of a response.
ISI is working on a prototype; a new version Internet-Draft is planned
for August.

Integrating One-time Passwords with Kerberos
(draft-ietf-cat-kerberos-passwords-01.txt):  This draft's implementation
(at CyberSafe) is pending and it was suggested that advancement
consideration be deferred pending implementation results.  The draft was
stated to be independent of one-time password (OTP) method, but Denis
Pinkas observed a need for coordination with the OTP working group
regarding S/Key support and discussion is ongoing on the list.

Kerberos V5 GSS-API Mechanism (draft-ietf-cat-kerb5gss-02.txt):  the
following issues/points are to be confirmed and discussed as needed by
e-mail, as input to preparation of a revised Internet-Draft:


   o Delegation (presumption:  unsupported within specification)

   o Possible need for additional text regarding context expiration
     semantics

   o Phrasing of sequence indicator (text proposed to list)

   o CONF_FLAG, INTEG_FLAG usage in protocol (text proposed to list)

   o Principal object name type (per list discussion, to be
     implementation defined, using local object definition and caveating
     non-portability)

   o Documented procedure for processing host-based service name

   o Discuss use of MD2.5 integrity, given recent results and discussion
     in IPSEC


FIPS PUB JJJ GSS-API Mechanism

Sandra Murphy (TIS) presented the Internet-Draft,
draft-ietf-cat-fipsjjjgss-00.txt.

This mechanism specification is based on public-key cryptographic
authentication per ISO 9798, specifically as refined by the document
known as FIPS PUB JJJ and issued in the 6 June 1995 US Federal Register,
with a 90-day comment period.  (The document is also available on the
Web, at http://csrc.ncsl.nist.gov/ps/pkauth.ps and .txt.)  The mechanism
specification supports unilateral or mutual authentication; random
numbers are used as challenges, authentication requests may be explicit
or implicit, and certificates may optionally be transferred.

The mechanism design is stand-alone (i.e., does not rely on use in
conjunction with the GSS-API Negotiation Mechanism or equivalent), but
some option negotiation facilities (e.g., choice of signature algorithm)
are incorporated within the mechanism.  Six token types are used.

The question arose:  why not use SPKM instead of JJJ (in other words, if
one is to employ cryptography per FIPS-PUB-JJJ, why define a new
mechanism for this purpose rather than placing the cryptography within
the SPKM framework)?  Several differences were noted.  The JJJ
mechanism, unlike SPKM, generates no session key and therefore does not
support per-message services; SPKM does not provide a ``no per-message
service'' option.  SPKM, unlike JJJ, assumes that all implementations
can perform mutual authentication.  The text fields defined in
FIPS-PUB-JJJ cannot be represented in SPKM tokens; these fields are
inaccessible to callers within the scope of the interface, but may be
important for use and internal consumption within mechanism
implementations.  It was noted that the FIPS JJJ mechanism specification
orders data elements per ISO 9798 and that SPKM does not, but this issue
did not appear to be a critical conformance requirement since ISO 9798
does not specify concrete syntax.

Ted Ts'o suggested that all capabilities of the FIPS JJJ mechanism were
apparently subsumed as subsets of SPKM, so perceived no reason to pursue
standardization of the JJJ mechanism within the IETF. Bob Blakley
asserted that availability of a FIPS JJJ mechanism specification as an
Internet standards-track document would be a benign result.  No motion
or decision regarding standards advancement was pursued during the
session.

Denis Pinkas noted a potential compatibility problem between negotiation
as defined for the JJJ mechanism and the GSS-API semantics of
mutual_state; Sandra believed that the specifications were compatible in
this area; more review and clarification is needed here.


Simple Authentication and Session Layer (SASL)

The presentation was given by J. Myers (CMU).

This proposal is a generalization of RFC 1731 (currently Proposed
Standard) facilities for IMAP4 authentication mechanisms, providing a
generic framework for integrating security tokens into a range of
text-based command stream applications.  In addition to IMAP, the
technique has been applied to and/or proposed for FTP, POP3, SMTP, LDAP,
and other protocols.  At the SASL level, recognized ``mechanisms''
include Kerberos V4, GSS-API, and S/Key.

SASL steps are:  (1) identify mechanism; (2) authenticate (negotiate
protection, buffer size, pass authorization userID); and (3) establish
protection (optionally):  integrity or privacy, can perform compression
as well.

SASL per-protocol integration profiles contain:  (1) server
authentication identity, e.g., POP; (2) command to start authentication;
(3) defined method to exchange tokens (applying base64 encoding if
needed); (4) defined method to abort exchange; and (5) identification of
where protected stream starts.

Work is pending to generalize RFC 1731 into SASL: (1) change name; (2)
remove IMAP4-centrism; (3) document profiling requirements; (4)
establish or adopt registry of mechanisms; and (5) include the session
layer protocol definition.

John Linn stated that SASL appeared to be an appropriate item for
discussion within CAT, as well as within groups representing potential
SASL consumers, and asked about implementation status.  Kerberos V4 is
being used, but Kerberos V5 and GSS-API have not yet been tested.  It
was suggested that future mechanisms should preferably be added under
GSS-API rather than at the SASL level.

As a security integration vehicle, SASL might also have relevant
interest to the SSL community.


Authorization

We discussed the scope of follow-on work in the area of authorization,
placing priority on items implementable and broadly useful.  Several
candidate topics were identified.  The following set appeared to offer
the most likely prospects for tangible near-term work building on the
current CAT technology base and offering benefit to a wide constituent
community, and specific proposals were solicited over the upcoming
months:


   o Authorization query interface (e.g., based on an ACL associated
     with an object).

   o Attribute definitions, applicable to principals, contexts, and
     data.  (Existing mechanisms, such as Kerberos and SPKM, include
     facilities to transfer authorization data objects, but those
     objects' content is not currently defined within the mechanisms.)
     Specific examples of interest include a canonical form of principal
     identifier and indications of a principal's group affiliations.

   o Credential and/or context annotation.

   o Attribute extraction from contexts.


It was noted that OSF's DCE-RFC 5 specifies some relevant GSS-API
extensions within the DCE environment; Bob Blakley agreed to investigate
releasability of this specification to the CAT Working Group.

Ted Ts'o proposed the idea of a GSS_Export_name() routine, which would
accept an internal name and emit a canonicalized binary name
representation.  The intended use of its output would be as a lookup key
to be applied against an ACL in a mechanism-independent manner.  If
names are to be used across mechanisms, or if authentication and
authorization mechanisms are to be mixed and matched, added complexity
arises and more definitions are needed than are presently available.

John Linn asked whether this could be accomplished with
GSS_Export_name_object() along with a newly-defined canonical name type;
Ted believed that buffer management facilities in
GSS_Export_name_object() were inappropriate, but more thought and
discussion on the list is needed here.

Additional areas were identified, but appeared to be longer-term topics,
pervasive attributes, or items of more limited interest:


   o Compound principal support, identifying intermediary entities as
     well as initiators.

   o Delegation constraints and controls (asserted as hard to specify).

   o Additional outputs from authentication (e.g., time of day, routes
     traversed), if a set of generic interest can be defined.

   o Facilities for policy management and query interfaces (asserted as
     hard to specify).

   o Facilities for interdomain operation (pervasive attribute).

   o Ability to support capability-based mechanisms (pervasive
     attribute).


Working Documents and Next Steps

   o RFCs 1508, 1509 (GSS-API, C Bindings) are Proposed Standards.
     GSS-V2 Internet Drafts prepared (draft-ietf-cat-gssv2-03.txt,
     draft-ietf-cat-gssv2-cbind-01.txt).  Working group last call is
     planned to be issued early in August, targeting recommendation for
     new Proposed Standards.

   o RFC 1510 (Kerberos) is a Proposed Standard.  Cliff Neuman to revise
     to new Internet-Draft in August, incorporating various
     clarifications and specifying resolution of keytype issue.  The
     result to be considered for advancement to Draft Standard.

   o Internet-Draft:  draft-ietf-cat-kerb5gss-02.txt (Kerberos GSS-API
     mechanism).  A new Internet-Draft is planned for August.  It will
     then be reviewed for advancement.

   o Internet-Draft:  draft-ietf-cat-kerberos-pk-init-00.txt (Kerberos
     Public-Key Initial Authentication).  Reference implementation in
     progress.  Pending issues to be resolved, and implementation
     results gained, before advancement.  A new Internet-Draft planned
     for August.

   o Internet-Draft:  draft-ietf-cat-kerberos-passwords-01.txt (Kerberos
     One-Time Passwords).  Advancement decision pending on reference
     implementation results, resolution of ongoing e-mail discussion,
     possible coordination with OTP S/Key activities.

   o Internet-Draft:  draft-ietf-cat-wingss-00.txt (GSS-API V1 MS
     Windows DLL interface).  A new Internet-Draft is planned for
     August, including changes for 32-bit support.  It will then to be
     reviewed for advancement.  The new Internet-Draft will reflect
     GSS-V2 assuming that GSS-V2 is stable.

   o Internet-Draft:  draft-ietf-cat-ftpsec-08.txt (FTP security).
     Successor Internet-Draft to be issued in August, incorporating
     protocol flow diagram.  It will then be placed in working group
     last call for advancement to Proposed Standard.

   o Internet-Draft:  draft-ietf-cat-snego-00.txt (GSS-API Negotiation
     Mechanism).  No decision has been made regarding advancement of
     this document.

   o Internet-Draft:  draft-ietf-cat-spkmgss-04.txt (SPKM). The document
     is in IETF Last Call for advancement to Proposed Standard.  Need to
     correct stated use of BER encoding to DER, include assigned OIDs.
     The changes are to be reflected in the new Internet-Draft after the
     Last Call period is completed.

   o Internet-Drafts:  draft-ietf-cat-idup-gss-02.txt,
     draft-ietf-cat-idup-cbind-01.txt (IDUP and C bindings).  Revised
     versions of these documents are expected in advance of the Dallas
     meeting.  They are to be considered, along with other IDUP drafts,
     for advancement as of Dallas meeting.

   o Internet-Draft:  draft-ietf-cat-pim-00.txt (PEM-based IDUP
     mechanism).  To be considered, along with other IDUP drafts, for
     advancement as of the December IETF meeting.

   o Internet-Draft:  draft-ietf-cat-fipsjjjgss-00.txt (FIPS JJJ GSS-API
     mechanism).  No decision has been made regarding advancement of
     this document.