Notes from Common Authentication Technology (CAT) meeting, Munich
IETF, 13 August 1997, compiled by John Linn (with thanks to Rich
Graveman (Bellcore) for access to his notes from the session and 
to Cliff Neuman (ISI) for providing copies of his presentation 
slides in text form). (This version contains a few detail-level
clarifications relative to the previous draft sent to the mailing 
list, per comments received from WG members.) 

The CAT WG met for one session at the Munich IETF.  

REVIEW OF ONGOING WORK ITEMS: FTP SECURITY

FTP Security (draft-ietf-cat-ftpsec-09) is in IESG hands and had been
inadvertently delayed in its IESG consideration, but is reportedly on
the agenda to be considered for Proposed Standard status at the next
IESG conference call.

REVIEW OF ONGOING WORK ITEMS: GSS-V2 AND C BINDINGS

Re GSS-V2, the proposed approach is to integrate the RFC2078bis
changes list into an updated GSS-V2 base Internet-Draft during
September, and then (following a WG Last-Call period) to submit the
resulting RFC2078bis and the GSS C bindings as an aligned set to the
IESG, requesting their advancement to Proposed Standards; this
proposed approach was acceptable to session attendees.  No more
than very minor changes to the C bindings are anticipated.

REVIEW OF ONGOING WORK ITEMS: SNEGO

Approximately 6 attendees indicated that they had reviewed
draft-ietf-cat-snego-06; approximately 15 indicated familiarity with
this or previous snego versions.  It had been believed that
draft-ietf-cat-snego-06 represented WG consensus for advancement, but
Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position
that draft-ietf-cat-snego-06 does not reflect previously established
WG consensus in certain areas, and were to detail the specifics of
their dissent to the WG list during the IETF meeting week.  No other
snego-related comments were indicated in the session. Follow-up
discussion is underway on the mailing list.

FTP AND DSA, KEA/SKIPJACK

William Nace (NSA) presented a pair of recently-distributed documents,
concerning, respectively, FTP with DSA
(draft-ietf-cat-ftpdsaauth-00-txt), and FTP with KEA/Skipjack
algorithms (draft-ietf-cat-ftpkeaskj-00.txt).  Other contributors
include Peter Yee and Russ Housley.  Given the status of KEA/Skipjack
(currently classified), the document authors are targeting this
document for informational status. Discussion within the session
suggested informational status for the DSA document as well, but
(given the fact of unconstrained DSA specification) the DSA document
could be admissible for subsequent standards-track consideration by
the WG.  Approximately three attendees indicated familiarity with the
drafts; a concern was indicated that the algorithms applied may
constitute national-level solutions.

The DSA draft provides FIPS-196 authentication for FTP.  Unilateral
DSA signature-based authentication was discussed in the session,
though support for both unilateral and mutual cases is defined
within the specification. The KEA/Skipjack draft
provides confidentiality for both the data and command streams; labels
are also implemented.  Encrypted data are base-64 encoded.

KERBEROS PK-INIT AND PK-CROSS

Brian Tung (ISI) presented and discussed the recently-revised
kerberos-pk-init and kerberos-pk-cross drafts. Brian noted that
Kerberos open issues are being identified at
http://gost.isi.edu/info/kerberos.

KERBEROS PK-INIT AND PK-CROSS: PK-INIT

Approximately 4 attendees indicated they had read pk-init-04;
approximately 15 were familiar with one or more pk-init versions.
Document contributors include Ari Medvinsky and Matt Hur (CyberSafe),
Jon Trostle (Novell), Brian Tung and Cliff Neuman (ISI), and John Wray
(Digital). In draft-ietf-cat-kerberos-pk-init-04, a convention was
added for translating between X.500 and Kerberos names.  Mike Swift
(Microsoft) questioned why base-64 encoding was applied in name
translation rather than using the new name type being defined in
1510bis.  Ted Ts'o (MIT) observed that the base-64 approach avoids the
need to recognize X.500 semantics within Kerberos.

In pk-init-04, a client's realm comes from a certificate, not a KDC.
A client's principal name also comes from a certificate.  A KDC's
principal name was added as an X.509 v3 attribute.  Diffie-Hellman
specification was imported from PKCS #3, specification was added for
checksummed encryption, and more specific errors were defined.

Support within pk-init for SPEKE, an algorithm with which
approximately 3 attendees indicated familarity, had been proposed on
the mailing list. Ted Ts'o believed that SPEKE was patent-pending, but
terms were unknown; Cliff Neuman believed that patent or
patent-pending status should not be a bar to consideration as long as
an algorithm's implementation is not mandatory for conformance with
the specification.  Brian Tung is to continue discussion of SPEKE on
the mailing list.

Mike Swift observed that Microsoft's CAPI supports PKCS formats rather
than bare-level public-key encryption, and would like to be able to
support pk-init functions with PKCS-level objects.  Ted Ts'o agreed
that this suggestion appeared reasonable, noting the broad existing
base of code supporting PKCS formats. Brian Tung will raise this issue
to the list for further discussion.  A suggestion was made that use of
X.509 AltSubjectName be considered.

KERBEROS PK-INIT AND PK-CROSS: PK-CROSS

Brian Tung described draft-ietf-cat-kerberos-pk-cross-02 as including
minor changes relative to its predecessor.  Approximately 2 attendees
indicated that they had read pk-cross-02; approximately 7 indicated
familiarity with one or more pk-cross revisions.  In pk-cross-02, the
remote realm now determines the lifetime of a shared key.  Matt Hur
has suggested using pk-init to do pk-cross, which would be a major
change.  Mike Swift noted that Microsoft was evaluating usage of DNS
as a means to locate KDCs; this was considered to be a form of
existing practice which may warrant codification in RFC1510bis.  Mike
Swift also reiterated his recommendation, as made relevant to pk-init,
to allow public-key operations to be performed using PKCS objects.

KERBEROS-REVISIONS (RFC1510BIS)

Cliff Neuman (ISI) discussed status and issues relative to the
Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00.
Approximately 4 attendees indicated that they had reviewed this draft.
Changes and issues had previously been summarized to the CAT list.  It
was noted in discussion that the currently pending issues list
includes the addition of key derivation procedures for 3DES support.

Document-related comments were solicited, to krb-protocol@mit.edu for
protocol-related issues and via http://gost.isi.edu/info/kerberos (as
also used for pk-init, pk-cross, and pktapp).  An HTML/SGML version is
in progress, targeted for completion by 1 September; its content will
correspond to a new I-D (kerberos-revisions-01) to be submitted.  As
revisions of the HTML versions proceed, corresponding I-Ds will also
be issued and will remain authoritative.

Major changes considered since the kerberos-revisions-00 I-D, and
discussed at the session, are:

- Authorization data field: Elements are of type AuthorizationData
(new terminology). New element types include: kdc-issued (checksummed
with application server's key, vouched for by the KDC of that
application server's realm), intended-for-server and
intended-for-application-class (identifying targets or sets thereof
for which a ticket is intended), if-relevant, and Boolean combinations
of authorization elements ("or" is currently proposed; "and" was
considered appropriate as well).

If a kdc-issued element occurs in an inter-realm environment, a
receiving KDC reads and (if acceptable) reissues the element; it is
not passed through without reissuance and, were a passed-through
element to occur, that element would be ignored.  Each of the
intended-for-server, intended-for-application-class, and if-relevant
attribute types carries a sequence of elements. If intended-for-server
or intended-for-application-class attributes are not understood at a
targeted recipient, their enclosing ticket is to be rejected; if
received elsewhere, they may be ignored. If if-relevant attributes are
not understood at a targeted recipient, they may be ignored. In the
interests of simplicity, and without perceived loss of needed
function, it was agreed in discussion that kdc-issued should be
limited to appear at the top nesting level only, and should not nest
recursively.

Backwards compatibility with existing code incapable of recognizing
these newly-defined elements was considered important; Cliff Neuman is
to propose text to the mailing list discussing the circumstances under
which these elements should be included.  One suggestion was that they
be included at the level of a ticket element.

- Extensions field to ticket: This is an optional sequence, allowing
additional data to be linked to the ticket so that it follows the
ticket throughout the system.  It is located in a ticket's cleartext
portion at the end of the ticket, is typed opaque, is linked from
within the authorization data field, and contains a flag as to whether
it is OK to be removed.  It can be used for PK-CROSS to distribute the
inter-realm key, or can be used to distribute authorization data which
is integrity protected but not confidential, plaintext ticket data, or
accompanying authorization credentials.  Placement of the extensions
field in the ticket's cleartext portion allows unnecessary encryption
of ancillary data to be avoided.

- Optional client version in pre-auth: This identifies the version of
kinit, in a manner considered analogous to an HTTP version string. The
intended concept is to use this for backwards compatibility when
changes are made.  These numbers are not registered and vendor
dependent; vendors or users of this field are admonished to pick
version identifiers unlikely to conflict with those of other vendors.
No corresponding server version identfier is provided, so as not to
advertise known and exploitable bugs.

RFC2078BIS, RFC1964 ISSUES

John Linn led discussion on some specific issues related to RFC2078bis
and RFC1964.

Specific items cited:

Re sequence number setup in RFC1964, John Wray's working proposal for
the context acceptor to use the initiator's ISN in the single-hop case
was accepted (recognizing that a separate reflection indicator is
included in the protocol).

Re gss_display_status and CONTINUE_NEEDED: some clarification was
desired as to whether these can be used together or not.  Some
existing implementations return CONTINUE_NEEDED when iterating through
successive messages returned from gss_display_status, but this had not
been contemplated in RFC-2078.  The sense of the discussion was that
CONTINUE_NEEDED should be returned only by gss_init_sec_context and
gss_accept_sec_context; this intent (along with commentary on the
residual portability issue) should be cited in RFC-2078bis and
defensive callers should ignore CONTINUE_NEEDED if returned by calls
other than gss_init_sec_context and gss_accept_sec_context.

If a name of the type GSS_C_NT_EXPORT_NAME is imported with an
unrecognized mechanism (OID) in the framing defined by Section 3.2,
GSS_S_BAD_MECH is to be returned."

RFC-2078 contains MIT arc OIDs for some, but not all, of the generic
name types; this was considered benign and the sense of the discussion
was to retain these OIDs to avoid backward compatibility issues.  For
the case of host-based service, where an IANA arc OID had been
assigned for use in preference to its predecessor MIT arc OID, it was
recommended that both OIDs be accepted with equivalent effect but that
the MIT arc OID be emitted on output; the sense of discussion was to
reverse the prior recommendation preferring the IANA arc OID over the
MIT arc OID representing the same type, in order to avoid backward
compatibility issues with existing implementations. 

RFC-2078bis needs (per discussion re snego) to add facilities for
informatory conf_req, integ_req inputs to gss_init_sec_context.

The conjunction of supplementary info bits and non-zero routine errors
was discussed briefly. The goal is to tighten up the list of possible
cases.  This topic was deferred to discussion on the list.

RFC1964 EXTENSIONS

Mike Swift solicited interest in two possible areas of extension to
RFC-1964, user-user authentication and initial authentication via a
dial-up access server.

Mike noted that user-user authentication would be useful for DCOM, and
suggested support for Kerberos user-user authentication as a
submechanism within RFC-1964.  Marc Horowitz believed that it would be
more appropriately supported as a separate mechanism with its own OID;
snego could be used to select between RFC-1964 Kerberos and a
user-user mechanism.  Generic resolution of name discovery for the
user-user environment was believed to be a difficult issue, but there
appeared to be interest in investigating and potentially drafting a
specification for user-user authentication support.

Mike also solicited interest in specification of initial
authentication via a dial-up server (as in pktapp), where an initial
request is forwarded through an access server.  Ted Ts'o commented
that Derek Atkins' Charon thesis had addressed essentially this
problem some years previously.

OTHER DISCUSSION

Bengt Ackzell (Generic Systems) noted that, per the Memphis CAT
minutes, IDUP had been planned for placement into WG Last Call
following the Munich meeting if no comments were pending.  Recent IDUP
on-list discussion has been quiet, the base specification has not been
recently revised, and issuance of corresponding C bindings remains
pending.  Upon further review, it appeared that further revision or
on-list discussion of pending comments was needed before proceeding.

--jl