DRAFT CAT minutes for Stockholm

[John Linn <[e-mail]>]

CAT fanciers:

Attached is a draft set of minutes for last week's meetings.  My
thanks to Richard Graveman for making the notes he'd collected in real
time on his laptop available as input to this compilation.  Please
review and submit to the list any additions or corrections by next
Tuesday, 1 August so that they can be reconciled and reflected in the
version to be submitted to the Secretariat later next week.

Thanks, regards, ...

--jl

-----------draft minutes follow, cut here-------------

Minutes for Common Authentication Technology (CAT) working group
sessions at Stockholm IETF, July 1995, 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 specs and a new mechanism spec 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 WG 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 WG had been shut down and a
new telnet security WG 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 (draft-ietf-cat-gssv2-03.txt,
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. RFC1508:

- Credential management: Add_cred(), refined discussion of credential
semantics, esp. wrt multi-mechanism issues and default references

- Name object routines: Import/Export_name_object()

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

- Buffering support: Wrap_size_limit()

- Context export: Import/Export_sec_context()

- Anonymity support

- Generic host-based service name type

- Additional OID support facilities

- 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're 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 WG 
"pseudo-last call".  The following points need to be reflected in
the high-level spec: 

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

- Acquire and insert OID assignments

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

- Reflect credential element terminology per revised C bindings

- Discussion later in the meeting re 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.

- Include "prot_ready_state" facility (see next section, "CONTINUE_DEFERRED
PROPOSAL").

- Incorporate clarifying text re 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)): 

Bob 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 modfication 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 appplications 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,
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 WG 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 I-D 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 4 stages: acquire credential;
establish security environment; per-unit protection; 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 (presentation, B. Blakley)

This proposal is motivated by a desire to support and dynamically
configure GSS-API installations with independent modules corresponsing
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 I-D 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 (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 I-D 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 I-D (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 I-D
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, 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 I-D (planned for August), including
a few clarifications plus the new text re 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 I-D 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
WG re 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:

- delegation (presumption: unsupported within specification)

- possible need for additional text re context expiration semantics

- phrasing of sequence indicator (text proposed to list)

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

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

- documented procedure for processing host-based service name

- discuss use of MD2.5 integrity, given recent results and discussion
in IPsec

FIPS PUB JJJ GSS-API MECHANISM (draft-ietf-cat-fipsjjjgss-00.txt; 
presentation by Sandra Murphy (TIS))

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/fips/pkauth.<ps|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 standalone (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 re 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)
(presentation, J. Myers (CMU), based on RFC-1731.)

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); (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; (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, (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:

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

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

- Credential and/or context annotation

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

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:

- Compound principal support, identifying intermediary entities as
well as initiators

- Delegation constraints and controls (asserted as hard to specify)

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

- facilities for policy management and query interfaces (asserted as
hard to specify)

- facilities for interdomain operation (pervasive attribute)

- ability to support capability-based mechanisms (pervasive attribute)

WORKING DOCUMENTS AND NEXT STEPS

RFCs 1508, 1509 (GSS-API, C Bindings): Proposed Standards. GSS-V2
Internet Drafts prepared (draft-ietf-cat-gssv2-03.txt,
draft-ietf-cat-gssv2-cbind-01.txt).  Plan WG Last Call to be issued
early in August, targeting recommendation for new Proposed Standards.

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

I-D draft-ietf-cat-kerb5gss-02.txt (Kerberos GSS-API mechanism). New
I-D planned in August, then to be reviewed for advancement.

I-D 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.  New I-D planned in August.

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

I-D draft-ietf-cat-wingss-00.txt (GSS-API V1 MS Windows DLL
interface). New I-D planned for August, including changes for 32-bit
support, then to be reviewed for advancement. New I-D will reflect
GSS-V2 assuming that GSS-V2 is stable.

I-D draft-ietf-cat-ftpsec-08.txt (FTP security).  Successor I-D to be
issued in August, incorporating protocol flow diagram, then to be
placed in WG Last Call for advancement to Proposed Standard.

I-D draft-ietf-cat-snego-00.txt (GSS-API Negotiation Mechanism). No
decision made re advancement.

I-D draft-ietf-cat-spkmgss-04.txt (SPKM). In IETF Last Call for
advancement to Proposed Standard.  Need to correct stated use of BER
encoding to DER, include assigned OIDs; changes to be reflected in new
I-D after Last Call period completed.

I-Ds draft-ietf-cat-idup-gss-02.txt, draft-ietf-cat-idup-cbind- 01.txt
(IDUP and C bindings). To be considered, along with other IDUP drafts,
for advancement as of December meeting.

I-D draft-ietf-cat-pim-00.txt (PEM-based IDUP mechanism). To be
considered, along with other IDUP drafts, for advancement as of
December meeting.

I-D draft-ietf-cat-fipsjjjgss-00.txt (FIPS JJJ GSS-API mechanism).  No
decision made re advancement.