CURRENT MEETING REPORT
Reported by John Linn, OpenVision
Common Authentication Technology Working
Group (cat)
SUMMARY
The CAT Working Group met for two sessions
at the Los Angeles IETF. Status of documents was discussed. Two
I-Ds (SPKM and Kerberos mechanisms) are currently at the IESG
being considered for advancement to Proposed Standard. Several
other active I-Ds have received variable levels of discussion
within the WG. Specific discussion topics at the meeting included
two activities re public-key login with Kerberos: a presentation
on DCE public-key Kerberos login work, and discussion of work
and issues re the "pk-init" Internet-Draft. Other topics
included discussion of the status of the negotiation GSS-API mechanism,
issues re GSS-V2 and the Kerberos V5 GSS-API mechanism, contrasts
between non-repudiation as defined in CORBA vs. IDUP, and a brief
presentation on a smartcard-based GSS-API mechanism developed
at the Union Bank of Switzerland.
Two clarifying and constraining comments
will be drafted for inclusion in the Kerberos V5 GSS-API mechanism
draft, currently in IETF Last-Call. A revised GSS-V2 draft, reflecting
comments received during the working group review period and discussed
at the meeting, will be edited and released after the meeting
(working target: during March), and the result will be placed
into Working Group Last-Call.
GENERAL DISCUSSION
The status of working group drafts was reviewed.
John Linn encouraged review and comment on all drafts, and reminded
attendees of RFC-1602's community and consensus requirements for
standards-track advancement.
Cliff Neuman (ISI) is in the process of
revising RFC-1510 to reflect errata and implementation experience.
The result will be reflected in a new Internet-Draft, to be considered
as a candidate for advancement to Draft Standard.
Re draft-ietf-cat-kerberos-passwords-02.txt,
an updated version is planned before the current draft expires
from the I-D repository. Denis Pinkas (Bull) stated that comments
which he had made against this draft had not yet been resolved.
In the second session, Denis presented a
brief report from the RADIUS meeting, which was investigating
RADIUS extensions. Denis suggested incorporation of GSS tokens
into RADIUS and provided a copy of the GSS-V2 spec to the RADIUS
chair, but noted that the fact that current RADIUS tightly limits
token sizes is an issue. Glen Zorn (Microsoft) commented that
he did not believe GSS-API was a clean, appropriate fit into the
RADIUS model, and Denis suggested off-line follow-up on this topic.
DCE WORK ON KERBEROS PUBLIC-KEY LOGIN
Bill Sommerfeld (HP) presented a discussion
of DCE 1.2.2 public-key login, based on Kerberos V5. (The DCE
Security Service, in addition to Kerberos, also includes a service
to manage privileges and UNIX account information.) The approach
integrates public-key processing into the Kerberos TGT acquisition
protocol. The work was motivated by indicated customer demand
for public-key support in DCE. The design prevents disclosure
of a KDC's database from allowing an intruder to later impersonate
users within a realm.
Bill was asked why the "pk-init"
Internet-Draft wasn't used. He commented that it had expired,
that it did not appear to have undergone major peer review, that
motivating customers did not like its approach, and that his group
regarded its use of certificates as unnecessary.
The DCE approach uses Kerberos V5 preauthentication
hooks. Public-key and non-public-key users can coexist within
a realm. A client's public key is used by the KDC to encrypt a
random key used, in turn, to encrypt a session key.
An X.511 bind token is used in preauthentication
data. Certificates are not currently employed, but could be incorporated
in future. Bill was asked, "Why X.511/ASN.1?" He commented
that it existed in non-expired form and that it had been the subject
of significant review. The initial version has no algorithm negotiation
(currently unnecessary, since there are no current algorithm options
to be negotiated), but future negotiation extensions are possible.
The Personal Security Module (PSM) is a
high-level abstraction for a smart card, isolating callers from
underlying crypto implementations. This interface was defined
partly because crypto-layer APIs have not yet converged: Bill
observed that Cryptoki and GCS-API were too low-level. Users have
separately-identified keypairs for signature and confidentiality
purposes, though it's possible for both keypairs to be the same.
Public components are stored in the DCE registry.
The approach is currently defined in OSF
RFC 68.2 and can be received by non-OSF members by request to
Anne Anderson at HP. If interest exists, it could be published
as an IETF Internet-Draft. It will be implemented in OSF DCE 1.2.2,
hopefully by late 1996; this initial version will not include
smartcard drivers and will depend on BSAFE.
It was noted in discussion that pk-init
doesn't strictly require certificates. Denis Pinkas reiterated
in the context of the HP proposal a suggestion which he had also
made for pk-init: that unnecessary usage of unnecessary strong
encryption keys for user data be avoided. Cliff Neuman noted that
it would be good to harmonize pk-init with this work, if possible;
it was announced at the second session that Bill and pk-init authors
had made encouraging progress in discussing this prospect, with
further anticipated progress to be reported to the list.
DRAFT-IETF-CAT-PK-INIT AND RELATED WORK
Brian Tung (ISI) gave a presentation on
the pk-init work (with which Cliff Neuman and John Wray (DEC)
are also involved), for which a "-01" revised Internet-Draft
will be issued shortly (stated goal: by 15 March). Brian described
the pk-init approach as offering "Low pain, high gain",
and as requiring minimal protocol changes. Motivations include
simple key management, simple recovery, and resistance to dictionary
attacks. Implementation status: available for V5 beta 4.3 (from
ftp://prospero.isi.edu/pub/pk_init/distribution, based on -00
pk-init draft), with V5 beta 6 patches submitted to MIT and reflecting
some of the changes which will be inclued in the -01 draft.
Supported scenarios include key pair registered
with KDC (with private component either stored on local disk or
stashed on KDC), and key pair registered with external service.
X.509 certificates are used. Several issues had been raised at
the Dallas meeting, and further discussion was solicited: format
of kdc-cert, format of transited realm, and a request for separate
keys for integrity and encryption for export reasons.
Requests were made for rationale discussion
about security issues with different operating modes, and about
return vs. non-return of private key for other uses. Regarding
liaison between pk-init and the HP-DCE public key login work,
Cliff Neuman stated that it might be possible for pk-init to reflect
HP-provided change requests in the interests of alignment. Bill
Sommerfeld asserted that protocol format definition is critical,
but certificate handling issues more deferrable; Cliff responded
that use of a certificate is particularly valuable for the KDC.
SIMPLE NEGOTIATION GSS-API MECHANISM
Denis Pinkas gave a presentation on the
negotiation mechanism's status. A second Internet-Draft has been
produced, and a reference implementation is available (of the
negotiation mechanism per se, not in conjunction with other mechanisms:
see ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz). The
reference implementation uses ASCII configuration files to identify
supported/accepted mechanism OIDs. A question was raised as to
how the snego reference implementation could be coupled with mechanism
modules; Ted Ts'o (MIT) mentioned parallels with GSS-API mechanism
glue layer code.
The current specification appeared (to the
set of attendees who had been tracking its progress) largely stable.
Denis accepted John Linn's comment about multi-level option hierarchies
as posted to the mailing list (though did not perceive ambiguity
in the current wording) and solicited text for inclusion.
KERBEROS V5 GSS-API MECHANISM
When the meeting took place, this document
(draft-ietf-cat-kerb5gss-06.txt) was in IETF-level Last-Call for
advancement to Proposed Standard. Two issues were raised and discussed
at the meeting and by E-mail between sessions.
The first issue relates to behavior of Kerberos
mechanism implementations when type BOTH credentials (credentials
structures supporting both initiation and acceptance of security
contexts) are employed, an area which currently varies among implementations
and on which the current draft is silent. Ted Ts'o and Bill Sommerfeld
agreed to draft and circulate text on this topic on the CAT list
for discussion and, if accepted, inclusion within the document.
A goal of convergence in two weeks (i.e., by Tuesday, 19 March)
was cited.
The second issue concerned clarification
on how interoperable delegation was to be implemented for the
mechanism. Per E-mail to the list from Dan Nessett (Sun), a statement
will be added saying that a TGT will be transferred within the
KRB_CRED message with its FORWARDABLE flag set.
GSS-API VERSION 2
John Linn presented summaries of the changes
made in draft-ietf-cat-gssv2-05.txt and currently outstanding
issues. A comment was made that the new Implementation Robustness
section was suitable and appropriate to respond to concerns against
an earlier draft. It was agreed that GSS_Export_name() should
be able to return a GSS_S_NAME_NOT_MN status if passed an input
name which is not an MN, but that return of this status should
not be required for all non-MN input cases. It was agreed that
no new requirement would be imposed constraining the pair of GSS_Compare_name()
inputs to contain at least one MN.
Ted Ts'o had posted to the list a proposal
for a new GSS_Duplicate_name() call, in order to avoid the prospect
of referencing pointers aliased at name objects which might previously
have been freed. This proposal was motivated by work with the
multi-mechanism glue layer (which checks the set of name types
supported by its underlying mechanisms). The call's inclusion
is motivated by a need to operate in environments which do not
perform automatic garbage collection, and a desire for GSS-API
to be relatively self-sufficient in managing its objects. Following
some discussion on the necessity for this call relative to duplication
facilities on other objects, the group agreed to accept inclusion
of a GSS_Duplicate_name() call, with Ted Ts'o accepting the action
of revising the text to explicitly allow implementations which
use reference counting rather than copying in order to support
the facility.
In discussion of GSS_Duplicate_name(), Dennis
Glatting (CyberSAFE) posed the question of whether a facility
for duplication of credentials should also be included. It was
noted that, while potentially useful, this could be difficult
to support within some implementations given side effects of some
operations (e.g., GSS_Add_cred()) on credentials. It was suggested
that duplication of credentials should be functionally equivalent
to calling acquire_cred twice. It was initially suggested that
duplication facilities for all GSS objects, not just credentials
and names, should be evaluated for inclusion in GSS-V2. Following
discussion in the second session, however, it was agreed that
new duplication facilities other than GSS_Duplicate_name() would
not be pursued at this time.
Dennis Glatting commented on a set of common
threads collected from customer inputs (also discussed in E-mail
to the list). He noted the fact that CyberSAFE allows memory-based
replay caches, and that use of such caches appears, undesirably,
as memory leakage from the viewpoint of customers' memory analysis
tools. To respond to this concern, he suggested inclusion of gss_open()
and gss_close() routines, previously suggested to the WG though
controversial in discussion, which would be used optionally by
use by applications wishing to delimit their use of GSS-API resources.
John Myers (CMU) commented that this appeared to be an inappropriate
solution and asserted that a gss_close() routine wasn't needed.
Ted Ts'o observed that Purify doesn't flag as memory leaks objects
which are pointed to by statics, and also pointed out that addition
of a context variable to GSS calls would be useful but would be
backward-incompatible, and therefore inconsistent with agreed
GSS-V2 scope.
Dennis also observed the current fact that
the only QOP value portable across mechanisms is "default",
implying that use of other values must be hard-coded or configured
in a mechanism-specific fashion. (Earlier WG discussion on broader
mechanism-independent definition of QOP values had failed to converge,
leaving this as the current status.) On a separate point, Dennis
re-iterated the value of the parse_token() facility which had
been proposed by Carlisle Adams (BNR) within SPKM but which had
not reached cross-mechanism WG consensus.
Denis Pinkas presented a set of GSS-V2 comments:
Major points:
Re naming section, particularly discussion of relation among naming-related routines, Denis requested a dataflow diagram and associated commentary.
Denis believed that the exported object format described in Section 4.2 is missing a slot for an OID. Ted Ts'o replied that, since some mechs may use implicit typing, the top-level specification need not specify the presence of an OID. Ted accepted an action to provide rationale text discussing why no typing is required at the mechanism-independent level.
Denis commented that he thought a name_type for GSS_Export_name() was missing. In discussion, it was agreed that no name_type was intended at this level; Ted accepted an action to tighten commentary in this area.
Denis requested that Annex A re PACs should be dropped (suggestion accepted by John Linn) or revised.
Minor points:
Denis suggested deletion of GSS_Inquire_mechs_for_name(), arguing that it did not appear easily implementable in a cross-vendor fashion. The mechanism glue layer in the MIT implementation constructs a table by calls to GSS_Inquire_names_for_mech(); GSS_Inquire_mechs_for_name() is not strictly necessary given GSS_Inquire_names_for_mech(), but is convenient for applications. As a higher-level comment, it was noted that the primary goal is an API for use by applications, not an internal glue layer interface. GSS_Inquire_mechs_for_name() was retained.
More explanation was requested to motivate the need for a anonymous name OID.
Editorial comments:
Requested revision of references to the term "signature".
Requested addition of table of contents.
Requested movement of Sec. 3 into annex; since section 4's content is normative, it was suggested that it should come first.
GSS_Import_name: output_name -> output_name_string [Note: output of import_name is an internal name, not a string, so this comment needs clarification.]
Host-based service name editorial comment. [Note: Comment needs to be restated.]
CORBA/IDUP NON-REPUDIATION
The authors of the IDUP and PIM specifications,
as cited by Dragan Grebovich (TimeStep) had believed that the
IDUP documents had converged to a stable state, but Denis Pinkas
voiced concerns in a presentation.
Denis observed that IDUP deals with non-repudiation
as well as other services, and that Object Management Group (OMG)
CORBA (based on a joint proposal submitted by a number of companies)
also handles non-repudiation. Per Denis, non-repudiation provides
evidence of actions which cannot be repudiated later. In CORBA,
non-repudiation evidence is provided in the form of a token. Most
common types are non-repudiation of creation, non-repudiation
of receipt; these are differentiated from ISO origin vs. delivery
constructs, because CORBA is more concerned with an object's creator
than with its sender. Distribution status of OMG documents to
non-OMG members is unknown, but Denis will investigate.
Supported OMG operations include: set_NR_features,
get_NR_features, generate_token, get_token_details (yielding parameter
set validated by evidence), verify_evidence, and form_complete_evidence
(collects information in a package to guarantee veriability in
arbitrary future). Non-repudiation policies have IDs and versions.
A "conditionally valid" status can be returned if, e.g.,
the time period when the evidence generator may declare his/her
key invalid has not yet expired, or if trusted time is required
for strong validation but is not available. Policies define rules
for generation, validation, and adjudication of disputes. Policy
management interfaces are also incorporated.
Denis stated that he has been working with
Carlisle Adams on alignment with IDUP, but that due to various
time constraints the alignment has not yet been accomplished.
Warwick Ford (BNR) commented that it was not clear what changes
would be motivated on IDUP. Denis observed that the IDUP document
was dealing with: (1) confidentiality and integrity, and (2) non-repudiation.
He asserted that aspect (1) was relatively stable, with only a
few minor changes needed, but that for (2) better alignment with
the CORBA specification would be highly desirable. Based on this
observation, he suggested that, if a need existed to have (1)
available very soon, then a split between (1) and (2) would be
possible; as an alternative, he suggested that the IDUP document
be delayed in the interests of polishing (2).
Denis asserted that use of a single IDUP
call with many options (using the parameter bundling concept)
was not necessary and was leading to overcomplication. Considering
the simultaneous need for (1) and (2) to be an infrequent case
(an assumption which proved controversial in discussion), Denis
noted that two consecutive calls could be applied to accomodate
this case, and further stated that this partitioning would greatly
simplify understanding and ease alignment with the CORBA specification
which deals only with non-repudiation. Consensus on requisite
or appropriate action was not clearly apparent. Limited on-list
IDUP discussion had taken place, and Carlisle Adams, author of
the base IDUP specification, was not available at the IETF session
to respond directly.
UNION BANK OF SWITZERLAND SMARTCARD GSS-API
IMPLEMENTATION
Harald von Fellenberg, Union Bank of Switzerland, gave a brief presentation on a smart card implementation which performs node and personal identification. Their installation is in the process of moving from a mainframe to a distributed environment. The approach uses an interface modeled after GSS; GSS glue code has been completed to layer above UBS's own calls and to expose a GSS interface to calling applications. Siemens chipcards are used on client and server sides, providing both user-host and host-host authentication, with an "Authenti-Box" for servers and a "Persauth" element for a personal chipcard. They are also interested in SKIP protection of network traffic and in coupling key management with smart cards. An attendee from Boeing stated that Boeing is also active in smart card usage, and both he and Harald stressed the operational importance of single sign-on.