DRAFT minutes for Dallas CAT meetings

[John Linn <[e-mail]>]

CAT fanciers:

Attached are draft minutes for the Dallas meetings.  If changes or
corrections are needed, please post them to the list NLT this
Wednesday, 20 December so that I can reflect them in a revised version
to be sent to the IETF secretariat before this week's upcoming
submission deadline and holidays.  Thanks, regards, ...

--jl

COMMON AUTHENTICATION TECHNOLOGY (CAT) WG MEETINGS, DALLAS IETF:

SUMMARY

The CAT WG met for two sessions in Dallas.  Presentations included
talks on the SESAME GSS-API mechanism, the Kerberos Single-Use
Authentication Mechanism (SAM) draft, Kerberos Public-Key Extensions,
IDUP, Simple Authentication and Session Layer (SASL), authorization
and delegation control extensions (xgssapi), and GSS-API/Web
integration (a work item within the WTS WG). Other discussion topics
included pending issues on GSS-V2; all known pending issues were
closed or triggered action items, and an additional Internet-Draft
version is planned for January as a basis for advancement to Proposed
Standard.  Following active business on Internet-Drafts, a brief
summary of Microsoft's adaptation of GSS-API for Windows NT was
presented.

WORKING DOCUMENTS AND NEXT STEPS

RFCs 1508, 1509 (GSS-API, C Bindings): Proposed Standards. GSS-V2
Internet Drafts prepared (draft-ietf-cat-gssv2-04.txt,
draft-ietf-cat-gssv2-cbind-01.txt). Targeting new high-level
Internet-Draft as basis for advancement to Proposed Standard.

RFC 1510 (Kerberos): Proposed Standard. Pending minor revision as I-D
before advancement to Draft Standard.

I-D draft-ietf-cat-kerb5gss-03.txt (Kerberos GSS-API
mechanism). Internet-Draft revision planned before considering
advancement to Proposed.

I-D draft-ietf-cat-kerberos-pk-init-00.txt (Kerberos Public-Key
Initial Authentication). Internet-Draft revision planned
before considering advancement to Proposed.

I-D draft-ietf-cat-kerberos-passwords-02.txt (Kerberos Single-Use
Authentication Mechanisms). Internet-Draft revision planned before
considering advancement to Proposed.

I-D draft-ietf-cat-wingss-00.txt (GSS-API V1 MS Windows DLL
interface). 32-bit Internet-Draft revision pending.

I-D draft-ietf-cat-ftpsec-08.txt (FTP security). Internet-Draft
revision with state diagram pending. 

I-D draft-ietf-cat-snego-00.txt (GSS-API Negotiated Mechanism).

I-D draft-ietf-cat-spkmgss-04.txt (SPKM). This document was placed
into IETF last call during the summer; some IESG technical comments
are pending.  The document had been recommended by the IESG in August
for Experimental status per RFC-1602 Intellectual Property Rights
(IPR) issues related to use of the RSA algorithm; given the recent
fact of RSA's publishing a public statement of license terms, it is
currently expected that the SPKM document will be reconsidered and
advanced to Proposed Standard.

I-Ds draft-ietf-cat-idup-gss-02.txt, draft-ietf-cat-idup-cbind- 01.txt
(IDUP and C bindings).  New, revised high-level I-D became available
after the meeting.

I-D draft-ietf-cat-pim-00.txt (PEM-based IDUP mechanism).

I-D draft-ietf-cat-sesamemech-00.txt (SESAME GSS-API mechanism). Newly
presented at meeting.

I-D draft-ietf-cat-xgssapi-acc-cntrl-00.txt (Authorization/Delegation
extensions). Newly presented at meeting.

REFERENCE IMPLEMENTATION STATUS

In addition to status of active drafts, status of available reference
code was discussed.  Reference code is currently available for
Kerberos and for the Kerberos GSS-API mechanism (per GSS-V1); a
partial GSS-V2 Kerberos mechanism implementation (including context
import/export and credential support extensions, and based on the -02
or -03 version of the GSS-V2 document) has been developed at MIT and
is available as a snapshot.  Reference code is planned to be available
shortly (January 1996) for the SESAME mechanism and early in 1996 for
the SPKM mechanism.  No reference implementations are currently
available for the GSS-API Negotiated Mechanism, for IDUP, PIM, or for
the xgssapi authorization and delegation extensions.

Reference code currently exists for Kerberos Public-Key Initial
Authentication but revisions are planned as a result of issues being
discussed.  No reference code is currently available for Kerberos SAM,
but it will be developed and made available subsequently.  Cygnus has
developed an implementation of FTP security which will be incorporated
into a subsequent MIT Kerberos distribution; another FTP security
implementation (based on Kerberos V4) has been done at CMU and can be
located on http://andrew2.andrew.cmu.edu/dist.

SESAME GSS-API MECHANISM 

Stephen Farrell (Software and Systems Engineering, Ltd.,
[e-mail]) presented this draft
(draft-ietf-cat-sesamemech-00.txt) and discussion.  An overall goal of
Project SESAME is ease of cross-platform administration; it was noted
that porting has been carried out to a large range of platform
environments.  Privilege Attribute Certificates (PACs) are carried in
GSS-API context establishment tokens.  Within context acceptor
systems, a target access enforcement function is distinguished and
implemented (on UNIX platforms) by a separate daemon. Three key
distribution schemes are supported: (1) intra-domain using Kerberos
per RFC-1510 and capable of supporting RFC-1510 clients, (2)
inter-domain with modified Kerberos, (3) asymmetric keying using SPKM
technology but not strictly interoperable with SPKM endpoints.

Context token contents include (non-exhaustive list): PAC, target key
block, dialogue key package (dialogue keys being formed by key
offsetting from a context's session key), context identifier.  PAC
contents include PAC id, validity specifiers, miscellaneous
attributes, privileges, PAC protection mechanisms, a crypto check
value, Primary Principal ID (PPID), Control Value/Protection Value
(CV/PV), target qualifier attributes, delegation qualifier attributes.
A PAC's protection value is a one-way function of its control
value. PACs may be protected using multiple methods, and accepted if
any of those methods can be successfully validated by a target
recipient.  An Application Trust Group (ATG) is a named group of
applications which are equivalently trusted.

Reference code will be available within about a month, probably from
an ftp site in Belgium.  Stephen will post a pointer when it becomes
available, as well as a citation to a Web site with further
information.

BASE GSS-API-V2 DISCUSSION 

(draft-ietf-cat-gssv2-04.txt, draft-ietf-cat-gssv2-cbind-01.txt).

GSS-V2 issues pending and discussed:

(P1) Adjust discussion of canonicalized name routines to match
state-of-list once converged. The issue had been summarized by Martin
Rex as follows:

"The list hasn't reached consensus on re-importability of the flat
binary name produced by gss_export_name() (i.e.  write-only ACLs). The
necessary provisions for re-importability would be either a default
name type for the flat binary representation, or the addition of
another argument that returns the required nametype. (I assume that
re- import should be done via gss_import_name(), which wants that
gss_name_t.) If consensus on re-importability can not be achieved,
then the lack of re-importability should be documented."

Reimportability engendered some controversy, but its value was
recognized.  As a result, the working proposal from discussion at the
meeting (subject, like other meeting discussion, to reconsideration on
the mailing list) was as follows: The output of GSS_Export_name() is
to be reimportable by GSS_Import_name(). Each GSS-V2 mechanism
specification should define the format of the object which
GSS_Export_name() produces for that mechanism, said object to be
self-describing and to include the mechanism's OID internally for
tagging purposes. Ted Ts'o offered to propose a candidate format to
the list.  For some mechanisms, it may be appropriate for the format
to be extensible to include data items other than names (e.g.,
privileges).

(P2) Treatment of multiply-imported context tokens.  CONCLUSION: Don't
impose strict requirement that conformant GSS implementations must
detect attempts to import a given context token more than once, but
permit GSS implementations to return an error if they detect and
reject an attempted multiple import. Portable applications must not
assume that multiply-importable tokens are supported.

(P3) Closure on what, if any, specific proposal for a MIC token analog
to GSS_Wrap_size_limit() should be included. CONCLUSION: Bill
Sommerfeld will reinitiate this discussion on the list.  If the result
converges by the end of December, it will be included in GSS-V2.

(P4) Are we promoting name types (e.g., USERNAME) other than
host-based service to GSS level?  CONCLUSION: The
mechanism-independent forms will be promoted to GSS level.

(P5) Need to acquire/insert IANA OID assignments for anonymous and
host-based service name types.  (Note: (P4) will imply the need to
broaden this list.)

(P6) Per Raj Srinivasan, 1 November: return of confidentiality QOP
bits by GSS_GetMIC(), GSS_VerifyMIC(), functions which never provide a
confidentiality service. CONCLUSION: Revise text to state that
implementations of these routines should not return non-zero values in
confidentiality QOP fields.

(P7) Per John Myers: for protocol elements in host-based service
names, should the existing IANA Protocols and Service Names registry
be used or should another registry be established?  Complexities
related to this issue include: Kerberos's use of the "host" principal
to accept contexts for a number of protocols, and usage of a single
principal to correspond to multiple versions of a service protocol
(e.g., "pop" vs. "pop3").  CONCLUSION: A new, case-sensitive IANA
registry appears to be needed; John Myers drafted text after the
meeting for review on the list as justification to be presented to the
IANA.

(P8) Per John Wray, 13 October, should align high-level spec and C
bindings re described printable format for OID representations.
CONCLUSION: Adopt within the high-level spec John's proposal as
currently included in the C bindings, to use the numeric ASN.1 syntax
format (curly- brace enclosed, space-delimited, as in "{2 16 840 1
113687 1 2 1}").

(P9) Per list discussion 12-18 October, will revise context token
wrapper syntax in GSS-V2 spec so that the actual octets, not the
ASN.1, are definitional.

Per meeting discussion, words will be added to the GSS-V2 spec about
presentation of an invalid token for a context not disrupting the
context's state.  Another issue: is it possible to make subsequent
calls on a context after, e.g., a memory failure?  Desirably, it
should at least be possible to delete the context.  While particulars
in this area are probably mechanism or implementation specific, it
would be useful to recommend that failures don't result in allocating
memory (with attendant risk of memory leakage).  Proposed text,
communicating the general message, "even after error, can continue
making calls on context", will be posted to the list for discussion
and intended inclusion in the top-level GSS-V2 draft.

Ted Ts'o raised a point re the GSS-V2 C bindings: there's a 32-bit
assumption which needs to be rechecked (GSS_C_INDEFINITE).

Simon Cooper (SGI) raised a set of issues which he saw as relevant to
GSS-API usage in Web environments.  He asked whether it was possible
for contexts to be cached for use over UDP; this can be done but is
not a facility guaranteed for all mechanisms.  Simon also indicated a
desire to be able to bind context identification to tokens, e.g., in
framing material.  This is analogous to the facility provided by
SPKM_Parse_token.  Parse_token is, however, hard to implement for some
mechanisms which don't maintain linked list of contexts, and had
previously been excluded from the GSS-V2 specification partly because
of this fact.  In addition to these functions and other GSS-V2
features, an ability to control emitted token size was requested.
Concern was also raised about flushing of inactive contexts.

KERBEROS SINGLE-USE AUTHENTICATION MECHANISMS

(draft-ietf-cat-kerberos-passwords-02.txt) (C. Neuman/G. Zorn)

Glen Zorn (CyberSAFE) led discussion on this Internet-Draft, renamed
from Kerberos One-Time Passwords.  A facility has been added to this
version for transport of public-key information, and code
corresponding to the SAM spec is planned for inclusion in Kerberos V5
beta 6.  Glen noted that he and Cliff Neuman consider the SAM spec to
be solid at this point and that its public-key hooks will be
sufficient, although the Kerberos public-key specification has not yet
stabilized.

Glen indicated a desire to reach consensus on SAM at the meeting or
shortly thereafter.  Denis Pinkas (Bull) indicated a concern that
specifications should not presume comprehensive multi-method support
when a particular method is dominant in the design.  Denis also
disagreed with the spec's recommendation re Kerberos password entry;
he wishes to support a 10-character passphrase as recommended in the
OTP WG.  Glen noted that SAM's OTPZ-mode operation can be supported
without a Kerberos password, but SAM's base OTP mode requires the
Kerberos password.  John Linn requested clarification as to whether a
client may or may not continue a SAM exchange with a different KDC
than that with which the exchange was initiated.

Denis, Cliff, and Glen reported at the second CAT session that they
had had follow-up discussion re SAM following the presentation, and
that they will investigate a generic way to accomodate Denis'
requirements in another version of the spec.

KERBEROS PUBLIC-KEY EXTENSIONS

(draft-ietf-cat-kerberos-pk-init-00.txt, expired) (C. Neuman)

Cliff Neuman led discussion on the Kerberos public-key extensions
Internet-Draft, on which related work is underway at ISI (with
information available on http://nii.isi.edu/info/Kerberos).  The
current code uses PGP; it is hoped that a version can be integrated
into the next MIT Kerberos release.  A revised Internet-Draft is
planned for January 1996, given resolution of issues under discussion.

One issue discussed was the certificate format(s) to be used to
certify the KDC.  A proposed approach was to use X.509V3, with a
request to be made to the PKIX WG to specify a name type to represent
a Kerberos principal name as an X.509V3 private type.  Alternatively,
the KDC may be certified within any of the infrastructures through
which the users it serves are validated.

Ted Ts'o asked for clarification of the requirements being addressed.
The presumed goal is to achieve single login, using Kerberos as
appropriate, within an environment where users are registered in a
public key infrastructure.

Another issue was whether or not certifiers of KDCs should be
indicated in the Kerberos transited realms field.  It was asserted
that such information might be too complex to be useful to most
targets, and that avoidance of such complexity was one reason why name
subordination has been used within certification infrastructures.
Another issue: Should a private key-based exchange, like that in SPX's
LEAF, be supported?

Denis Pinkas reiterated a request for changes in the interests of
export, so that a user need not apply a high-strength private key for
encryption (vs. signature); Cliff Neuman commented that this would
require invasive Kerberos changes beyond the scope of
preauthentication, but Denis observed that this goal could be
satisfied if session key generation were performed by users.

RFC-1510 REVISIONS

Cliff Neuman commented about the status of the RFC-1510 update.  The
revision has new checksum identifiers and preauthentication codes,
includes means for notifying clients re the set of methods supported
by servers, and is slated for mid-January.

INDEPENDENT DATA UNIT PROTECTION (IDUP)

Discussion of revised IDUP drafts (draft-ietf-cat-idup-gss-02.txt,
draft-ietf-cat-idup-cbind-01.txt, and
draft-ietf-cat-pim-00.txt). (C. Adams, D. Grebovich).

Carlisle Adams (BNR) presented discussion on an idup-gss-03 update,
which was in transit and reached the I-D directories after the
meeting.  He commented that the new version includes sweeping changes
in call structure, changing parameters, removing "evidence" calls, and
adding capabilities for encapsulation and single-call processing of a
self-contained message.  Carlisle asserted that the structure is now
much more general, and should simplify future inclusion of new
services.  Discussion on idup-gss-03 was eagerly solicited; to this
point, relatively little E-mail debate has taken place on the IDUP
documents. 

Parameter bundles are a notational convenience to simplify
presentation of calls in the spec and to simplify application use of
the calls (e.g., via convenient defaulting).  Some bundles have
mechanism-defined structure and are opaque to callers, but others have
defined, application-parseable structure. Bundles can contain both
input and output elements, and can can be nested within other bundles.
All services use General_Service_Data bundle, some also use others,
e.g. Target_Info.

The new IDUP version removes the distinction between "protection" and
"evidence", returning to a generalized concept of "protection".  Three
types of protection and unprotection operations are defined:
unsolicited services, solicited services, solicitation of a service.
There are 10 IDUP-defined services, identified by OIDs.  "Unsolicited"
refers to a local request, "Solicited" to action triggered by
remotely-received token.  An originator, e.g., performs unsolicited
encrypt and sign operations, soliciting a receipt from a target.  To
process a received token, unprotect is called once for token parsing
(omittable if needed data can be otherwise determined), and a second
call performs the actual validation.  Suggestion at meeting: use
message hash as hint to identify messages corresponding to signatures.

Carlisle believes that the document should now be stable, and said
that the C bindings and PIM are being aligned and will be submitted in
January or February.  Denis Pinkas noted related work: the Object
Management Group (OMG) has issued an RFT for object-oriented
non-repudiation technology (addressing just evidence processing, not
other services), with submissions to be provided 18 December and
reviewed by January; work is in progress to align this submission with
Carlisle's work.

John Myers asked why the IDUP work was taking place in the IETF, given
the fact of pre-existing store-and-forward messaging security
protocols, and questioned the value of an API-based approach in a
non-interactive, non-negotiating protocol environment. Several
attendees saw value in IDUP, and commented that the justification for
IDUP is closely analogous to the justification for base GSS.  It was
also noted that GSS-API existed and was applied in interactive
environments before the negotiated mechanism approach was proposed.

SIMPLE AUTHENTICATION AND SESSION LAYER (SASL) 

(draft-myers-auth-sasl-00.txt) (J. Myers)

John Myers (CMU) presented a discussion on SASL, a framework for
adding security into protocols.  Generalized from IMAP, SASL is a
small layer which is recommended for layering over GSS-API, also
supporting Kerberos V4 and S/KEY (OTP) and encoding bits indicating
protection service availability.  SASL's use is currently specified
for POP, IMAP, and John has implemented it with Kerberos V4; it is
being considered for the next LDAP revision and by an ad-hoc non-IETF
LPR-ng (printing protocol - next generation) group. Issues: registries
to be used for service names and SASL mechanism names.  John wants to
issue a new draft, and then go to last call.

GSS-API/WEB INTEGRATION 

(draft-ietf-wts-gssapi-00.txt) (D. Rosenthal)

Doug Rosenthal ([e-mail]) gave a presentation on a
proposed approach for GSS/Web integration.  Although this presentation
was given to the CAT WG for informational purposes, the draft is a
work item of the Web Transaction Security (WTS) WG and any decision on
its potential advancement will be made within the WTS WG.

Doug noted that the proposal's objectives were to meet WTS WG
requirements, to leverage existing IETF security work, to support a
variety of security technologies, and to enable API sharing between
Web and non-Web secure applications.  As described, the proposal
defines a new URL type, establishes a security context per Web
transaction, encapsulates HTTP, and can be used to support access
control enforcement.  Informal testing didn't show major performance
problems from context setup, Doug reported, but quantitative values
have not been presented and would be valuable. No context caching is
currently performed above the mechanism level, but this could be
considered as a future optimization. An IANA service port has been
assigned, and WinWeb and MacWeb browsers have been integrated with
PK-based (SPKM) GSS toolkit.  Doug's plans include deployment with a
commercial CA service to gain experience and evolve the specification.

It was reported that a concern had been raised at the WTS meeting about
the feasibility of API usage, given the fact of multi-language Web
development environments.  John Myers observed that the proposal
appears to duplicate SASL work, which could potentially replace it.

GSS-API AUTHORIZATION AND DELEGATION EXTENSIONS

(draft-ietf-cat-xgssapi-acc-cntrl-00.txt) (D. Pinkas/T. Parker)

Denis Pinkas (Bull) presented a discussion on a proposed set
authorization/delegation extensions, called XGSS-APIs.  These
extensions, based on an X/Open snapshot document, provide support for
exchanging attributes, constructing related authorization functions,
and for providing delegation controls.  They extend GSS to allow
authorization based on attributes beyond just username; as in DCE,
groups are accomodated.  An audit identity, explicitly not to be used
for authorization decisions, is supported.

An xgssapi security attribute contains attributeType,
definingAuthority, and securityValue (with interpretation qualified by
type).  Attributes are divided into principal attributes, privilege
attributes, qualifier attributes, and miscellaneous attributes.  There
are attribute handling support functions (GSS_Set_cred_attributes,
GSS_Get_sec_attributes), an acceptor support function
(GSS_Get_received_creds), and acceptor control functions
(GSS_Set_cred_controls, GSS_Get_sec_controls, GSS_Compound_creds).
Denis noted that the proposed extensions assume a push model of
privileges, and cited a goal to migrate to support for role-based
authorization decisions.

John Myers perceived the proposal as complex from an applications
programmer's viewpoint; he expects to write his own authorization
service but would like to receive groups as well as the individual
entity names which GSS-API now provides, and would be satisfied to
receive the groups as (separately-typed) elements of a set of names
associated with a context.  Glen Zorn also observed that the proposal
appeared complex and suggested its division into different documents:
a framework, separated C bindings, and a worked instantiation within a
mechanism.  Concerns were raised about the extent to which the
proposal could be implemented in multiple mechanisms; Denis commented
that DCE could support some of the described functions. Ted Ts'o asked
whether attribute extensions were intended to be portable across
supporting mechanisms.  Generally, it was considered that
cross-mechanism attribute definition for a core set of attributes is
highly desirable.

MICROSOFT GSS-RELATED INTERFACE

Following discussion of Internet-Drafts, Richard Ward
([e-mail]) presented a brief summary on ongoing
GSS-related work at Microsoft.

A "Windows-ized" GSS-V1 implementation is incorporated in Windows NT
3.5.1.  Its interface specification ("Security Support Provider
Interface") is not currently on-line, but hardcopies were provided at
the meeting and the document is available on request to Richard,
within the Win32 SDK, and/or via a to-be-provided FTP pointer.  A
primary goal motivating changes was to to provide stream support,
enabling use of the interface to support caller protocols like SSL and
PCT which define their own record blocking. Richard encouraged the
GSS-compatible connection-oriented usage mode for future applications,
but was constrained to satisfy this compatibility requirement.  The
Microsoft implementation has an additional descriptor in buffers,
which allows continuation buffers to be represented and processed.
Although a particular caller may require the use of a specific
compatible provider mechanism (for compatibility with the caller's
protocol format specification), such a provider can also be reused by
other callers which do not constrain the structure of their GSS
tokens.

Richard intends to prepare an Internet-Draft describing the extensions
and changes to GSS-V2 which the Microsoft interface embodies.