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

Text File | 1995-05-26 | 21KB | 418 lines

CURRENT_MEETING_REPORT_

Reported by John Linn/OpenVision

Minutes of the Common Authentication Technology Working Group (CAT)


Liaison Report

Piers McMahon (ICL) stated that the X/Open Security Working Group has
been working on conformance statements and verification procedures for
GSS-API implementations, and that a description of results and issues in
this area will be forwarded to the CAT list.  Two specific points
(channel binding structures and authoritative indicators of services
available on a security context) were raised and discussed in
conjunction with the base GSS-API and C bindings therefor.


Working Group Charter

The group reviewed the draft, updated charter of the CAT Working Group,
broadened to include, among other points, scope compatible with IDUP
(although not constrained to preclude future work towards return of
evidence objects for enhanced non-repudiation) and with future
authorization support facilities.  The text will be re-sent to the
Security Area Director for approval by the IESG.


Active Working Group Documents


FTP Security

draft-ietf-cat-ftpsec-06.txt

Marc Horowitz (OpenVision) is the new draft author.  A revised draft is
planned for distribution in April, with a target of 1 May for working
group last call in advance of recommendation of that draft for
advancement to Proposed Standard.

Denis Pinkas (Bull) asked whether FTP security was able to provide
authentication in only the server-client direction, without also
authenticating the client to the server.  Marc Horowitz stated that this
is an issue at the level of the underlying GSS-API mechanism rather than
the FTPsec specification, and noted that many GSS-API mechanisms cannot
support this service selection.  The revised FTPsec draft will clarify
the relation between FTPsec and the GSS-V2 anonymity support.

Changes between -05 and -06 of the draft:  Much of the text has been
rewritten and reorganized for clarity.  The CONF command, 633 reply
code, and E data channel protection level were added to support
confidentiality without integrity.  Most policy restrictions have been
relaxed.  In particular, neither encryption nor integrity is required,
and each can be used independently.  The GSSAPI authentication mechanism
has been updated to reflect work on those documents.  Line breaks in
multiline protected replies are no longer required to be on the same
line boundaries as in the plaintext reply.

Some reply codes have been changed due to redundancy, or poor
construction according to the rules in RFC 959, Sec.  4.2:  402 (MIC or
ENC not supported) replaced by 533 (Command protection level denied for
policy reasons); 231 (USER authorized, need dummy password) replaced by
232 (User logged in, authorized by authentication data exchange); 333
(after ADAT exchange, USER requires PASS) replaced by 331 (USER required
PASS, from RFC 959); 502 (Command channel must be protected) replaced by
533; 500 (MIC or ENC before ADAT exchange complete) replaced by 503 (Bad
sequence of commands, from RFC 959); 504 (PROT before PBSZ) replaced by
503; 504 (PBSZ not representable in 32 bits) replaced by 501 (Syntax
error in parameters or arguments, from RFC 959).


Base GSS-API and C Bindings

draft-ietf-cat-gssv2-01.txt
draft-ietf-cat-gssv2-cbind-00.txt

The sense of the group was that backward compatibility with GSS-V1
applications was an important goal, and that call signatures of routines
extant in GSS-V1 should be preserved.  John Wray (DEC) stated that the
current C bindings draft contains three changes which could affect
backward compatibility, leading to discussion.  Discussion specifically
considered flag bits and use of OM_unit32 types.  Shawn Mamros (FTP)
observed that source code compatibility, the basis assumed by at least
most current implementors, has already been achieved.  Piers McMahon
suggested that current caller behavior should (for cases where changes
arise in GSS-V2) be permitted but deprecated.  Specific proposal and
discussion of wording was remanded to the mailing list.

Extended controversy emerged about the proposal for structure and
interpretation of Quality of Protection (QOP) parameters, as made by
Carlisle Adams (BNR) on the mailing list and provisionally included in
draft-ietf-cat-gssv2-01.txt.  Specific contention arose around the
proposed interpretations for mechanism-independent Type Specifier values
for confidentiality and integrity; unless common agreement on these
values can be achieved, the application portability benefit of QOP
structure is limited.  A straw poll at the meeting showed roughly equal
sentiment for rolling back to the text in draft-cat-gssv2-00, for
proceeding with the text in draft-cat-gssv2-01, and for proceeding with
the structure in draft-cat-gssv2-01 but with revised values.  Pending
further discussion, the relevant text in draft-cat-gssv2-01.txt will be
rolled back to the corresponding material from draft-cat-gssv2-00.txt.

Regarding OID support routines, the group agreed to incorporate the set
as proposed by John Wray, augmented by functions as proposed by Dennis
Glatting (CyberSAFE) for conversion of OIDs to and from string
representations.

John Wray described the approach for anonymity support as included in
the current drafts.  A question was raised as to whether credentials
could be acquired under the ``anonymous'' name and used; this case may,
but need not, be supported by a particular mechanism.  John next
introduced issues of semantics for default and dual-mode credentials,
brought into sharp focus through consideration of GSS_Add_cred().  It was
recommended that we recognize that default behavior may differ depending
on whether credential usage for context initiation or acceptance is
being considered.  A specific proposal was made to the mailing list and
is currently being discussed.

John led a discussion on GSS_Process_context_token(), recommending that a
currently-proposed, and backward-incompatible, change to
GSS_Process_context_token(), be expunged.  He suggested that
GSS_Process_context_token() be retained as defined in RFCs 1508/1509 for
compatibility, but deprecated for future use in favor of new
GSS_Refresh_sec_context() and GSS_Maintain_sec_context() routines.  An
alternative approach, accomplishing context renewal with
GSS_Init_sec_context(), GSS_Accept_sec_context(), and/or variants thereof,
was also discussed at the meeting.  Subsequent e-mail identified an
issue with this alternative and reiterated the Refresh/Maintain
proposal; specifics are currently under discussion.

It was agreed that the specifications should comment that interface
implementations need to be self-initializing.

Currently, the level of cross-mechanism support available for
applications using address specifiers within channel bindings is
limited.  There are two candidate approaches to improve this situation:
(1) deprecate use of channel bindings except for application-provided
data, or (2) document, for a selected set of address types, the address
structures to be used with those address types.  Per (2), the address
type list from RFC 1510 was nominated for consideration, and an
implementor survey is now ongoing by e-mail to determine what types are
currently supported and with which structures.

It had been observed that cases can exist within which the service
availability flags returned by GSS_Init_sec_context() and
GSS_Accept_sec_context() are non-authoritative, e.g., when context
establishment is accomplished through transfer of a single token from
initiator to target without a means for the target to return a token to
the initiator indicating inability to support an optional service.  This
was agreed to be an undesirable result; mechanisms should return
authoritative flags, either as a result of exchanging indicator-bearing
tokens to report service availability or by using separate mechanism IDs
to represent different service selection options.  Unless both peers to
a context are known to be able to support an optional service (e.g.,
confidentiality), that service's unavailability should be indicated on
both sides.

Discussion of Parse_token() facilities in SPKM and IDUP (see also
sections dealing with those drafts for related discussions) led to
discussion of whether such a facility could be feasibly implemented
within existing GSS-API mechanisms.  Parse_token(), as currently
implemented, is intended to support demultiplexing in a multi-context
environment and does not perform cryptographic validation.  For a token
to be parsed successfully, it must be associated with a determinable
mechanism, either via an explicit tag, an mech_type input argument (not
currently included, but suggested as a useful option), or implicitly
(e.g., support within a particular implementation for only one mechanism
with untagged tokens).  The Kerberos mechanism tags all tokens; the
SESAME mechanism does not tag non-initial tokens; categorization of
other mechanisms (e.g., KryptoKnight) was unknown and was solicited on
the mailing list.  Implementors are also being surveyed to ascertain the
feasibility of implementing a Parse_token() function within their
mechanisms.


SPKM: Simple Public Key Mechanism

draft-ietf-cat-spkmgss-02.txt

Carlisle Adams gave a presentation on the updated SPKM draft.  Changes
from prior drafts include an added SPKM_Parse_token() facility useful for
disambiguation in environments where multiple contexts are
simultaneously active, specification of mandatory algorithm sets for
interoperability, support for additional name types, and facilities
enabling a context initiator to request that a target return
certification data and/or generate a context's key.  Sequence numbers
are now optional and unencrypted (although integrity-protected), and
algorithm IDs in per-message tokens are optional.  SPKM uses the
GSS_Process_context_token() facility as described in RFC 1508, so would
be affected by an incompatible change to this call.  Delegation is not
supported.

The BNR implementation of SPKM is complete and is in the process of
incorporation into a commercial product.  Don Stephenson (Sun) indicated
that an implementation at Sun was also planned.  The GSS-API sample
application from the MIT Kerberos distribution has been successfully
tested atop this implementation.  Public domain implementation
activities are underway at the University of New Brunswick and are being
initiated at the Queensland Institute of Technology (target date:
September 1995).  The specification is considered to be stable at this
time, pending resolution of an identified issue concerning X9.44 replay
protection, and was placed in working group last call on 5 April 1995
for advancement recommendation to Proposed Standard.


IDUP: Independent Data Unit Protection

draft-ietf-cat-idup-gss-01.txt
draft-ietf-cat-idup-cbind-00.txt

Carlisle Adams and Dragan Grebovich (BNR) gave presentations on the
revised IDUP (renamed from IOP) and associated C bindings
specifications.  To avoid confusion with the base GSS-API security
context construct, the IDUP ``context'' has been renamed to an
``environment.''  Even when encryption is provided, IDUP does not
encapsulate its data buffers into tokens; this allows messages to be
split into multiple buffers but remains controversial, and further
e-mail discussion was solicited.

IDUP allows support for non-repudiation via digital signature, but does
not currently offer calls for processing of provable evidences.  New
calls added in this version:  IDUP_Process_receipt(), IDUP_Parse_token();
IDUP_Extract_prot_token() was deleted.  BNR is currently developing a
commercial IDUP implementation, layered on PEM; public-domain
implementation activities are encouraged.  Some GSS-API major_status
values are irrelevant to IDUP, and some new major_status values are
defined.  Credentials can be shared between GSS-API and IDUP



GSS-API Negotiated Mechanism


This document is not yet an Internet-Draft.

Doug Rosenthal (MCC) summarized ongoing work on a ``negotiated''
pseudo-mechanism for GSS-API, which could be configured as the default
mechanism or requested explicitly by passing its mech_type OID to
GSS_Init_sec_context().  At the Toronto CAT meeting, desires were
expressed for negotiation at the level of mechanism selection, to
simplify interoperability between peers.  The facility being considered
can also support negotiation of options within a mechanism.
Non-intrusiveness to the current GSS-API is a goal.  Denis Pinkas and
Eric Baize (Bull) issued a draft proposal to the list, and comments were
received; Denis and Doug intend to issue a revised proposal as an
Internet-Draft in advance of the July IETF. One open issue:  how to
arbitrate different preference-ordered mechanism/option lists provided
by negotiating peers.



Kerberos (RFC 1510)


Cliff Neuman (ISI) has a list of errata against RFC 1510; the document
is fairly stable with no major discussion topics.  One issue is relevant
to advancing the document to Draft Standard:  the document specifies
that support for MD5 is mandatory, and CRC support optional, but few
implementations support MD5 and only CRC is the current practice for
interoperability.  Cliff will send a message to the list summarizing the
situation, as a basis for action and/or as input to an advancement
recommendation.



Kerberos GSS-API Mechanism

draft-ietf-cat-kerb5gss-02.txt

One issue is known to be active against the Kerberos V5 GSS-API
mechanism Internet-Draft:  the fact that no specific behavior is
documented for implementations electing to support the (optional)
delegation facility.  Initial sense was that this document was ready for
advancement to Proposed Standard.



GSS-API Windows Bindings

draft-ietf-cat-wingss-00.txt

Piers McMahon submitted and discussed this Internet-Draft, related to
GSS-API usage on Windows 3.1 and successor versions.  It is being used
in MIT-directed Cygnus Kerberos porting activities.  Shawn Mamros
observed that the Internet-Draft's structure alignment convention
(4 bytes) diverges from common Windows and WinSock 2-byte practice.
Piers responded that the intent was to support both 16-bit and 32-bit
environments; given, however, a recognition that DLLs for these
environments would likely diverge in any event, it was not seen as
harmful to document them separately with different alignment
conventions.  A revised Internet-Draft will incorporate this change.



Kerberos Extensions:  Public-Key Initial Authentication

draft-ietf-cat-kerberos-pk-init-00.txt

Cliff Neuman led a discussion on this Internet-Draft, reporting that
some comments had been received by e-mail and soliciting further review
and discussion, especially regarding naming and trust path issues.
Implementation activities are currently underway, but not yet complete;
SESAME has implemented functionality similar to parts of the proposal.
The draft's goal is to enable secure recovery from KDC compromise; its
authors believe that its relatively simple extensions for initial
authentication provide perhaps 80% of the benefits which public-key
cryptography can offer to Kerberos.  In the proposed approach, users are
registered with public keys in order to prove (via preauthentication)
their identity to the KDC. Use of a public-key algorithm capable of
encryption (e.g., RSA, elliptic curve) rather than a signature-only
algorithm is required.  Denis Pinkas expressed concern about the export
implications of the implied requirement for use of a strong-length
encryption key, but others observed that the usage described would
likely qualify as ``encryption in support of authentication.''  Users'
private keys can, as one option, be stored (password-encrypted) on the
Kerberos server.



Kerberos Extensions:  Kerberos One-Time Passwords

draft-ietf-cat-kerberos-passwords-00.txt

Glen Zorn (CyberSAFE) led a discussion on this Internet-Draft; a working
update to the draft was sent by e-mail to the CAT list during the IETF
week.  Some questions are embedded in the e-mailed version; a follow-up
Internet-Draft will intercept outstanding issues.  Glen solicited review
and discussion, specifically flagging a need for qualified review of the
proposed ASN.1 syntax.  Identified changes include renamed protocol
fields, inclusion of a previously-missing field for transfer of a
passcode, and support for a list of identified KDCs and for redirection
among them.  Device IDs are to be registered via IANA. Public-key
passcode encryption will be treated in a separate document.  It is
believed that this document represents the first appearance of
user-displayed text within a Kerberos protocol, thereby raising
internationalization issues:  as an approach, it was proposed that a
language identifier be configured for each registered user.  Topic for
investigation:  is the GeneralString type sufficiently general to
accommodate variant character sets?


Secure Socket Layer (SSL) Presentation

Taher Elgamal (NetScape) gave a presentation on Secure Socket Layer
(SSL), developed by NetScape.  A protocol description document is
available, but was not in Internet-Drafts as of the time of the meeting.
A reference implementation (SSLref) is available from NetScape.  SSL
requires TCP or other reliable transport and provides an socket-derived
API; it is intended as a means to protect a range of application-layer
protocols.

SSL provides transaction-oriented privacy, authentication, and integrity
services; it does not provide non-repudiation.  Encryption is always
performed; 40-bit exportable algorithms are supported and indicated with
different algorithm identifiers.  Service negotiation facilities are
included within the SSL protocol; it was observed that key size
negotiation was not itself cryptographically protected.  Supported
algorithms include DES, RC2, RC4, IDEA, triple DES, RSA, master-key
seeded MD5, and MAC. Separate session keys are used in the client-server
and server-client directions; this property was described as desirable
for use with RC4.  In the interests of performance, key generation is
performed using MD5 and a single master key may be reused for generation
of per-connection session keys for multiple TCP connections.  Perfect
forward secrecy is not provided.

SSL is based on (X.509) public-key certificates; a server-side
certificate is required but a client-side certificate (and, therefore,
client authentication to a server) is optional.  A client must possess
an issuer's public key via out-of-band means in order to validate a
server's certificate.  In the current protocol, only a single level of
certification is supported; it was stated, however, that this limitation
is not fundamental and that support for certificate chains could be
incorporated.  Certificate revocation lists (CRLs) are not supported.

Indicated future plans for SSL include Diffie-Hellman key negotiation,
improved certificate management (chains, larger RSA keys, PKCS #7 and
PEM formats), and responses to requests from individuals, organizations,
and standards groups.

Audience questions sought to position SSL relative to existing IETF
Security Area activities.  Relative to IPsec, Taher stated that SSL does
not provide functions which IPsec omits, but offers the virtues of being
available today and of being performable within an application.
Relative to CAT, he observed that SSL was simpler; it was also observed
that SSL might be supportable as a CAT mechanism.  Piers McMahon
commented that SSL was very much like the SOCKS protocol under
discussion in the AFT Working Group, with the exception that SSL, unlike
SOCKS, requires use of new port numbers.


Actions Initiated and Pending

   o SPKM draft (draft-ietf-cat-spkmgss-02.txt) is out for working group
     last call (to close 13 April) for advancement to Proposed Standard;
     one issue concerning replay protection is being checked.

   o Resend revised working group charter to be submitted for IESG
     approval.

   o FTP security Internet-Draft (draft-ietf-cat-ftpsec-06.txt) pending
     specific edit, then to be released for working group last call for
     advancement to Proposed Standard.

   o Updated drafts for GSS-V2 and GSS-V2 C bindings are targeted for
     mid-May, then to be released for working group last call for
     advancement as Proposed or Draft Standards.

   o Denis Pinkas to send summary of QOP position.

   o Denis Pinkas and Doug Rosenthal to issue revised negotiated
     mechanism Internet-Draft in advance of July meeting.

   o Revised GSS-API Windows bindings Internet-Draft pending.

   o Cliff Neuman to send summary of RFC 1510 checksum issue.