November '93 IETF: Common Authentication Technology WG (cat)

[John Linn <[e-mail]>]

Group Name: Common Authentication Technology WG (cat)
IETF Area: Security
Date/Time: Tuesday, November 2, 1993: 1330-1530
           Wednesday, November 3, 1993: topics for CAT at Houston IETF (Tuesday, 1330-1530 and
Wednesday, 1600-1800):1600-1800

----

Agenda:

(1) Administrative issues: officers, possible spin-off subgroups to
progress particular activities, follow-on work plan

(2) Status review of CAT-related activities: KV5, KV4, CATS,
implementors' guidance/agreements, environment-specific extensions and
specifications (e.g., proposed POSIX environment addendum, to include
recommendations for GSS_set_default_cred and GSS_lookup_default_cred),
X/Open liaison

(3) Presentation(s) on implementation issues and experience

(3a) Piers McMahon on SESAME multi-mechanism implementation

(3b) others??

(4) Specific technical issues raised on CAT list and summarized below

(5) FTP security discussion

o Discuss changes to the FTP Security Internet Draft

    - Principal name fallback (use "rcmd" if "ftp" doesn't exist)

    - Changed GSS_Safe to GSS_Seal with conf_flag == FALSE

    - Changed GSS_Verify to GSS_Unseal

    - Changed GSS_Seal to GSS_Seal with conf_flag == TRUE

    - Changed the mailing list from [e-mail] to [e-mail].

o Reach closure on the length of buffers allowed for protected file transfers

o Reach closure on the lack of restriction on the length of base-64 encodings

o Decide on the targ_name for the GSSAPI specification for FTP

    - Since we have a "fall back" name for Kerberos V4 ("ftp" vs. "rcmd"),
      we've defined "SERVICE:ftp@hostname", but is there a more common name
      we could fall back on?

o Get commitments for more implementations of FTP Security in general,
    including of the GSSAPI specification for FTP

(6) Discussion of Internet Authentication Guidelines I-D,
draft-haller-auth-requirements-01.<txt,ps>. (Atkinson/Haller: Ran Atkinson
to present)

(7) Portability levels: how far should we try to go in the direction
of binary-level portability, and what's needed?

Specific issues related to GSS-API RFC-1508:

(1) Addition of GSS_inquire_context, per request (to enable libraries
independent of a GSS-API implementation to extract information from a
context structure), and list proposal

(2) Multi-mechanism support requirements, facilities, and extensions:

(2a) Proposal for gss_add_cred as replacement/preferred alternative to
gss_acquire_cred; observation that acquire_cred isn't usefully
specific in the errors it returns, and that input of a single name
type constitutes a significantly limiting restriction, if more than a
single mechanism is relevant.

(2b) add GSS_BAD_MECH as possible return from gss_init_sec_context
and gss_accept_sec_context

(2c) ambiguous scope of interpretation for minor_status values when
no current mechanism is defined (as in gss_acquire_cred)

(3) Renaming/deprecation of per-message primitives' names, per X/Open
request: we agreed tentatively to do this pending E-mail review, but
the list has been silent.  The proposal on the table, per the July CAT
WG minutes, is the following:

(3a) GSS_Sign -> GSS_GetMIC

(3b) GSS_Seal -> GSS_Wrap

(3c) GSS_Verify -> GSS_VerifyMIC

(3d) GSS_Unseal -> GSS_Unwrap

Going once? Going twice? :-)

(4) Raised, but unresolved, at last meeting: new or extended per-message
service to allow confidentiality without integrity?

(5) Other erratum: GSS_init_sec_context's GSS_NO_CONTEXT return should
be clarified as covering any case where the input context_handle can't
be used.  (Unless the caller has a pending context establishment in
progress, no non-zero input handle is acceptable.)

Specific issues related to GSS-API C Bindings RFC-1509:

(1) Currently, there's no clear transition between the last routine
discussed (GSS_Inquire_cred, section 3.20) and the following header
file data ("gssapi.h").  This should be fixed, and it would be
beneficial for portability, making object-level porting plausible, if
all implementors employed the same header file as incorporated in the
standard.  Suggestion: add a section header for "gssapi.h", confirming
that its use is an element of conformance to the GSS-API C bindings.

(2) Acquire_cred should be able to accept a NULL desired_name, to match
1508.

(3) GSS_Process_context_token should be changed to accept a pointer
to context_handle, corresponding to fix made to GSS_Delete_sec_context.