Tải bản đầy đủ
4 TFTP ( trivial file transfer protocol)

4 TFTP ( trivial file transfer protocol)

Tải bản đầy đủ

426

Data networking and Internet applications

Figure 10.9

Typical uses of TFTP (trivial file transfer protocol).

Figure 10.10 TFTP (trivial file transfer protocol): RRQ, WRQ and ACK message packet formats.

TFTP (trivial file transfer protocol)

427

The TFTP file transfer process is established by first sending a request message — either a
WRQ (write request) or a RRQ (read request). Provided a positive reply is received, the file
transfer may begin. An ACK (acknowledgement) packet represents a ‘permission’ to write (i.e.,
to send a packet to the remote end). The positive reply to a read request (RRQ) is a response
containing the first data packet of the file requested.
The header of all TFTP packets (Figure 10.10) consists of a 2-byte opcode field (Table 10.5)
which indicates the TFTP packet-type.
Table 10.5 TFTP packet types and opcode values
TFTP opcode
1
2
3
4
5

Operation
RRQ
WRQ
DATA
ACK
ERROR

Full name
Read request
Write request
Data packet
Acknowledgement
Error

RRQ (read request) and WRQ (write request) packets, as shown in Figure 10.10a, include
the TFTP opcode (value ‘1’ or ‘2’), the name of the file to be transmitted (in a text string
format), a NULL octet and then the mode in which it is to be transmitted (again indicated as a
character string in NVT-ASCII character format). A further NULL octet completes the RRQ
or WRQ packet.
The ACK (acknowledgement) packet (Figure 10.10b) is initially returned with the block
number set at 1. The acknowledgement indicates the number of the next expected data block.
Should the response to an RRQ or WRQ message be an error packet (opcode = ‘5’), then the
request has been denied.
Each data packet includes the TFTP block number, consecutively numbered starting at 1.
This is used for data flow control, as we discussed in detail in Chapter 3. Following the opcode
(set at value ‘3’) and the block number (which is incremented for each successive packet),
comes the data itself (Figure 10.11a). A TID (terminal identification) is chosen randomly by

Figure 10.11 TFTP (trivial file transfer protocol): data and error message packet formats.

428

Data networking and Internet applications
Table 10.6 TFTP (trivial file transfer protocol) error message code
values
Error code value

Meaning

0
1
2
3
4
5
6
7

Not defined, see textual error message (if any)
File not found
Access violation
Disk full or allocation exceeded
Illegal TFTP operation
Unknown transfer ID
File already exists
No such user

both ends and these values are used for duration of connection as the values of the UDP
source and destination ports. The initial request (RRQ or WRQ), on the other hand, is sent to
the UDP port corresponding to TID = 69 (decimal).
Error messages have the format shown in Figure 10.11b, where the error code value is
set according to Table 10.6. Error messages are typically extended by means of a short text
message which is intended to appear on the user’s terminal screen.

10.5 Secure shell program and protocol (SSH or SECSH)
Because the traditional telnet protocols (RFC 854) and related UNIX remote login commands
(e.g., rsh, rlogin (RFC 1282), rcp, etc.) are vulnerable to different kinds of network attacks,
there has been an increasing focus on improving the security of protocols (as we shall discuss
in more detail in Chapter 13). A third party who has network access to hosts or servers
connected to the Internet, or simply with physical access to communications lines, can gain
unauthorised access to systems, steal passwords and wreak havoc in a variety of ways. For
this reason, the ssh (SSH or secure shell) program and protocol was designed as a secure
replacement for telnet, rlogin and similar data network services.
SSH (secure shell) is a protocol and program for secure remote login and other secure
network services over an insecure network. It is used in particular as ‘secure version of telnet’
or as a secure shell — a program which allows commands to be executed in a remote machine,
for the transfer of files between machines and other secure network services. It was invented
by SSH Communications Security Oy, and ssh is a trademark of this company. It is currently
an Internet draft (being prepared as an RFC by IETF — Internet Engineering Task Force),
where it is also known as secsh (secure shell).
SSH is designed to protect against:
• interception of passwords and other data by intermediate hosts;
• manipulation of data by people in control of intermediate hosts or network transit points;
• IP spoofing (in which a targetted machine is ‘conned’ by a remote host which sends IP
packets which pretend to come from another, trusted host);
• DNS spoofing (in which an attacker forges domain name system (DNS)4 server resource
records.
4

See Chapter 14.

Secure shell program and protocol (SSH or SECSH)

429

Figure 10.12 SSH protocol architecture (SSH-ARCH).

SSH considers the network to be a hostile and evil environment — not to be trusted — and
protects data to be carried by the network accordingly. Even though a hostile third party
who manages to wrest control of the network can force SSH connections to disconnect, they
will not be able to decipher or play back messages, and will not be able to take over (i.e.,
hijack) connections. SSH achieves this by using encryption. The basic principles of SSH are
similar to those of IPsec.5 In essence, SSH adds a new ‘data security (authentication and
encryption) layer’ between the transport layer (layer 4) and the application data and protocols
(see Figure 10.12).

SSH protocol architecture
SSH has a three-layer protocol architecture comprising the following components:
• the SSH transport layer protocol (SSH-TRANS ) provides for a secure, low-level transport
connection — a confidential connection (called a session). It provides for encryption, message authentication and compression too (if required). It is usual for the SSH transport
layer protocol to be run over a TCP (transmission control protocol)6 connection [port 22],
but any other reliable data stream protocol may be used instead;
• the SSH user authentication protocol (SSH-USERAUTH ) runs over the transport layer
protocol and is used by the client to authenticate itself to the server. If authorisation is
successful, then an SSH tunnel results;
• the SSH connection protocol (SSH-CONNECT ) provides for the multiplexing of several
logical channels into the single tunnel provided by the transport and authentication protocols. It runs over the user authentication protocol.
The layered protocol architecture of SSH (called SSH-ARCH and illustrated in Figure 10.12)
is intended to allow for easy adaption of the protocol suite and incorporation of other protocols.

SSH transport layer protocol
Once a TCP/IP connection has been established on port 22 for the SSH protocol, both the
SSH client and SSH server will begin to listen on this port. The first action is for the two
5
6

See Chapter 13.
See Chapter 7.

430

Data networking and Internet applications

ends to check their SSH version compatibility. This is done by each end sending a plain text
message as a single TCP segment/IP packet in the format:
SSH-protoversion-softwareversion-comments followed by

Note how the SSL specification documents refer to CR-NL (carriage return, new line) rather
than to CRLF (carriage return line feed). Nonetheless the same ASCII characters (13 and
10) are used.
Once compatibility has been established (the current version of SSH incidentally is 2.0),
SSH packets are composed in the SSH transport protocol binary packet protocol format as
shown in Figure 10.13. The individual fields have the following meanings and uses:
• packet length — this is the length of the SSH packet (in number of bytes or octets), but
not including MAC field or the packet length field itself.
• padding length — this is the number of bytes (octets) of padding which has been added to
the payload field to make the total length of the SSH packet (minus MAC field) equal to
a multiple of 8 bytes or a multiple of the encryption code cipher block size. There must
be at least 4, but no more than 255 bytes.
• payload — the payload is the useful contents of the packet. Normally, this will contain
both compressed and encrypted information. The use of encryption on the payload is what
makes SSH a secure protocol. But, at the start, while the SSH transport layer protocol is
still establishing the secure connection — a process which involves exchange of security
encryption keys and negotiation of compression algorithms, plain text (unencrypted and
uncompressed text) may be used in this field. The plain text takes the format of an SSH
message type (a one byte field, coded with the message numbers according to Table 10.7
and followed by relevant message parameters). The character set used to code such plain
text messages must be explicitly specified. In most places, ISO 10646 with UTF-8 encoding
is used (RFC-2279). When applicable, a field is also provided for the language tag (RFC1766) — to indicate the human language in which text messages appear.
• random padding — this is a random pattern of data used to fill out the payload to the
standard length required by the encryption algorithm.

Figure 10.13 SSH transport protocol binary packet protocol format.

SSH transport protocol

Used by
SSH protocol:

SSH− MSG− SERVICE−
REQUEST

2
3

SSH− MSG− IGNORE
SSH− MSG−
UNIMPLEMENTED
SSH− MSG− DEBUG
5

4

1

Message
number

SSH message numbers

SSH− MSG− DISCONNECT

Message name

Table 10.7

Service names:
Ssh-userauth
Ssh-connection
(continued overleaf )

Always display (Boolean value)
Message (RFC 2279)
Language tag (RFC 1766)
Service name

Reasons:
1 host not allowed to connect
2 protocol error
3 key exchange failed
4 reserved
5 MAC (message authentication) error
6 compression error
7 service not available
8 protocol version not supported
9 host key not verifiable
10 connection lost
11 disconnect by application
12 too many connections
13 authorisation cancelled by user
14 no more auth. methods available
15 illegal user name
Message-specific data
Packet sequence number of reject message

Reason code
Description (RFC 2279)
Language tag (RFC 1766)

Message parameters

Secure shell program and protocol (SSH or SECSH)
431

(general authentication)

SSH authentication

Used by
SSH protocol:

21
30

SSH− MSG− NEWKEYS
SSH− MSG− KEXDH−
INIT
SSH− MSG− KEXDH−
REPLY
Reserved for other kex (key
exchange) packets
SSH− MSG− USERAUTH−
REQUEST
SSH− MSG− USERAUTH−

20

SSH− MSG− KEXINIT

51

50

32–49

31

6

Message
number

SSH− MSG− SERVICE−
ACCEPT

Message name

Table 10.7 (continued )

Username
Service name
Method name
Authentications− that− can− continue Partial
success (Boolean value)

(message specific)

Value f of encryption algorithm

Service names:
Ssh-userauth
Ssh-connection
(key exchange using following parameters:)
cookie
kex algorithms
server− host− key− algorithms
encryption− algorithms− client− to− server
encryption− algorithms− server− to− client
mac− algorithms− client− to− server
mac− algorithms− server− to− client
compression− algorithm− client− to− server
compression− algorithm− server− to− client
languages− client− to− server
languages− server− to− client
first kex packet follows (Boolean value)
(confirmation of end of key exchange — no
parameters)
Value e of encryption algorithm

Service name

Message parameters

432
Data networking and Internet applications

SSH connection protocol

(method specific)

Text message
Language tag
(message specific)

53

82

91

92

SSH− MSG− CHANNEL−
OPEN− FAILURE

90

(continued overleaf )

Channel type (e.g., ‘session’)
Sender channel number
Initial window size
Maximum packet size
Recipient channel number
Sender channel number
Initial window size
Maximum packet size
Recipient channel number
Reason code
Additional text
Language code



(no parameters)

81

83–89

Request name
Want reply (Boolean value)
Request-specific data
Response-specific data (usually none)

80

60–79

(no parameters)

52

SSH− MSG− CHANNEL−
OPEN− CONFIRMATION

SSH− MSG− REQUEST−
SUCCESS
SSH− MSG− REQUEST−
FAILURE
Reserved for other generic
connection protocol messages
SSH− MSG− CHANNEL−
OPEN

FAILURE
SSH− MSG− USERAUTH−
SUCCESS
SSH− MSG− USERAUTH−
BANNER
These messages are only sent by
the server (client sends only
SSH− MSG
− USERAUTH− REQUEST
messages). Different
authentication methods reuse
the same message numbers.
SSH− MSG− GLOBAL−
REQUEST

Secure shell program and protocol (SSH or SECSH)
433

Used by
SSH protocol:

Recipient channel number
Channel-type required
Want reply (Boolean value)
Channel-type-specific data
Recipient channel number
Recipient channel number

98

100

128–191
192–255

Reserved for local extensions

101–127

99







Recipient channel number

97

96

Recipient channel number
Data type code
Data
Recipient channel number

Reason codes:
1 administratively prohibited
2 connect failed
3 unknown channel type
4 resource shortage
Recipient channel number Data

Message parameters

95

94

Message
number

SSH− MSG− CHANNEL−
SUCCESS
SSH− MSG− CHANNEL−
FAILURE
Reserved for other connection
protocol channel-related
messages
Reserved for client protocols

SSH− MSG− CHANNEL−
EOF
SSH− MSG− CHANNEL−
CLOSE
SSH− MSG− CHANNEL−
REQUEST

SSH− MSG− CHANNEL−
DATA
SSH− MSG− CHANNEL−
EXTENDED− DATA

Message name

Table 10.7 (continued )

434
Data networking and Internet applications

Secure shell program and protocol (SSH or SECSH)

435

• MAC (message authentication code) — this field contains the message authentication code
bytes (of a length appropriate to the message authentication algorithm). The MAC is also
called a fingerprint or digital signature. It serves the same function as a hand-written
signature at the bottom of a letter — it confirms the authenticity of the message and the
sender. Initially the MAC value will be set as none.
Once the TCP connection has been set up and once both SSH client and server have agreed to
use the same SSH version, the SSH transport protocol can start its work in earnest. The first
step is to undertake key exchange to establish the encryption, MAC (message authentication
code) and compression algorithms which will be used to code the packet payload contents. The
SSH client starts the process by sending an SSH MSG KEXINIT to initiate the key exchange
(kex). The message informs the SSH server of all the encryption, MAC and compression
algorithms which it supports. The server replies with a similar SSH MSG KEXINIT message.
The encryption, MAC algorithm and compression initialisation process takes place
by exchange of SSH MSG KEXDH INIT and SSH MSG KEXDH REPLY messages (see
Figure 10.14). The client selects its chosen algorithms, calculates certain encryption code
values (we shall discuss encryption keys and MAC digital signatures in more detail in
Chapter 13) and communicates relevant initialisation vector (IV)7 values for the encryption
algorithm chosen. Since the encryption in the reverse direction (server-to-client) may be
different, the server also chooses encryption, compression and MAC algorithms and similarly
informs the client of initialisation vector values. (The algorithms used in the two directions
are recommended to be run independently of one another if not by different algorithms — this
gives greater security.)
The different encryption algorithms (ciphers) which may be used in association with SSH
are listed in Table 10.8. The different types of keys which may be used in association with
these algorithms may conform with any of the standards listed in Table 10.9.
The message authentication code (MAC, integrity check value, fingerprint or digital signature) associated with the message may conform to any of the standards listed in Table 10.10.

Figure 10.14 SSH transport protocol: keyexchange and establishment of a secure transport connection.
7

See Chapter 13.

436

Data networking and Internet applications
Table 10.8

Cipher name

SSH Transport layer protocol: alternative encryption algorithms and ciphers
Use in SSH
protocol

Cipher code name

3des-cbc

REQUIRED

aes128-cbc

RECOMMENDED

aes192-cbc

OPTIONAL

aes256-cbc

OPTIONAL

arcfour

OPTIONAL

Triple-DES (Defense
encryption
standard — 3DES)
[CBC — cipher block
chaining — mode]
AES (advanced encryption
standard) [CBC mode;
128-bit key]
AES (advanced encryption
standard) [CBC mode;
192-bit key]
AES (advanced encryption
standard or Rijndael
code) [CBC mode;
256-bit key]
ARCFOUR stream cipher

blowfish-cbc

RECOMMENDED

Blowfish (CBC mode)

cast128-cbc
idea-cbc

OPTIONAL
OPTIONAL

none
serpent128-cbc

OPTIONAL (NOT
RECOMMENDED)
OPTIONAL

CAST-128 (CBC mode)
IDEA (International Data
Encryptions Algorithm
CBC mode) [ASCOM
AG company-patented
encryption mechanism]
No encryption

serpent192-cbc

OPTIONAL

serpent256-cbc

OPTIONAL

twofish-cbc or
twofish256cbc

OPTIONAL

twofish128-cbc

RECOMMENDED

twofish192-cbc

OPTIONAL

Serpent (CBC mode:
128-bit key)
Serpent (CBC mode:
192-bit key)
Serpent (CBC mode:
256-bit key)
Twofish (CBC mode;
256-bit key)

Twofish (CBC mode;
128-bit key)
Twofish (CBC mode;
192-bit key)

Specified by:
RFC 1851

FIPS-197 (NIST Federal
Information
Processing Standard)
FIPS-197

FIPS-197

(Internet draft,
December 1999)
Bruce Schneier: Fast
Software Encryption
[Cambridge Security
Workshop
Proceedings, Dec
1993:
Springer-Verlag
1994]
RFC 2144
RFC 3058


www.cl.cam.ac.uk/
∼rja14/serpent.html
(see above)
(see above)
The Twofish Encryption
Algorithm (Schneier,
Kelsey, Whiting,
Wagner, Hall,
Ferguson) John
Wiley & Sons
(see above)
(see above)

Note: CBC = cipher block chaining mode. An excellent reference work on encryption is Applied Cryptography (Bruce
Schneier), published by John Wiley & Sons.