Common Authentication Technology (CAT) WG minutes, DC IETF, 8-9 December
1997, recorded by John Linn, RSA Laboratories.

Summary

The CAT WG met for 1.5 sessions (one full-length and one short slot) at
the DC IETF. A large number of Internet-Drafts were presented and
discussed. The WG believes that the final remaining issue with SPNEGO
(Simple Protected Negotiation) has now been closed; following specific
changes, this draft will be submitted to the IESG to be considered for
advancement to Proposed Standard.  A WG Last-Call on GSS-IDUP had been
recently completed; following review of the most recent draft (which
became available on the Internet-Drafts repositories only on the Friday
before the IETF) for consistency with Last-Call discussion, it is
expected that a subsequent update will be prepared and similarly
submitted to the IESG. A number of RFC2078bis issues were discussed; an
update (hopefully final) to this draft is planned on/about late January;
in conjunction, minor revisions to the GSS C bindings draft are being
discussed. A WG Last-Call is planned on
draft-ietf-cat-ftpdsaauth-00.txt; draft-ietf-cat-ftpkeasj-00.txt is
intended for Informational status. Discussion and review was resolicited
on the xgssapi-acc-cntrl draft. 

Several Internet-Drafts related to Kerberos technology were discussed.
The base Kerberos document (RFC1510bis) is to be revised in January, and
the result is anticipated to be a final version; updates to pk-init and
pk-cross drafts are also planned in response to discussion. A draft
presented on Kerberos anonymous credentials is intended to provide
tutorial information, to be applied in conjunction with RFC1510bis;
another presented draft provides informational discussion on Kerberos
usage with firewalls. Separate drafts on error message processing, usage
with TCP, and usage with IPV6 are being subsumed within RFC1510bis.
Password change and pktapp drafts are to be reissued; updates are also
pending to initial authentication (iakerb) and user-to-user (user2user)
drafts.

SPNEGO

Denis Pinkas (Bull), SPNEGO document editor, summarized SPNEGO as having
evolved to being Protected and More Complex.  It was believed that
exactly one issue remained to be closed: inclusion of mechListMIC in
negTokenInit, and whether such inclusion would be mandatory or optional.
In the week prior to the meeting, Denis had proposed (in the SPNEGO
document's optional API annex) inclusion of a control flag directing
whether or not transfer of a MIC to the target was requested. Mike Swift
(Microsoft) recommended that SPNEGO should support the sending of a MIC
on the last message in an exchange which contains an odd number of
messages; Marc Horowitz (Cygnus) agreed, also noting that "single
message negotiation" is intrinsically contradictory.  It was agreed that
all SPNEGO-based context establishment sequences would require at least
two messages.  Mike Swift observed that this would be sub-optimal for
the case of a server which always required SPNEGO but was capable of
accepting only one underlying mechanism (e.g., Kerberos); it was noted
that use of SPNEGO would add only limited value if only one negotiated
result was possible, but some consideration was given to the special
case of a single-token exchange.  

A proposed resolution and closure to the final issue was reported by
Marc Horowitz in the second WG session as follows, based on text which
Marc had written between the sessions and had discussed with Denis.  In
the proposal, an initiator's MIC can optionally be sent to an acceptor;
the acceptor sends a MIC if none was sent by the initiator.  Denis
suggested additional security considerations issue regarding mutual
authentication, which he intends to add to the draft.  Actions planned:
Marc's text will be sent to the list for review, and will be
incorporated into a new I-D for submission to the IESG with a
recommendation for advancement to Proposed Standard.

RFC2078bis/C bindings

Several points related to RFC2078bis and the C bindings were discussed.
A revision to RFC2078bis, hoped to be suitable for WG Last-Call, is
planned for late January.  On-list discussion may suggest a few
clarifying revisions to the C bindings.  Points discussed re RFC2078bis
were as follows:

The sense of attendees confirmed that GSS_Inquire_context() would be
aligned with the C bindings to add a result value indicating whether or
not a context was fully open.  Expired contexts are to be indicated with
a reserved "lifetime" value rather than by returning the fatal
CONTEXT_EXPIRED error. 

Attendees confirmed list discussion regarding the indication of
informational sequencing errors along with GSS_S_COMPLETE and
GSS_S_FAILURE major_status: consistent with the C bindings, 2078bis will
reflect that the sequencing error status codes may be indicated along
with either COMPLETE or FAILURE for per-message calls; while this is
syntactically possible for context establishment calls as well, return
of sequencing error status along with COMPLETE (or CONTINUE_NEEDED) will
remain semantically prohibited during the context establishment phase.

Regarding side effects, it was considered appropriate to state that
invocation of GSS-API calls incurs no side effects visible at the
GSS-API level (it being considered implausibly broad to rule out side
effects on other aspects of system behavior).

For GSS_Acquire_cred() and GSS_Add_cred(), GSS_S_NO_CRED, rather than
GSS_S_FAILURE as at present, is to be returned if an authorization
failure is encountered upon credential acquisition. This decision
reconciles previous inconsistent choices in the direction of informative
error reporting.

Per a recent suggestion on the mailing list, we considered the prospect
that the target_name input parameter to GSS_Init_sec_context() might be
made optional.  Mike Swift and Martin Rex (SAP) argued that this should
be permitted, since not all mechanisms require that a target name be
specified in order to authenticate an initiator to a target (and,
subsequently, to authenticate the accessed target to the initiator).
Ted Ts'o (MIT) observed that use of such a facility would be
non-portable to the set of mechanisms which do require a target name in
order to construct their tokens, and that its use by applications should
therefore be cautioned, but considered (albeit reluctantly) that it was
appropriate to allow the name to be optional.  The working proposal,
therefore (pending further list discussion), was to recommend that
mechanisms accept GSS_C_NO_NAME as an input target_name type.

Regarding the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials
with explicit names, it was considered that an explicit name as returned
from GSS_Inquire_context() should be acceptable as an input to
credential acquisition.  It is important to recognize that the explicit
name which is yielded by resolution of a reference to "default" may
change over time, e.g., as a result of local credential element
management operations outside GSS-API.

If an exported name object is imported with GSS_Import_name() and the
enclosed mechanism type is not recognized or unsupported, it was
considered (consistent with list discussion) that GSS_S_BAD_MECH should
be returned. 

Discussion at the session confirmed that RFC2078bis is to be aligned
with the C bindings by removing (rather than deprecating, as is
currently the case) GSS_S_CREDENTIALS_EXPIRED as a return value from
per-message protection, context_time, and inquire_context calls.

It was recognized that current GSS-API specifications do not prescribe
the error which should be returned if a reflected token (a token
received by the endpoint which generated it) is detected.  Many existing
mechanisms' protocols include provisions for detecting such tokens, and
it seems reasonable that a major_status code should be selected to
indicate this situation.  This topic is being discussed on the mailing
list. 

An additional RFC2078bis topic had been identified for discussion, but
was not considered within the time available and therefore remains
outstanding: should GSS_S_NO_CRED be returned by per-message calls if
credential elements are needed but unavailable in order to complete an
operation?

GSS-IDUP

Few attendees had been able to read the most recent draft, since it
emerged as an I-D only on the Friday before the meeting. One issue,
cited previously on the mailing list, was the question of whether or not
IDUP tokens should necessarily be wrapped with a mechanism tag in the
manner of GSS tokens.  Carlisle Adams (Entrust) believes that use of
unframed tokens is sufficient to enable interoperability between
IDUP-based and non-IDUP implementations of existing messaging security
protocols; Ted Ts'o observed that such interoperability would be a
desirable property.  Another IDUP draft version is anticipated,
reflecting reconciliation of issues raised during the WG Last-Call.

Kerberos Anoncred

Ari Medvinsky (Cybersafe), Kerberos/Anoncred: This is an informational
draft, related to PKINIT and the Kerberos-revisions draft, describing
use of optional flags in 1510bis. Its motivation: users may not be
registered with an authentication service, or may be registered and wish
to remain anonymous for a particular association, yet may still require
an encrypted channel to an end service.  Anonymity may be called for,
Ari observed, in some applications (e.g., E-commerce). 

Case 1: user not registered with authentication service: use
REQUEST-ANONYMOUS flag in AS_REQUEST along with PKINIT's Diffie-Hellman
option.  The KDC returns a ticket with the ANONYMOUS flag set and
session key protected via Diffie-Hellman. Case 2: registered user wishes
to remain anonymous; ANONYMOUS flag used in AS_REQUEST, but PKINIT
Diffie-Hellman option not needed. For either case, client's principal
name, as reflected in the ticket, is "anonymous@realm" or other name
based on KDC policy.  Discussion point: Is it, per Marc Horowitz's
suggestion, legitimate to make authorization decisions based on realm ID
within name? Cliff Neuman (ISI) thought that this might be appropriate,
but there was some controversy about this point, which was remanded to
list discussion. 

Kerberos Initial Authentication (IAKERB)

Mike Swift led discussion on the Initial Authentication with Kerberos
and GSS-API (IAKERB) draft. It addresses the problem that some Kerberos
clients (e.g., in dialup initial authentication scenarios, or in some
web server access cases) are unable to locate or contact a KDC, while
servers generally have good KDC connectivity. Initial credential
elements (e.g., passwords, private key for PKINIT) must be provided
through an extension.  The client sends framed KDC requests to server
via GSS-API, which the server forwards to the KDC; tickets and requests
don't have addresses, because the server is responsible for KDC
communication.

The primary issue considered was that of how IAKERB integrates with the
GSS-API Kerberos mechanism per RFC-1964. Ted Ts'o commented that a new
mechanism OID is needed in order to identify that an endpoint supports
IAKERB. Conceivably, IAKERB might be bundled with User-to-User (both of
which precede or encapsulate the scope of the existing Kerberos GSS-API
mechanism per RFC-1964), to comprise a successor version of the Kerberos
mechanism. Ted Ts'o expressed sentiment in favor of merging IAKERB into
the Kerberos mechanism, but was less sure about User-to-User.  Further
discussion about document relationship and structure was remanded to
list. A separate issue was identified: how are initial credentials
(principal name, password) established?

Kerberos User-to-User (U2U)

Mike Swift led discussion on the User-to-User Kerberos Authentication
using GSSAPI (U2U) draft. It addresses two limitations within the
current GSS Kerberos mechanism: that context establishment to servers
without accessible passwords (long term keys) cannot be supported, and
that a client must know the server's principal name in order to initiate
context establishment.  In the U2U proposal, an extra round trip
(bearing KERB-TGT-REQUEST and KERB-TGT-REPLY elements) is required in
order to carry the TGT request transaction.  RFC1510's ENC_TKT_IN_SKEY
option is used within the KDC request. The client may request a server's
principal name and realm. 

Denis Pinkas requested additional clarification and/or references
concerning the proposal's goals.  Two basic issues were raised: 

Should the ability for a client not to know a server's principal name in
order to initiate a security context be further generalized? Sentiment
appeared positive, consistent with discussion of GSS_C_NO_NAME input
target_name to GSS_Init_sec_context() as noted above re RFC2078bis.  For
the case of an initially unnamed target, mutual authentication's
semantics would confirm the target identity subsequently returned. 

What are the security risks of a server handing out its TGT?  The TGT is
already (independent of U2U) transported over the net; its availability
to requestors via U2U could make its access for password guessing
purposes more convenient, but does not expose information not already
transmitted.

Kerberos Public-Key Initial Authentication (PKINIT)

Brian Tung (ISI) led discussion on the Kerberos PKINIT draft.  Changes
in the most recent draft were relatively minor, including (among others)
X.500 name encoding and the addition of 2 new encryption types.  At the
Munich meeting, Mike Swift had introduced the recommendation that PKINIT
employ PKCS objects (subsequently clarified to PKCS#1 rather than
PKCS#7) in the interests of compatibility with existing code and
infrastructure. Brian's slide summary at the current meeting asserted
that a change to PKCS structures would potentially make messages large,
introduce unnecessary redundancy, and would introduce incompatibility
with existing work using the incumbent PKINIT format.  Decision was
deferred, partly pending consideration of impact of PKCS#1. 

Mike Swift also commented that the current document states that a
ticket's realm should be the CA's name, but asserted as a goal that an
application server shouldn't encounter different names for PKINIT
accessors than for non-PKINIT access.  This goal was agreed reasonable,
and is achievable through one of various possible means. Mike also noted
that existing means are available for putting RFC-822 names into
certificates (e.g., AltName, and/or "E=" convention) and suggested that
these should be applied.  

Denis Pinkas commented that the security considerations section should
refer to the possibility that a user's private key may have been
retrieved without user knowledge.  He also posed the prospect that
storage of an encrypted private key on a server may be subject to a
Digital Equipment Corporation patent; this question was not immediately
answerable and requires follow-up research. He also requested that
PKINIT be able to conformantly support user with only a signature-only
key; Brian responded that this could be achieved through subset
conformance, or through conformance to a separate protocol which could
be defined within the document for this purpose. 

Kerberos Public-Key Cross-Realm Authentication (PKCROSS)

Brian Tung led discussion on the Kerberos PKCROSS draft. It uses the
Kerberos Ticket-Extension field. The local KDC sends a PKINIT request to
a remote KDC, and the remote KDC sends back a PKINIT reply, accompanied
by a tag and policy information in the Ticket-Extension.  The local KDC
returns a ticket to the client, also including the TGT from local to
remote KDC within a Ticket-Extension. No Ticket-Extensions are ever
stripped.  Mike Swift noted that it seemed bulky to send a TGT just for
the purpose of transporting a session key, but it was observed that a
TGT transports policy and validity information as well; more rationale
discussion was desired in this area. Ted Ts'o commented that this
appeared to be an overloading reuse of the TGT object; Cliff Neuman
responded that usage as described was perhaps the fundamental use of a
ticket; this dispute was remanded to the list. It was also observed that
avoidance of KDC-KDC communications would be attractive.  

Kerberos Extensions  (RFC1510bis)

Cliff Neuman (ISI) led discussion on the Kerberos-revisions draft
(rfc1510bis).  Editing on this draft is being undertaken in html, and
the current version is accessible at
http://gost.isi.edu/people/bcn/draft-ietf-cat-kerberos-r-01.html; Cliff
considers this html version to be authoritative, and will generate an
Internet-Draft from it. He requests that open issues be posted on the
web page at ISI. 

IPV6 addressing will be included in 1510bis. Regarding support for
Kerberos over TCP, Cliff suggests that this be made mandatory as of the
next (-2) draft.  One issue: whether to include a 32-bit length
specifier in network byte order (Cliff's recommendation) or instead to
rely solely on ASN.1 length indicators.  Statements are also needed
about policies for closing outstanding TCP connections with the KDC; it
was recognized that the KDC must be free to break connections in order
to throttle denial-of-service attacks. 

Material from the previously separate key-derivation draft has been
incorporated.  Cliff noted that procedures as newly incorporated (and,
hence, for which no backwards compatibility issues apply) for 3DES
encryption do not conform to RFC1510's general structure template,
suggesting either that the changes be redefined to conform with the
template or that the assumption of template usage should be flushed.
Typed e-data was also considered: Munich meeting discussion had
suggested merits of typing the field to govern its interpretation. 

Regarding anonymous credentials support, fields and flags are defined in
1510bis, and such credentials can be obtained with or without public
key.  The public key acquisition method is defined in a separate I-D.
An anonymity-related issue was discussed, that of whether or not a
reserved "anonymous" principal name should be defined.  Cliff
recommended use of the name "anonymous@anonymous", which (if adopted)
would render the "anonymous principal" ticket flag moot and eligible to
be removed, though the corresponding request flag would remain. Mike
Swift commented that special treatment might need to be specified for
authorization data in conjunction with the anonymous principal case.
Cliff had noted before the meeting that auth time will be reset on
anonymous ticket generation in order to prevent "de-anonymization" by
correlation of ticket validity times.  Ted Ts'o observed, though, that
the presence of transport addresses and other fields can weaken the
quality of anonymity offered in any case. 

Regarding authorization data, several elements can now be represented,
including (among others): KDC-issued, external adata (integrity
protected but not confidentiality protected), and-or (now can achieve
both AND and OR conjunctions with an and-or, along with the number of
elements which must be matched to succeed). Mandatory extensions must be
preserved in order to maintain the validity of a ticket. A pksigned
element (suggested, but not now an included element) would provide a
facility to allow entities other than the KDC to sign with a private
key. Ticket extensions carry information to be moved along with the
ticket, in its plaintext part, such as: the external adata authorization
element, PKCROSS information, and a null extension (helpful in detecting
whether ticket extension fields are being stripped).

Cliff identified the following next steps for kerberos-revisions:
resolve open issues, fix 3DES specification, action on changes decided
at meeting, formatting cleanup, added references, and citations.  His
intent is to post a revised version in order to enable WG Last-Call in
advance of the LA IETF. 

A question was raised as to whether any incompatibility issues existed
between the specification and the DCE and/or MIT Kerberos
implementations relative to the string-to-key algorithm. Ted Ts'o
believes that MIT implements RFC-1510's string-to-key algorithm and was
unaware of any interoperability issues with it.  MIT's implementation
also has backwards compatibility provisions with string-to-key as
defined in Kerberos Version 4 and in AFS.  

Kerberos/IPV6, Kerberos/TCP, Kerberos/Firewalls

Assar Westerlund (SICS) led brief discussion on the Kerberos/TCP and
Kerberos/IPV6 drafts, whose scopes are being subsumed into 1510bis. The
TCP draft includes a 4 byte length specifier, as recommended (per prior
discussion) for 1510bis.  Regarding connection closing, it was noted
that some but not all implementations drop connections after a request
is processed, but that the KDC must be permitted to drop the connection
at any time.  Cliff will revisit 1510bis wording on this issue.

Assar then led discussion on the Kerberos/Firewalls draft; his goal for
this document is an informational RFC about making Kerberos work in
firewalled environments; Cliff endorsed placement of this material in a
separate document from 1510bis.  Some list discussion had taken place
about the draft's characterization of firewalls. Ted Ts'o asked for
clarification about the implementation impact imposed by the draft's
recommendations.  One point: use of proxies implies a desire to add an
extra set of addresses into tickets to correspond to the proxy (e.g., as
discovered by SOCKS); this is further complicated where multiple
gateways are involved.  Address checking can be disabled, but this
renders the usage of tickets more permissive.  A further revision to the
firewalls draft is planned per list discussion. 

FTPsec/DSA, FTPsec/KEA

Peter Yee (Spyrus) summarized the status of the FTPsec/DSA document: an
original draft had been submitted for the Munich IETF, and no
outstanding technical issues have been raised.  Alignment with RFC2228
is being verified, and an implementation exists (win16 client, SCO
server).  He considers the document ready for WG Last-Call. 

Concerning the FTP Encryption with Skipjack/KEA document, Peter is
targeting informational RFC status unless the algorithms it employs are
subsequently declassified.  Mike Swift asked what advantages this
approach offered relative to use of TLS, and Peter replied that this
approach allows pre-computation.

Status Summary on WG Internet-Drafts

We concluded the session with a summary of status and plans for CAT-WG
Internet-Drafts, based on a snapshot of the I-D directories as of the
week prior to the meeting:

draft-ietf-cat-ftpdsaauth-00.txt (07/21/97): WG Last-Call planned.

draft-ietf-cat-ftpkeasj-00.txt (07/21/97): Targeted for Informational
status, possibly to be revisited if algorithms declassified. 

draft-ietf-cat-gssv2-cbind-05.txt (11/24/97): minor update may be needed
in response to discussion.

draft-ietf-cat-iakerb-00.txt (11/05/97): update pending

draft-ietf-cat-idup-cbind-03.txt (04/16/97): not currently active

draft-ietf-cat-idup-gss-08.txt (10/14/97): minor update (-10 version) to
be upcoming in response to WG Last-Call discussion

draft-ietf-cat-kerb-chg-password-00.txt (03/10/97): different
implementations have reportedly interoperated; draft to be reissued

draft-ietf-cat-kerberos-anoncred-00.txt (09/22/97): to be released as
informational document along with rfc1510bis and PKINIT, on which it
depends

draft-ietf-cat-kerberos-err-msg-00.txt (03/26/97): obsolete: subsumed
into rfc1510bis

draft-ietf-cat-kerberos-pk-cross-03.txt (11/26/97): further discussion
and revision needed

draft-ietf-cat-kerberos-pk-init-05.txt (11/21/97): issues to be
discussed; intent for revision and WG Last-Call before LA IETF

draft-ietf-cat-kerberos-revisions-00.txt (07/14/97): intent for revision
in January as input to WG Last-Call

draft-ietf-cat-krb5-ipv6-00.txt (10/29/97): subsumed into 1510bis

draft-ietf-cat-krb5-tcp-00.txt (11/24/97): subsumed into 1510bis

draft-ietf-cat-pktapp-00.txt (02/17/97): to be revised and reissued; new
version depends on PKINIT and is intended to be informational

draft-ietf-cat-rfc2078bis-01.txt (11/13/97): intent for revision in
January, hopefully as input to WG Last-Call

draft-ietf-cat-snego-07.txt (11/18/97): final update to be made in
response to issue discussed at meeting, result to be reviewed and
forwarded to IESG

draft-ietf-cat-user2user-01.txt (12/01/97): update pending

draft-ietf-cat-xgssapi-acc-cntrl-02.txt (03/24/97): According to Denis
Pinkas, this approach currently supports DCE and SESAME; document
unchanged; review and discussion was resolicited.  It was stated in
discussion that the webdav WG is doing definitions of access control
APIs. 

John Linn (linn@rsa.com)
RSA Laboratories East, Bedford, MA, USA