Future of RFC 1731

John Gardiner Myers <jgm+@cmu.edu> Wed, 21 June 1995 18:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07201; 21 Jun 95 14:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07197; 21 Jun 95 14:48 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12822; 21 Jun 95 14:48 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.12/) with SMTP id <OAA25677@pad-thai.cam.ov.com>; Wed, 21 Jun 1995 14:06:01 -0400
Received: from PO4.ANDREW.CMU.EDU by MIT.EDU with SMTP id AA04430; Wed, 21 Jun 95 14:05:12 EDT
Received: (from postman@localhost) by po4.andrew.cmu.edu (8.6.12/8.6.12) id OAA01788 for cat-ietf@mit.edu; Wed, 21 Jun 1995 14:05:07 -0400
Received: via switchmail; Wed, 21 Jun 1995 14:05:03 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Iju5wNO00WBwI0W9hE>; Wed, 21 Jun 1995 14:04:09 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.gju5wM200WBwE9xpkB>; Wed, 21 Jun 1995 14:04:08 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 21 Jun 1995 14:04:04 -0400 (EDT)
Message-Id: <Yju5wI600WBwQ9xpZR@andrew.cmu.edu>
Date: Wed, 21 Jun 1995 14:04:04 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+@cmu.edu>
To: cat-ietf@mit.edu
Subject: Future of RFC 1731
Beak: is Not

I've been talking to a number of people about taking the RFC 1731
protocols and writing them up as a generic security protocol, not as
something specific to IMAP4.  The IMAP4 security work has a lot of
potential for use elsewhere; it has been applied to POP3 (RFC 1734),
is being proposed for use in SMTP (draft-myers-smtp-auth-01.txt), and
I just recently suggested it be used in LDAP.  I think it would be
good to shift the focus of the RFC 1731 protocols away from IMAP.

Basically, 1731 is a method for adding strong authentication to
single-connection protocols.  It is based on the FTP security work,
but greatly simplified.  The client identifies an authentication
method to the server, initiating an authentication token exchange.
The contents of the tokens are specified by 1731, but their encoding
for transfer over the connection is specific to the protocol, as
necessary to fit the structure and syntax of the protocol.  When
negotiated, what is effectively a session layer is inserted after
authentication is complete between the connection and the protocol, to
provide protection of the rest of the session.

This could fill a lot of the need people see for a simplified
stream-based GSSAPI.

A possible generic name for this would be "Simple Authentication and
Session Layer" or "Strong Authentication and Session Layer".

I've asked for a few minutes of WG time to discuss this idea.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up