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

Text File | 1995-02-28 | 22KB | 433 lines

CURRENT_MEETING_REPORT_

Reported by John Linn/OpenVision

Minutes of the Common Authentication Technology Working Group (CAT)


Summary

The Common Authentication Technology Working Group (CAT) met for two
sessions at the San Jose IETF. The group progressed through a busy
agenda, including the following areas:  Kerberos One-Time Passwords
Internet-Draft and issues; updated Simple Public-Key Mechanisms
Internet-Draft and issues; Internet-Draft update to RFC 1508 and issues;
status of Windows GSS-API bindings; Independent Object Protection (IOP)
Internet-Draft for extensions to GSS-API and issues; issues affecting
the update to the FTP security Internet-Draft for its advancement to
Proposed Standard; discussion concerning multiple overlay proposals for
interfaces to layer atop GSS-API. Revised Internet-Drafts are expected
for many of these documents in advance of the Danvers IETF; in
particular, a revised FTP security Internet-Draft will be targeted for
submission to become a Proposed Standard; depending on implementation
results, a version of the SPKM Internet-Draft may also be submitted for
advancement.


Kerberos V5 One-time Passwords

Following agenda discussion, Glen Zorn (CyberSAFE) presented discussion
about the Kerberos V5 one-time passwords Internet-Draft
(draft-ietf-cat-kerberos-passwords-00.txt) which he had co-authored with
Cliff Neuman (ISI). The proposal's goal is to support a range of
one-time password schemes through use of the Kerberos V5
preauthentication data (padata) field.  The draft considers two cases of
one-time password integration, one of which is more secure and easier to
support, but is unable to accommodate as broad a range of one-time
password technologies.  In the less secure, more complex, but more
general case, the server is assumed to know passcode values in advance;
for the higher security case, the server is not assumed to know passcode
values in advance.

Ted Ts'o (MIT) observed that the weaker form presumes that peers know
the salting value a priori and can perform computations with it; as an
alternative, he suggested that the salt value be provided dynamically in
a krb_error message.  Charlie Kaufman (Iris) noted that Security
Dynamics had indicated potential willingness to opening up the structure
of their interfaces in order to support operation in the stronger mode.
The group agreed that both classes should be supported.  It was also
believed that more than the 5 passcode type values currently defined in
the draft are needed.  In detailed discussion, Bill Sommerfeld
(Hewlett-Packard) commented that a redirect facility should be available
to designate a server address.  It was also recognized that the proposal
contains no explicit internationalization facilities (e.g., to tag a
desired language for user prompt messages).

Cliff Neuman expressed a desire to move forward quickly on revision of
this specification to another Internet-Draft, and then to advance the
result to Proposed Standard status.  Cliff asserted that client support
for the defined passcode types should be mandatory, though server
support would be optional (and often dependent on availability of
proprietary vendor code).  In response to a query about availability of
one-time password code in the MIT Kerberos distribution, Glen Zorn
indicated that CyberSAFE would be willing to contribute requisite
client-side code, and possibly a server-side S/Key implementation.
Piers McMahon (ICL) noted that it would be useful to define a common API
for use on the server side; Ted Ts'o observed that maintaining modular
structure within the KDC was important.  Cliff also commented that
additional work was underway on public-key preauthentication, but that
it was not yet sufficiently complete or stable to be considered for
standardization.  Further review of the Internet-Draft and comment on
the working group mailing list was solicited.


SPKM

Paul Van Oorschot (BNR) presented an update on the Simple Public-Key
Mechanism (SPKM) proposal, documented in draft-ietf-cat-spkmgss-01.txt
and for which Paul gave primary technical credit to Carlisle Adams of
BNR. SPKM incorporates digital signature facilities (see also IOP
extension proposal, discussed elsewhere in these minutes) as well as
base GSS-API services, and can operate in a mode which imposes no
requirement for shared secure time.  Algorithm IDs provide
extensibility, and negotiation facilities are provided for selection of
alternate algorithms for confidentiality, integrity, and key
establishment within SPKM. QOP values are used to select among different
integrity levels, including a level which provides non-repudiation.

Changes between the original and current SPKM Internet-Drafts were
summarized.  Token formats include syntax changes for alignment with
Project SESAME. The distinctions between SPKM-1 (random-number based,
with 2-step one-way authentication of target to initiator, or 3-step
mutual authentication) and SPKM-2 (timestamp-based, with one-step
one-way authentication of initiator to target or 2-step mutual
authentication) operational modes were clarified.  OIDs were changed to
Algorithm IDs in order to carry parameters; all tokens are now encoded
in ASN.1 BER. Context negotiation within the mechanism now negotiates
the key establishment mechanism.  SPKM now specifies certificate_data as
optional, and allows a source name in a request token as an alternative.
The SPKM-REQ now has an optional authorization data field (as in
Kerberos V5), and an optional validity period specifier for the
context's key.  Two new integrity algorithms were added:  one which
provides single-pass integrity and encryption for data and another based
on an encrypted MD5 hash.  Some additional minor status values were
defined for SPKM.

Error handling is enhanced by including a sequence number to identify
the token within which a processing error occurred.  Some discussion
ensued about whether error-reporting tokens were themselves signed
objects; signatures are applied but (given the fact that the signatures
will not necessarily be verifiable under all failure conditions), their
reports are assumed to be accepted whether or not the signature check
succeeds.  It was observed that this can make implementations vulnerable
to disruption through receipt of gratuitous and/or spurious error
tokens.  Further clarification on error token generation and processing
is expected before the next IETF meeting.

Several SPKM implementation activities are proceeding.  BNR is
approaching completion (before the end of 1994) of an implementation
including some proprietary facilities and performance optimizations.
SESAME is building an implementation of SPKM-2, which is to be publicly
available.  The University of New Brunswick is developing a public
reference SPKM implementation, and additional activity may be underway
in Australia.  Ted Ts'o suggested that SPKM developers attempt to use
the GSS-API sample application as available in the MIT Kerberos V5
distribution as a test vehicle to exercise SPKM and to validate
portability.  Interoperability testing is planned between now and
February 1995, with results to be reported to the CAT list; depending on
progress, SPKM may be recommended for advancement to Proposed Standard
at, or before, the Danvers IETF meeting.


GSS-API Bindings for Microsoft Windows

Piers McMahon reported on the status of Windows bindings for GSS-API,
which had been the topic of prior mailing list discussion and proposal
by Piers.  Like RFC 1509, Piers' draft presumes that GSS-API functions
operate in a synchronous and potentially blocking mode; the prospect of
an alternative asynchronous interface was also agreed to be useful, but
would be a separate effort; Shawn Mamros (FTP) indicated possible
interest in such an activity.  Ted Ts'o noted that MIT will be engaging
a developer to build a Kerberos V5 DLL based on Piers' draft.  A version
of the draft document as discussed in e-mail, reflecting revisions based
on comments received, will be sent to Internet-Drafts shortly.


GSS-API Overlay Proposals

Multiple proposals have been made on alternate interfaces to layer atop
GSS-API, providing protected communications sessions, including (at
least) Ted Ts'o's CATS, work (by Lam) at the University of Texas at
Austin, and an e-mail proposal made by P. Rajaram.  Don Stephenson (Sun)
was familiar with the UT/Austin work, and may be able to make its code
and/or a descriptive USENIX paper available on-line.  We collected an
informal subgroup (Don Stephenson, John Myers (CMU), Glen Zorn, Ed Reed
(Novell), and Ted Ts'o) to work on a consolidated proposal to become an
Internet-Draft, drawing on these inputs.


GSS-V2:  Changes Made In the Internet-Draft

A number of changes, included in draft-ietf-cat-gssv2-00.txt, were
summarized.  These changes are specific and incremental, derived from
implementation experience and liaison requests and making only minor
modifications to the functional model established in V1, and their
inclusion is not perceived as necessitating reset of GSS-API's standards
status to Proposed Standard rather than progressing to Draft Standard.


   o Changed GSS_ prefix for major_status values to GSS_S_.

   o Added GSS_S_GAP_TOKEN major status to be returned by GSS_VerifyMIC()
     and GSS_Unwrap() to indicate receipt of a message following skipped
     predecessor sequenced messages.  Rewording in Section 1.2.3 on
     sequencing indicators.

   o Added new GSS_S_BAD_QOP major status.

   o Added description of GSS_S_BAD_MECH return status for
     GSS_Init_sec_context() and GSS_Accept_sec_context().

   o Added non-textual name import and export routines, as proposed in
     the Kerberos V5 Internet-Draft.  Renamed GSS_Import_internal_name()
     to GSS_Import_name_object() and GSS_Export_internal_name() to
     GSS_Export_name_object() to avoid terminology confusion; the phrase
     ``internal name'' is already used to represent the opaque form as
     supported within a GSS-API implementation, and the input to
     GSS_Import_name_object is an object tagged externally to GSS-API.

   o Added GSS_Inquire_context().

   o Deprecated GSS_Sign, GSS_Seal, GSS_Verify, GSS_Unseal routine names
     in favor of successors GSS_GetMIC, GSS_Wrap, GSS_VerifyMIC,
     GSS_Unwrap.  (After some discussion, we resisted the temptation to
     revisit the function naming question again.)

   o Added new GSS_Wrap_size_limit() routine to determine how large an
     input token can be provided to GSS_Wrap() without generating an
     output token larger than a caller-specified size.

   o Rewrote description of channel bindings (Sec.  1.1.6) for purposes
     of clarification.

   o In routine descriptions, changed types of credential and context
     handle arguments to CREDENTIAL HANDLE and CONTEXT HANDLE,
     respectively.


GSS-V2:  Issues Pending and Discussed

This section summarizes topics pending against GSS-V2 and their intended
disposition.  Further discussion is required to ascertain working group
consensus about whether the scope of intended actions on these topics
warrants resetting GSS-V2's standards status to Proposed Standard rather
than proceeding to Draft status.


   o Level, if any, to include extension routines for OID and OID set
     management:  John Linn to send message to list, comparing Wray and
     Glatting proposals; subsequent resolution to be sought on list.

   o GSS_Add_cred() proposal.  Accepted for addition.

   o ASN.1 syntax for Appendix B, conformantly permitting non-ASN.1
     enclosed objects.  No information available.

   o Definition of reserved QOP values to distinguish NO, WEAK, MEDIUM,
     STRONG levels in a mechanism-independent matter (with mapping to
     algorithm choices to be mechanism-specified), and to distinguish
     integrity QOP from confidentiality QOP. Accepted for addition.
     Additional values designating FAST, SLOW, and (for integrity)
     NON_REPUDIABLE were suggested and also accepted.

   o GSS_Delete_sec_context() to be documented as returning a token only
     if caller requests same by passing a non-NULL buffer to accept it;
     usage with NULL token and, therefore, without transfer of deletion
     token to be recommended.

   o GSS_Process_context_token() changes to distinguish whether or not
     context remains valid; action:  not adopted.

   o Facilities to enable binary compatibility:  believed to require
     only changes to RFC 1509 (concrete typing of 4 objects), as
     documented in e-mail from John Wray.  Action:  Review Wray proposal
     and assume that it holds, unless list discussion revisits the
     issue.

   o Ability for GSS_VerifyMIC() and GSS_Unwrap() to return, in addition
     to current fatal errors on receipt of unsequenced messages, new
     advisory codes to report the same conditions.  Action:  Intend to
     support.  John Linn and Marc Horowitz (OpenVision) to codify
     proposal to the list.

   o GSS_Open(), GSS_Close() proposal (added calls to obviate need for
     constructing self-initializing implementations of other GSS-API
     routines).  Ted Ts'o observed that the strongest portability rules,
     as he has seen applied in other developments, require that neither
     static nor global variables be used; conformance to this standard
     would imply that each GSS-API routine would need to incorporate an
     added parameter for a caller-provided state block, a pervasive
     change which the group was not prepared to adopt at this time.  The
     semantics of GSS_Open() and GSS_Close() in terms of objects which
     could be allocated and freed (with and without maintenance of
     reference counts) received some debate; resources (e.g., replay
     caches) potentially sharable across multiple callers were a
     particular discussion point.  Action:  discussion remanded to list.

   o Dual-use (INITIATE and ACCEPT) credentials, within which expiration
     times and other parameters may differ for directions of use, and
     extensions (e.g., by new parameter to GSS_Inquire_cred() or new
     GSS_Inquire_cred_specific() routine in order to preserve
     GSS_Inquire_cred()'s call signature intact:  there was disagreement
     (as yet unresolved) about what, if any, changes are needed in this
     area.  Action:  more discussion needed.


FTP Security

Sam Sjogren (TGV) led discussion of FTP security, beginning at the end
of the first CAT session and finishing at the beginning of the second
session.  Relatively few of the session's attendees indicated detailed
familiarity with the FTP security draft.  During the second session,
Steve Lunt (J.P. Morgan), author of the current Internet-Draft
(draft-ietf-cat-ftpsec-05.txt) joined the discussion via speakerphone.
Sam Sjogren and Marc Horowitz intend to handle the next set of revisions
to the Internet-Draft, between January 1995 and the next IETF meeting,
with the result targeted for recommendation by the working group to Jeff
Schiller as Security Area Director for advancement to Proposed Standard.
Marc Horowitz noted that the current draft emphasizes client-side
behavior and should be enhanced to include more detailed discussion of
server-side cases and behavior as well; he has implemented client-side
and server-side FTP security code layered atop GSS-API and can
contribute to clarifying this discussion.

Proposal:  Add a new reply code to support OT passwords; the apparent
sense of the group was that this was a useful and valid facility,
without adverse impact on existing clients and enabling new
security-aware clients to accomplish more intelligent behavior.

An issue was discussed about the relation between AUTH and USER
commands:  is it acceptable to perform AUTH more than once
(renegotiating) to create a new security context within an FTP session?
A window of vulnerability can be constrained by refusing to act on
commands which are received outside secure mode.  Proposal:  a new AUTH
will tear down any existing security context and try to initiate a new
one; Ted Ts'o notes that this does not work in all cases (e.g., chroot,
where you would not be able to go back to prior identity) or on all
system types.  Marc Horowitz notes that current FTP implementations
refuse to accept a new USER command on an existing session; analogously,
it would be possible for implementations to reject a new AUTH command
once a context is in place.  An implementation note on behavior seems
important here.

Should MIC be required on all commands once security initiated?
Diffie-Hellman and one-time password mechanisms cannot accommodate this,
for example.  Marc believes that it should not be required (if so
negotiated, in a tamperproof fashion).  Proposal accepted; a server need
not require use of MIC'd commands.

Use of more verbose error codes was proposed and accepted.

Multiline reply format (Jeff Schiller issue):  Jeff suggested dropping
1:1 correspondence between number of input versus protected lines,
encoding multiline object as an object.  Noted that multiline replies,
unlike file data, are not generally massive.  It was proposed that each
line should be represented as a separate GSS-API token, but discussion
here was not conclusive.


Independent Object Protection (IOP)

Paul Van Oorschot proposed GSS-API extensions for use in a
store-and-forward environment, per a recent Internet-Draft
(draft-ietf-cat-iopgss-00.txt) authored by Carlisle Adams of BNR. Its
motivations include the need to protect important applications (e.g.,
e-mail) which are not session-based, to protect independent message
objects, and to operate independently of on-line communication with
target.  The IOP proposal permits a context, and an object protected in
conjunction with that context, to be addressed to and processable by
multiple recipients.  By intent, IOP contexts impose no expiration
times.  For the case of mechanisms capable of supporting both base
GSS-API and IOP functions, the ability to use common credentials for
both classes of operations is a valuable facility.

The IOP proposal's security context construct contrasts with that in the
base GSS-API: rather than being shared on-line with a peer, independent
contexts at initiator and target allow creation and remote recovery of a
key.  It was suggested that, in order to reduce confusion, another term
rather than ``context'' be used to describe the IOP construct.  Ted Ts'o
and Marc Horowitz expressed elements of an alternate view:  that at
least some of IOP's goals might be satisfiable within the conventional
GSS-API, given a mechanism within which context establishment could be
accomplished with exactly one context establishment token from initiator
to target, and suitable technology supporting the existing GSS-API
per-message calls.  An updated draft is expected to include renaming of
the IOP context construct and to clarify IOP context expiration
semantics.

The IOP proposal leaves GSS-API's credential functions unchanged, and
adds new IOP_Init_context(), IOP_Accept_context(), and
IOP_Delete_context() for management of IOP contexts.  New per-object
calls IOP_Protect(), IOP_Unprotect() are provided; each operation is
subdivided into ``start,'' ``operate,'' and ``end operate'' calls,
emitting a prot_token at the start of processing and an optional
receipt_token; common routines provide functions analogous to both
GSS_Wrap() and GSS_GetMIC().  Continuation facilities seem more important
for protection of potentially-large documents than for the
session-oriented paradigm in which the base GSS-API operates.  Each
operation yields a buffer (e.g., of encrypted text), not a token; this
aspect of the proposal was controversial.  Issues around segmentation of
buffer data at peers, and requirements on crypto-algorithm quantization,
arise here:  tokenizing would help here and will be explored.  One new
support call, IOP_Extract_Prot_Token(), is added in the proposal.
Clarification on buffers and their management is expected in an updated
draft.

BNR is implementing the IOP proposal, but this implementation is not
planned to become public domain; the availability of the specification
is intended to encourage independent evaluation and implementation
activities.


Action Items Pending

Check on availability of documents on Stephenson and Rajaram's mechanism
negotiation work; also on electronic availability of paper and,
possibly, code from UT/Austin re session-oriented overlay for GSS-API.
(Don Stephenson).

Send summary message re ``Service:''  name prefix issue (Ted Ts'o, to be
supported by others with memory of the issue).


Status of Active CAT Documents and Advancement Plans

GSS-V2:  To be revised Internet-Draft before Danvers meeting (John
Linn).  To plan for advancement from Proposed to Draft standard level,
we need a statement proposing how the IETF's independent implementation
requirements for advancement to Draft, defined and commonly used for
protocols, should be applied for this case of an interface
specification; John Linn will draft such a statement.  Piers McMahon
commented that X/Open has relevant experience in interface validation
and is now planning test procedures and suites to validate conformance
with GSS-V1.

FTP Security:  To be revised Internet-Draft early 1995, before Danvers
meeting, with result targeted for advancement to Proposed Standard (Sam
Sjogren, Marc Horowitz, Steve Lunt).

SPKM: Implementation experience pending at BNR and University of New
Brunswick (the latter to be freely available reference implementation),
possibly also at SESAME; experience to be summarized to list in advance
of advancing current or revised Internet-Draft to Proposed Standard,
possibly before Danvers meeting (Paul Van Oorschot, for Carlisle
Adams).

IOP: Internet-Draft to be revised (Paul Van Oorschot, for Carlisle
Adams).

Kerberos One-Time Passwords:  Internet-Draft probably to be revised
(Glen Zorn, Cliff Neuman).

Kerberos V5 GSS-API mechanism:  slight Internet-Draft revision pending
(John Linn).

Windows GSS-API bindings:  to be released as Internet-Draft (Piers
McMahon).

RFC 1509:  Internet-Draft update needed to track 1508 changes, binary
portability, and other pending issues (John Wray:  John Linn to contact
re scope and status of planned RFC 1509 revisions.).