CAT-WG Last-Call: draft-ietf-cat-ftpdsaauth-00.txt

["Linn, John" <[e-mail]>]

CAT/FTPsec fanciers:

Per discussion at the DC IETF, this message is to open a CAT-WG
Last-Call on draft-ietf-cat-ftpdsaauth-00.txt, "FTP Authentication using
DSA", which profiles the use of FTP Security Extensions (RFC-2228) with
DSA and SHA-1 algorithms.  Please send any discussion or comments on
this draft and its prospective recommendation for advancement to
Proposed Standard to the CAT-WG list NLT Tuesday, 3 February 1998.  

Note: Per RFC-2026 ("The Internet Standards Process - Revision 3"), sec.
4.1.1, IESG Proposed Standard advancement decisions require that a
document has received significant community review and apparent
community interest, and discussion of this draft has so far been
relatively quiet.  To aid in supporting this document's progression per
the RFC-2026 criteria, it would be helpful if readers and reviewers of
draft-ietf-cat-ftpdsaauth-00 were to identify themselves to the list
during the WG Last-Call even if no comments need be made against the
draft's content.

Thanks, ...

--jl

Date: Fri, 09 Jan 1998 08:37:59 -0600
From: Doug Engert <[e-mail]>
Reply-To: [e-mail]
Organization: Argonne National Laboratory
To: Carlisle Adams <[e-mail]>
Cc: [e-mail]
Subject: GSSAPI-SPKM

Carlisle,

Are there any implementations of GSSAPI which implement
SPKM - RFC-2025? Either comercial products or source code? 

Is the Entrust product RFC-2025 compliant? 

If there are more then one, has there been an
interoperability testing? 

Thanks. 

-- 

 Douglas E. Engert  <[e-mail]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 [phone]

To: [e-mail], [e-mail]
Subject: Contents of e-data with KDC_ERR_PREAUTH_REQUIRED
X-Emacs: 19.34
From: [e-mail] (Johan Danielsson)
Date: 11 Jan 1998 01:20:41 +0100
Lines: 26


If the client is required to use pre-authentication, what should the
KDC return in the e-data field?

Suppose I have a database with a list of keys for each principal. Each
key corresponds to the same password, but are different because they
are used with different crypto-systems, and/or because they are salted
differently.

What I would like to return is a list of keytype/salt-pairs, but there
isn't any documented way to do this. I believe that the MIT KDC uses
the PA-ETYPE-INFO padata-type for something similar. I basically want
something like this:

PA-KEY-INFO ::= SEQUENCE {
	keytype[1]	INTEGER,
	salttype[2]	INTEGER,
	salt[3]		OCTET STRING
}


Generally, the various structures that has OCTET STRINGs instead of
CHOICEs, need better descriptions of the intended use of the `opaque'
data.

/Johan