CAT minutes for Danvers IETF

[John Linn <[e-mail]>]

CAT minutes, Danvers IETF, 4-5 April 1995. 

Minutes reported by John Linn (OpenVision). 

LIAISON REPORT

Piers McMahon (ICL) stated that the X/Open Security WG 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
(regarding 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.

WG CHARTER

We reviewed the draft updated CAT WG charter, 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 area director for
approval by the IESG.

ACTIVE WG DOCUMENTS AND DISCUSSIONS THEREOF

FTP Security (draft-ietf-cat-ftpsec-06.txt):

New draft author: Marc Horowitz (OpenVision), [e-mail].  A
revised draft is planned for distribution in April, with a target of 1
May for WG 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 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, we 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
initator 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 re X9.44 replay protection, and was placed in WG 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 (not yet in 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 I-D'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 I-D 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; an
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 accomodate 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

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 re replay protection being checked.

Resend revised WG charter to be submitted for IESG approval.

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

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.

Denis Pinkas to send summary of QOP position.

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

Revised GSS-API Windows bindings I-D pending. 

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