draft-ietf-cat-ftpdsaauth-00.txt   draft-ietf-cat-ftpdsaauth-01.txt 
CAT Working Group Russell Housley (SPYRUS) CAT Working Group Russell Housley (SPYRUS)
<draft-ietf-cat-ftpdsaauth-00.txt> William A. Nace (NSA) <draft-ietf-cat-ftpdsaauth-01.txt> William A. Nace (NSA)
Updates: RFC 959 Peter Yee (SPYRUS) Updates: RFC 959 Peter Yee (SPYRUS)
Internet-Draft Expire in six months Internet-Draft Expire in six months
February 1998
FTP Authentication Using DSA FTP Authentication Using DSA
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc- This document is an Internet-Draft. Internet-Drafts are working
uments of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas,
its working groups. Note that other groups may also distribute work- and its working groups. Note that other groups may also distribute
ing documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are Draft documents valid for a maximum of six months Internet-Drafts are Draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate- time. It is inappropriate to use Internet-Drafts as reference
rial or to cite them other than as ''work in progress.'' material or to cite them other than as ''work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow "1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited. Please send comments to the Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list. <cat-ietf@mit.edu> mailing list.
Abstract Abstract
This document defines a method to secure file transfers using the FTP This document defines a method to secure file transfers using the FTP
specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985) specification RFC 959, ''FILE TRANSFER PROTOCOL (FTP)'' (October 1985)
and the work in progress document "FTP Security Extensions" <Draft- and the work in progress document ''FTP Security Extensions'' <Draft-
ietf-cat-ftpsec-09.txt>[1]. This method will use the extensions pro- ietf-cat-ftpsec-09.txt>[1]. This method will use the extensions
posed in the "FTP Security Extensions" Draft document along with a proposed in the ''FTP Security Extensions'' Draft document along with a
public/private digital signature. public/private digital signature.
1 Introduction 1 Introduction
The File Transfer Protocol (FTP) provides no protocol security except The File Transfer Protocol (FTP) provides no protocol security except
for a user authentication password which is transmitted in the clear. for a user authentication password which is transmitted in the clear.
In addition, the protocol does not protect the file transfer session In addition, the protocol does not protect the file transfer session
beyond the original authentication phase. beyond the original authentication phase.
The Internet Engineering Task Force (IETF) Common Authentication The Internet Engineering Task Force (IETF) Common Authentication
Technology (CAT) Working Group has specified security extensions to Technology (CAT) Working Group has specified security extensions to
FTP. These extensions allow the protocol to use more flexible secu- FTP. These extensions allow the protocol to use more flexible
rity schemes, and in particular allows for various levels of protec- security schemes, and in particular allows for various levels of
tion for the FTP command and data connections. This document protection for the FTP command and data connections. This document
describes a profile for the FTP Security Extensions by which these describes a profile for the FTP Security Extensions by which these
mechanisms may be provisioned using the DSA[2] and SHA-1[3] algo- mechanisms may be provisioned using the DSA[2] and SHA-1[3]
rithms. The FTP Security Extensions do not attempt to provide for algorithms. The FTP Security Extensions do not attempt to provide
security when FTP is used in proxy mode. The profile proposed in for security when FTP is used in proxy mode. The profile proposed in
this document does not remove this limitation. this document does not remove this limitation.
2 FTP Security Extensions 2 FTP Security Extensions
The IETF CAT Working Group has produced an Internet Draft that seeks The IETF CAT Working Group has produced an Internet Draft that seeks
to improve the security of FTP. This Internet Draft is likely to to improve the security of FTP. This Internet Draft is likely to
become a standards track RFC in 1997. It provides: become a standards track RFC in 1997. It provides:
* user authentication -- augmenting the normal password mechanism; * user authentication -- augmenting the normal password mechanism;
* server authentication -- normally done in conjunction with user * server authentication -- done in conjunction with user
authentication; authentication or authenticates the server to an anonymous user;
* session parameter negotiation -- in particular, encryption keys * session parameter negotiation -- in particular, encryption keys
and attributes; and attributes;
* command connection protection -- integrity, confidentiality, or * command connection protection -- integrity, confidentiality, or
both; both;
* data transfer protection -- same as for command connection * data transfer protection -- same as for command connection
protection. protection.
In order to support the above security services, the two FTP entities In order to support the above security services, the two FTP entities
negotiate a mechanism. This process is open-ended and completes when negotiate a mechanism. This process is open-ended and completes when
both entities agree on an acceptable mechanism or when the initiating both entities agree on an acceptable mechanism or when the initiating
party (always the client) is unable to suggest an agreeable mecha- party (always the client) is unable to suggest an agreeable
nism. Once the entities agree upon a mechanism, they may commence mechanism. Once the entities agree upon a mechanism, they may
authentication and/or parameter negotiation. commence authentication and/or parameter negotiation.
Authentication and parameter negotiation occur within an unbounded Authentication and parameter negotiation occur within an unbounded
series of exchanges. At the completion of the exchanges, the enti- series of exchanges. At the completion of the exchanges, the
ties will either be authenticated (unilateral or mutually), and may entities will either be authenticated (unilateral or mutually), and
be ready to protect FTP commands and data. may be ready to protect FTP commands and data.
Following the exchanges, the entities negotiate the size of the Following the exchanges, the entities negotiate the size of the
buffers they will use in protecting the commands and data that fol- buffers they will use in protecting the commands and data that
low. This process is accomplished in two steps: the client offers a follow. This process is accomplished in two steps: the client offers
suggested buffer size and the server may either refuse it, counter a suggested buffer size and the server may either refuse it, counter
it, or accept it. it, or accept it.
At this point, the entities may issue protected commands within the At this point, the entities may issue protected commands within the
bounds of the parameters negotiated through the security exchanges. bounds of the parameters negotiated through the security exchanges.
Protected commands are issued by applying the protection services Protected commands are issued by applying the protection services
required to the normal commands and Base64 encoding the results. The required to the normal commands and Base64 encoding the results. The
encoded results are sent as the data field within a MIC (integrity). encoded results are sent as the data field within a MIC (integrity).
Base64 is an encoding for mapping binary data onto a textual charac- Base64 is an encoding for mapping binary data onto a textual
ter set that is able to pass through 7-bit systems without loss. The character set that is able to pass through 7-bit systems without
server sends back responses in new result codes which allow the iden- loss. The server sends back responses in new result codes which
tical protections and Base64 encoding to be applied to the results. allow the identical protections and Base64 encoding to be applied to
Protection of the data transfers can be specified via the PROT com- the results. Protection of the data transfers can be specified via
mand which supports the same protections as those afforded the other the PROT command which supports the same protections as those
FTP commands. PROT commands may be sent on a transfer-by-transfer afforded the other FTP commands. PROT commands may be sent on a
basis, however, the session parameters may not be changed within a transfer-by-transfer basis; however, the session parameters, such as
session. 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) 3 Use of Digital Signature Algorithm (DSA)
This paper a profile in which DSA may be used to achieve certain This paper a profile in which DSA may be used to achieve certain
security services when used in conjunction with the FTP Security security services when used in conjunction with the FTP Security
Extensions framework. As stated above, the reader should be familiar Extensions framework. As stated above, the reader should be familiar
with the extensions in order to understand the protocol steps that with the extensions in order to understand the protocol steps that
follow. In the context of the FTP Security Extensions, we use DSA follow. In the context of the FTP Security Extensions, we use DSA
with SHA-1 for authentication and integrity. with SHA-1 for authentication and integrity.
3.1 DSA Profile 3.1 DSA Profile
FTP entities may use DSA to give either unilateral or mutual authen- FTP entities may use DSA to give either unilateral or mutual
tication as well as to provide integrity services for commands and authentication as well as to provide integrity services for commands
data transfers. This specification follows the tokens and exchanges and data transfers. This specification follows the tokens and
defined in FIPS PUB 196[4], including Appendix A on ASN.1 encoding of exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1
messages and tokens. encoding of messages and tokens.
3.1.1 Unilateral Authentication with DSA 3.1.1 Unilateral Authentication with DSA
A client may unilaterally authenticate its identity to a server. A client may unilaterally authenticate its identity to a server.
What follows are the protocol steps necessary to perform DSA authen- What follows are the protocol steps necessary to perform DSA
tication as specified in FIPS PUB 196 under the FTP Security Exten- authentication as specified in FIPS PUB 196 under the FTP Security
sions framework. Where failure modes are encountered, the return Extensions framework. Where failure modes are encountered, the
codes follow those specified in the Extensions. They are not enumer- return codes follow those specified in the Extensions. They are not
ated here as they are invariant among mechanisms. FIPS PUB 196 enumerated here as they are invariant among mechanisms. FIPS PUB 196
employs a set of exchanges which are transferred to provide authenti- employs a set of exchanges which are transferred to provide
cation. Each exchange employs various fields and tokens, some of authentication. Each exchange employs various fields and tokens,
which are optional. In addition, each token has several subfields some of which are optional. In addition, each token has several
that are optional. A conformant subset of the fields and subfields subfields that are optional. A conformant subset of the fields and
for use with FTP have been selected. Therefore, the exchanges below subfields for use with FTP have been selected. Therefore, the
do not show the FIPS PUB 196 notation indicating optional fields, exchanges below do not show the FIPS PUB 196 notation indicating
while only the mandatory subfields are allowed. The tokens are ASN.1 optional fields, while only the mandatory subfields are allowed. The
encoded per Appendix A of FIPS PUB 196, and each token is named to tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each
indicate the direction in which it flows (i.e., TokenBA flows from token is named to indicate the direction in which it flows (i.e.,
Party B to Party A). In Figure 1, the client binds the last trans- TokenBA flows from Party B to Party A). In Figure 1, the client
mission (token identifier, certificate, and token) together as an binds the last transmission (token identifier, certificate, and
ASN.1 sequence. token) together as an ASN.1 sequence.
The exchanges detailed below presume a knowledge of FIPS PUB 196 and The exchanges detailed below presume a knowledge of FIPS PUB 196 and
the FTP Security Extensions. The client is Party A, while the server the FTP Security Extensions. The client is Party A, while the server
is Party B. The notation for concatenation is " || ". The pseudo- is Party B. The notation for concatenation is " || ". The pseudo-
function Sequence is used to indicate that its parameters are to be function Sequence is used to indicate that its parameters are to be
joined as an ASN.1 SEQUENCE. Verification of signed data, and in joined as an ASN.1 SEQUENCE. Verification of signed data, and in
particular certification path verification is implicitly assumed, but particular certification path verification is implicitly assumed, but
is not shown. is not shown.
--------------------------------------------------------------------- ---------------------------------------------------------------------
skipping to change at page 4, line 38 skipping to change at page 4, line 40
<-- 234 <-- 234
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 1 Figure 1
With this example, the client is now authenticated to the server. With this example, the client is now authenticated to the server.
Additional functionality available to client and server includes the Additional functionality available to client and server includes the
use of MIC protected commands and the ability to send signed data. 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 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 end of the parameter, and then computes a DSA with SHA-1 signature
over the parameter followed by a nonce. The 40 octet 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 val- value, as described in FIPS PUB 186, is composed of two 20 octet
ues, r followed by s. The nonce is comprised of a two octet command values, r followed by s. The nonce is comprised of a two octet
counter and the Ra value from TokenAB. Since both the client and command counter and the Ra value from TokenAB. Since both the client
server have the Ra value from TokenAB and both can calculate the com- and server have the Ra value from TokenAB and both can calculate the
mand counter, the nonce is not transmitted. The command counter is command counter, the nonce is not transmitted. The command counter
initialized to the least significant two octets of the Ra value from is initialized to the least significant two octets of the Ra value
TokenAB, and it is incremented each time the client issues a command. from TokenAB, and it is incremented each time the client issues a
The Sign function output is composed of the 40 octet signature value command. The Sign function output is composed of the 40 octet
followed by the parameter. An example follows: signature value followed by the parameter. An example follows:
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
MIC Base64(Sign("PBSZ 65535")) --> MIC Base64(Sign("PBSZ 65535")) -->
<-- 200 PBSZ=32767 <-- 200 PBSZ=32767
MIC Base64(Sign("USER yee")) --> MIC Base64(Sign("USER yee")) -->
<-- 331 <-- 331
MIC Base64(Sign("PASS fortezza")) --> MIC Base64(Sign("PASS fortezza")) -->
<-- 230 <-- 230
MIC Base64(Sign("PROT S")) --> MIC Base64(Sign("PROT S")) -->
<-- 200 <-- 200
MIC Base64(Sign("STOR foo.bar")) --> MIC Base64(Sign("STOR foo.bar")) -->
<-- 150 <-- 150
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2 Figure 2
Data now flows from the client to the server as specified in the Data now flows from the client to the server as specified in the
Extensions. Specifically, the file is broken up into blocks of data Extensions. Specifically, the file is broken up into blocks of data
of less than the negotiated protection buffer size (32768 bytes in of less than the negotiated protection buffer size (32767 bytes in
the example exchanges). Each protection buffer contains a safe token the example exchanges). Each protection buffer contains a safe token
followed by file data. A common safe token structure is used for followed by file data. A common safe token structure is used for
unilateral and mutual authentication. The safe token structure is unilateral and mutual authentication. The safe token structure is
described in section 3.1.3. described in section 3.1.3.
3.1.2 Mutual Authentication with DSA 3.1.2 Mutual Authentication with DSA
The PDU flow for mutual authentication is slightly more complex, as The PDU flow for mutual authentication is slightly more complex, as
shown: shown:
skipping to change at page 5, line 50 skipping to change at page 5, line 50
ADAT Base64(Sequence(TokenID || ADAT Base64(Sequence(TokenID ||
CertA || TokenAB || CertA || TokenAB ||
absigValue)) --> absigValue)) -->
<-- 235 ADAT=Base64(Sequence( <-- 235 ADAT=Base64(Sequence(
TokenID || CertB || TokenID || CertB ||
TokenBA2 || ba2sigValue)) TokenBA2 || ba2sigValue))
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 3 Figure 3
Data retrieval and other FTP operations can now be performed with Data retrieval and other FTP operations can now be performed with
signature protection. As before, the FTP entities negotiate a pro- signature protection. As before, the FTP entities negotiate a
tection buffer size. Likewise, a two octet command counter combined protection buffer size. Likewise, a two octet command counter
with the Ra value from TokenAB is used as a nonce in the Sign combined with the Ra value from TokenAB is used as a nonce in the
function. Sign function.
--------------------------------------------------------------------- ---------------------------------------------------------------------
Client Server Client Server
MIC Base64(Sign("PBSZ 65535")) --> MIC Base64(Sign("PBSZ 65535")) -->
<-- 631 Base64(Sign <-- 631 Base64(Sign
("200 PBSZ=32767")) ("200 PBSZ=32767"))
MIC Base64(Sign("USER yee")) --> MIC Base64(Sign("USER yee")) -->
<-- 631 Base64(Sign("331")) <-- 631 Base64(Sign("331"))
MIC Base64(Sign("PASS fortezza")) --> MIC Base64(Sign("PASS fortezza")) -->
skipping to change at page 7, line 4 skipping to change at page 7, line 4
Figure 5 Figure 5
The safe token is comprised of the signature value, buffer size, The safe token is comprised of the signature value, buffer size,
nonce, file count, and buffer count. The signature covers the buffer nonce, file count, and buffer count. The signature covers the buffer
size, nonce, file count, buffer count, and the file data buffer. size, nonce, file count, buffer count, and the file data buffer.
Buffer size is the number of octets contained in 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 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 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 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 file. If the file ends on a full buffer boundary, a buffer with the
buffer size set to zero will be sent. The nonce is the least signif- buffer size set to zero will be sent. The nonce is the least
icant 64 bits of the Rb field of TokenBA1. File count is a sequence significant 64 bits of the Rb field of TokenBA1. File count is a
counter of protected files transferred, starting at zero. Buffer sequence counter of protected files transferred, starting at zero.
count is the number of protected buffers sent for this file, starting Buffer count is the number of protected buffers sent for this file,
at zero. starting at zero.
4.0 Security Considerations 4.0 Security Considerations
This entire memo is about security mechanisms. For DSA to provide This entire memo is about security mechanisms. For DSA to provide
the authentication discussed, the implementation must protect the the authentication discussed, the implementation must protect the
private key from disclosure. private key from disclosure.
5.0 Acknowledgements 5.0 Acknowledgements
I would like to thank Todd Horting for insights gained during imple- I would like to thank Todd Horting for insights gained during
mentation of this specification. implementation of this specification.
6.0 References 6.0 References
[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.
Internet-Draft <draft-ietf-cat-ftpsec-09.txt>, Internet-Draft <draft-ietf-cat-ftpsec-09.txt>,
November, 1996. November, 1996.
[2] - Digital Signature Standard (DSS). FIPS Pub 186. [2] - Digital Signature Standard (DSS). FIPS Pub 186.
May 19, 1994. May 19, 1994.
 End of changes. 19 change blocks. 
80 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/