Miniproject Assignment - Clarifications
Servers: There are two options for testing your implementation
with a server:
1- It is ideal if your implementation works with a real
server (e.g., CSE IMAP server). You may install a server or use an existing
server (of course without causing system overload or crash!). However, this
option may not be feasible for some protocols that are either outdated or not
being used in practice. Thus, in this case (1) you are working on such
outdated/obsolete protocols, your test-bed bed requires an element which is unavailable
(e.g., a secure communication channel from a network provider), or (3) the
protocol is too complicated to work with a real server (i.e., needs several
weeks for implementation), you may choose the second option. Note that the
later case should be cleared with Dr. Cheng or the TA.
2- Implement a dummy server that provides the basic
functionality of the protocol according to the following table. Note that your
implementation must exhibit at least
these features. Moreover, both client and server must show all the interactions
and type of messages sent and
received. This will help you to ensure that your implementation is consistent
with your state diagrams.
|
|
|
Protocol |
Why needed? |
Basic Functionalities |
Resource |
|
1 |
Remote
Access Lopez |
RLogin |
Provides remote access to UNIX
machines |
1.
Username/password authentication. 2.
Character-based communication and
buffering. 3. Different flow-control handling for Rlogin and
telnet. |
|
|
Telnet |
General purpose remote access
protocol |
||||
|
SSH |
Secure shell |
Common functions of rlogin and telnet
+ username/password encryption + secure tunnels. |
|||
|
2 |
Hypertext Transfer Gerber/ Krishnamurthy |
HTTP |
Web-based remote access. |
1-
HTML file downloads and displaying. 2- Form
submissions |
|
|
HTTPS |
Basic HTTP plus secure communication |
||||
|
SOAP |
Works with HTTP to transfer and open
XML files. |
||||
|
3 |
Proxy Hopkins/Macklem |
SOCKS4 |
Clients behind a firewall, needing to
access exterior servers |
1-
Initial setup communication 2- Subsequent
data transfer |
|
|
SOCKS4a |
Name resolution |
||||
|
SOCKS5 |
One type of authentication |
|
|
|
Protocol |
Why needed? |
Basic Functionalities |
Resource |
|
4 |
Email
Transfer Brown/Bandela |
IMAP2 |
To retrieve e-mail messages from a
remote server over a TCP/IP connection (pull protocol) |
1.
Shows contents of mailbox. 2. IMAPs: Delete emails 3. POP3: download/keep and download/delete emails. 4. IMAPs: Create email folders. |
|
|
POP3 |
|
||||
|
IMAP4rev1 |
|||||
|
5 |
Authentication Ramirez/Diaz/ Fiedler |
Kerberos |
Strong authentication for
client/server applications Authentication protocol designed for
use on insecure networks. Mutual authentication between two
parties communicating on a network. |
1-
Basic authentication request/response. 2-
Session management 3-
Key distribution center (including AS
and TGS) 4- Implementation of Needham Schroeder protocol 5- Kerberos authentication using GSS_API 6- The first 3 items suffice to implement Otway-Rees
protocol. |
|
Otway-Rees
protocol
|
Authentication protocol designed for
use on insecure networks. |
||||
Needham-Schroeder
protocol
|
Mutual authentication between two
parties communicating on a network. |
||||
|
6 |
File Transfer Cai/Lee |
TFTP |
Simple file transfer |
1.
Basic file transfer service. 2. FTP utilizes non-secure authentication. TFTP does
not use logins 3. FTP provides a reliable service through its use of
TCP. TFTP does not since it uses UDP 4.
Your implementation should provide 5
commands that TFTP provides. |
|
|
FTP |
Non-secure file transfer
|
||||
|
SFTP |
Secure file transfer. |
Basic
functions of FTP plus secure file transfer and authentication. |