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

Text File | 1996-06-03 | 24.9 KB | 492 lines

CURRENT MEETING REPORT


Minutes of the Common Authentication Technology Working Group
(cat)

Reported by John Linn, Open Vision

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
(posted on http://www.rsa.com), 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; this code
base will have some differences from the I--D specification, as
documented in an annex to the I--D.  Reference code is planned for 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, and (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, and 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.,
Service_Creation_Info or Service_Verification_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 GSSs--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.