One document matched: draft-ietf-cat-ftpdsaauth-03.txt
Differences from draft-ietf-cat-ftpdsaauth-02.txt
CAT Working Group Russell Housley (SPYRUS)
<draft-ietf-cat-ftpdsaauth-03.txt> William A. Nace (NSA)
Updates: RFC 959 Peter Yee (SPYRUS)
Internet-Draft Expire in six months
December 1999
FTP Authentication Using DSA
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Please send comments to
yee@spyrus.com.
Abstract
This document defines a method to secure file transfers using the FTP
specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985)
and RFC 2228 "FTP Security Extensions" (October 1997) [1]. This
method will use the extensions proposed in the "FTP Security
Extensions" along with a public/private digital signature.
1 Introduction
The File Transfer Protocol (FTP) provides no protocol security except
for a user authentication password which is transmitted in the clear.
Housley, Nace & Yee [Page 1]
INTERNET DRAFT December 3, 1999
In addition, the protocol does not protect the file transfer session
beyond the original authentication phase.
The Internet Engineering Task Force (IETF) Common Authentication
Technology (CAT) Working Group has specified security extensions to
FTP. These extensions allow the protocol to use more flexible
security schemes, and in particular allows for various levels of
protection for the FTP command and data connections. This document
describes a profile for the FTP Security Extensions by which these
mechanisms may be provisioned using the DSA[2] and SHA-1[3]
algorithms. The FTP Security Extensions do not attempt to provide
for security when FTP is used in proxy mode. The profile proposed in
this document does not remove this limitation.
2 FTP Security Extensions
The IETF CAT Working Group has produced an Internet Draft that seeks
to improve the security of FTP. This Internet Draft is likely to
become a standards track RFC in 1997. It provides:
* user authentication -- augmenting the normal password mechanism;
* server authentication -- done in conjunction with user
authentication or authenticates the server to an anonymous user;
* session parameter negotiation -- in particular, encryption keys
and attributes;
* command connection protection -- integrity, confidentiality, or
both;
* data transfer protection -- same as for command connection
protection.
In order to support the above security services, the two FTP entities
negotiate a mechanism. This process is open-ended and completes when
both entities agree on an acceptable mechanism or when the initiating
party (always the client) is unable to suggest an agreeable
mechanism. Once the entities agree upon a mechanism, they may
commence authentication and/or parameter negotiation.
Authentication and parameter negotiation occur within an unbounded
series of exchanges. At the completion of the exchanges, the
entities will either be authenticated (unilateral or mutually), and
may be ready to protect FTP commands and data.
Following the exchanges, the entities negotiate the size of the
Housley, Nace & Yee [Page 2]
INTERNET DRAFT December 3, 1999
buffers they will use in protecting the commands and data that
follow. This process is accomplished in two steps: the client offers
a suggested buffer size and the server may either refuse it, counter
it, or accept it.
At this point, the entities may issue protected commands within the
bounds of the parameters negotiated through the security exchanges.
Protected commands are issued by applying the protection services
required to the normal commands and Base64 encoding the results. The
encoded results are sent as the data field within a MIC (integrity).
Base64 is an encoding for mapping binary data onto a textual
character set that is able to pass through 7-bit systems without
loss. The server sends back responses in new result codes which
allow the identical protections and Base64 encoding to be applied to
the results. Protection of the data transfers can be specified via
the PROT command which supports the same protections as those
afforded the other FTP commands. PROT commands may be sent on a
transfer-by-transfer basis; however, the session parameters, such as
PBSZ, may not be changed without sending another AUTH command. Be
aware that support for subsequent AUTH commands may not be permitted
by all implementations.
3 Use of Digital Signature Algorithm (DSA)
This paper a profile in which DSA may be used to achieve certain
security services when used in conjunction with the FTP Security
Extensions framework. As stated above, the reader should be familiar
with the extensions in order to understand the protocol steps that
follow. In the context of the FTP Security Extensions, we use DSA
with SHA-1 for authentication and integrity.
3.1 DSA Profile
FTP entities may use DSA to give either unilateral or mutual
authentication as well as to provide integrity services for commands
and data transfers. This specification follows the tokens and
exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1
encoding of messages and tokens.
3.1.1 Unilateral Authentication with DSA
A client may unilaterally authenticate its identity to a server.
What follows are the protocol steps necessary to perform DSA
authentication as specified in FIPS PUB 196 under the FTP Security
Extensions framework. Where failure modes are encountered, the
return codes follow those specified in the Extensions. They are not
enumerated here as they are invariant among mechanisms. FIPS PUB 196
employs a set of exchanges which are transferred to provide
Housley, Nace & Yee [Page 3]
INTERNET DRAFT December 3, 1999
authentication. Each exchange employs various fields and tokens,
some of which are optional. In addition, each token has several
subfields that are optional. A conformant subset of the fields and
subfields for use with FTP have been selected. Therefore, the
exchanges below do not show the FIPS PUB 196 notation indicating
optional fields, while only the mandatory subfields are allowed. The
tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each
token is named to indicate the direction in which it flows (i.e.,
TokenBA flows from Party B to Party A). In Figure 1, the client
binds the last transmission (token identifier, certificate, and
token) together as an ASN.1 SEQUENCE.
The exchanges detailed below presume a knowledge of FIPS PUB 196 and
the FTP Security Extensions. The client is Party A, while the server
is Party B. The notation for concatenation is " || ". The pseudo-
function Sequence is used to indicate that its parameters are to be
joined as an ASN.1 SEQUENCE. Verification of signed data, and in
particular certification path verification is implicitly assumed, but
is not shown.
---------------------------------------------------------------------
Client Server
AUTH DSS-CLIENT-UNILATERAL -->
<-- 334 ADAT=Base64(Sequence(
TokenID || TokenBA))
ADAT Base64(Sequence(TokenID ||
CertA || TokenAB ||
absigValue)) -->
<-- 234
---------------------------------------------------------------------
Figure 1
With this example, the client is now authenticated to the server.
Additional functionality available to client and server includes the
use of MIC protected commands and the ability to send signed data.
The Sign function used in the figures below appends a nonce to the
end of the parameter, and then computes a DSA with SHA-1 signature
over the parameter followed by a nonce. The 40 octet signature
value, as described in FIPS PUB 186, is composed of two 20 octet
values, r followed by s. The nonce is comprised of a two octet
command counter and the Ra value from TokenAB. Since both the client
and server have the Ra value from TokenAB and both can calculate the
command counter, the nonce is not transmitted. The command counter
is initialized to the least significant two octets of the Ra value
from TokenAB, and it is incremented each time the client issues a
command. The Sign function output is composed of the 40 octet
signature value followed by the parameter. An example follows:
Housley, Nace & Yee [Page 4]
INTERNET DRAFT December 3, 1999
---------------------------------------------------------------------
Client Server
MIC Base64(Sign("PBSZ 65535")) -->
<-- 200 PBSZ=32767
MIC Base64(Sign("USER yee")) -->
<-- 331
MIC Base64(Sign("PASS fortezza")) -->
<-- 230
MIC Base64(Sign("PROT S")) -->
<-- 200
MIC Base64(Sign("STOR foo.bar")) -->
<-- 150
---------------------------------------------------------------------
Figure 2
Data now flows from the client to the server as specified in the
Extensions. Specifically, the file is broken up into blocks of data
of less than the negotiated protection buffer size (32767 bytes in
the example exchanges). Each protection buffer contains a safe token
followed by file data. A common safe token structure is used for
unilateral and mutual authentication. The safe token structure is
described in section 3.1.3.
3.1.2 Mutual Authentication with DSA
The PDU flow for mutual authentication is slightly more complex, as
shown:
---------------------------------------------------------------------
Client Server
AUTH DSS-MUTUAL -->
<-- 334 ADAT=Base64(Sequence(
TokenID || TokenBA1))
ADAT Base64(Sequence(TokenID ||
CertA || TokenAB ||
absigValue)) -->
<-- 235 ADAT=Base64(Sequence(
TokenID || CertB ||
TokenBA2 || ba2sigValue))
---------------------------------------------------------------------
Figure 3
Data retrieval and other FTP operations can now be performed with
signature protection. As before, the FTP entities negotiate a
protection buffer size. Likewise, a two octet command counter
combined with the Ra value from TokenAB is used as a nonce in the
Housley, Nace & Yee [Page 5]
INTERNET DRAFT December 3, 1999
Sign function.
---------------------------------------------------------------------
Client Server
MIC Base64(Sign("PBSZ 65535")) -->
<-- 631 Base64(Sign
("200 PBSZ=32767"))
MIC Base64(Sign("USER yee")) -->
<-- 631 Base64(Sign("331"))
MIC Base64(Sign("PASS fortezza")) -->
<-- 631 Base64(Sign("230"))
MIC Base64(Sign("PROT S")) -->
<-- 631 Base64(Sign("200"))
MIC Base64(Sign("RETR foo.bar")) -->
---------------------------------------------------------------------
Figure 4
Data now flows from the client to the server as well as the server to
the client as specified in the Extensions. Specifically, the file is
broken up into blocks of data of less than the negotiated protection
buffer size. Each protection buffer contains a safe token followed
by file data. A common safe token structure is used for unilateral
and mutual authentication. The safe token structure is described in
section 3.1.3.
3.1.3 File Protection with DSA
The next figure shows the structure of the safe token and file data.
---------------------------------------------------------------------
Signature 40 octets
Buffer Size 4 octets
Nonce 8 octets
File Count 2 octets
Buffer Count 4 octets
File Data Buffer Buffer Size
---------------------------------------------------------------------
Figure 5
The safe token is comprised of the signature value, buffer size,
nonce, file count, and buffer count. The signature covers the buffer
size, nonce, file count, buffer count, and the file data buffer.
Buffer size is the number of octets contained in file data buffer.
This buffer size must be less than the negotiated PBSZ value, and the
maximum buffer size is PBSZ minus 58. If the buffer size is not
equal to PBSZ minus 58, then this buffer is the final buffer of the
file. If the file ends on a full buffer boundary, a buffer with the
Housley, Nace & Yee [Page 6]
INTERNET DRAFT December 3, 1999
buffer size set to zero will be sent. The nonce is the least
significant 64 bits of the Rb field of TokenBA1. File count is a
sequence counter of protected files transferred, starting at zero.
Buffer count is the number of protected buffers sent for this file,
starting at zero.
4.0 Security Considerations
This entire memo is about security mechanisms. For DSA to provide
the authentication discussed, the implementation must protect the
private key from disclosure.
5.0 Acknowledgements
I would like to thank Todd Horting for insights gained during
implementation of this specification.
6.0 References
[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.
RFC 2228, October, 1997
[2] - Digital Signature Standard (DSS). FIPS Pub 186.
May 19, 1994.
[3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.
[4] - Standard for Entity Authentication Using Public Key
Cryptography. FIPS Pub 196. February 18, 1997.
Housley, Nace & Yee [Page 7]
INTERNET DRAFT December 3, 1999
7.0 Author's Address
Russell Housley
SPYRUS
381 Elden Street
Suite 1120
Herndon, VA 20170
USA
Email: housley@spyrus.com
DIRNSA
Attn: X22 (W. Nace)
9800 Savage Road
Fort Meade, MD 20755-6000
USA
Email: WANace@missi.ncsc.mil
Peter Yee
SPYRUS
5303 Betsy Rose Drive
Santa Clara, CA 95054
USA
Email: yee@spyrus.com
Housley, Nace & Yee [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 05:46:43 |