Use of Requirements
The requirements identified in this document are intended primarily for I/T teams developing or purchasing cross departmental and Institute wide applications and systems, however all I/T teams are encouraged to review the requirements and to carefully consider both short and long term implications of any alternative technical solutions. This document may be incorporated into consulting or development contracts, however MIT's I/T Integration Team reserves the right to remove or modify requirements for those specific contracts.

To ensure compatibility with the MIT architectural infrastructure, exceptions to these requirements may only be granted upon the recommendation of the I/T Integration Team.

Network Security
The MIT network (MITnet) supports administrative, faculty and student use both on and off of campus including collaboration with colleagues at other universities. While many corporations use firewalls to protect themselves from unauthorized network intruders, the unique requirements for MITnet are not compatible with firewalls and thus require stricter network security mechanisms. Vendors often incorrectly assume that firewalls are sufficient.

Firewalls assume that the "bad guys" are outside the firewall and that the "good guys" are inside the wall. At MIT, the identification of "bad" and "good" guys can not be as easily determined since:

• many MITnet machines are accessible world wide via the Internet
• some members of the MIT community need world wide remote access to MITnet
• not all applications on MITnet are available to the entire Institute

Many of the requirements outlined in this document are a direct result of the fact that the MIT infrastructure must provide mechanisms to protect its systems from unauthorized users while providing access to authorized users in many locations.

Document Conventions
Each requirement identified in this document includes a requirement name, description and optional supplemental text in the following format:

1. Requirement Name
   Requirement Description
   Optional Supplemental Text

Application Requirements
The current MIT Application Requirements are as follows:

1. Client/Server Applications on MITnet
   A Client/Server (C/S) architecture must be used for all non-web applications.

   The traditional two-tiered C/S model should be sufficient for most applications, however if the application is complex or the number of transactions between the client and server is large, then a three-tiered architecture may be required. Two-tiered C/S provides presentation level support at the desktop and business processing on a server. In a three tiered approach, the client talks to a "middleware" server that then talks to a backend database server. The "middleware" server may be implemented using a standard TP monitor, or by implementing the server such that it exports an application specific protocol which is used by the client. A significant advantage of the three-tiered model is that the business processing is done on a centrally controlled machine. This provides for increased security and in some case makes it possible to change the business processing logic in the middleware without making changes to the client. Three tiered architectures also provide better scalability and significant performance advantages for more complex applications.

2. Web Based Applications
   Web Based applications may be used but must follow additional web specific guidelines.

   Web-based applications need to meet the same authentication, authorization, and encryption requirements identified for traditional Client/Server applications in this document. Implementation differences between Client/Server and Web based applications are noted within the requirement descriptions and supplemental text portions of the requirements. 

3. Authentication
   For security reasons, Client/Server and Web based applications must determine if a user is who they claim to be either by using an authenticated Kerberos ID or by using X.509 certificates issued by the MIT certificate server (Certifying Authority).

   While security requirements may vary from application to application, a secure authentication method must be used whenever users can do either of the following:

   • read data which is protected due to business or privacy requirements
   • modify or enter data which could seriously affect the Institute's business interests.

   All Client/Server applications must use MIT's standard network authentication service, Kerberos. Authentication must take place between the client and server or in the case of three tiered applications between the client and the middleware server.

   For Web based applications authentication is provided through the MIT Certifying Authority, the MIT certificate server. Users must obtain an MIT certificate from the MIT certificate server before accessing a secure MIT web service. See the document "Obtaining Certificates for Accessing Secure Web Services at MIT".

   IP addresses should not be used for either authentication or authorization especially for applications that are available to the entire MIT community. While technically servers can use IP addresses to identify MIT clients, this is not a scalable practice for MIT applications since many members of the MIT community have IP addresses outside of Net 18 (18.*.*.*) and a growing number of users have IP addresses from independent Internet Service Providers (ISP).

   While Client/Server applications can utilize Kerberos authentication directly, Web based applications need to use X.509 certificates. A server that authenticates users based on X.509 certificates does not need to maintain a list of IP addresses, and it can accommodate both on- and off-campus MIT users. (See the transcript of Jeff Schiller's 12/3/96 talk on Web authentication technology.) MIT supports a certificate server that allows a user to get an MIT certificate with their Kerberos ID and password. These MIT certificates should be used by all secure MIT Web based applications. 

4. Authorization
   For security reasons, Client/Server and Web based applications must provide server authorization to determine if an authenticated user is allowed to use services provided by the server.

   Client/Server applications must not rely solely on client based authorization, since this makes the application server and/or database vulnerable to an attacker who can easily bypass the client-enforced authorization checks. Such security attacks are possible via commercially available SQL tools and by modifying and replacing client software.

   For three tiered Client/Server applications the middleware server must be responsible for performing user authorization checks. The backend database server must also be configured so that it will only accept requests from the middleware server or from privileged system administrators. Otherwise, clients would be able to bypass the authorization and data consistency checks performed by the middleware server.

5. Data Encryption
   Applications that transmit sensitive information including passwords over the network must encrypt the data to protect it from being intercepted by network eavesdroppers.

   Users of an application that has been granted an exception to this requirement must be specifically and explicitly warned against using their Kerberos passwords for that particular application. This is to prevent an insecure application from jeopardizing MIT's entire computing infrastructure, the ramifications of which may be both financial and legal.

   Data Encryption for Client/Server applications is provided by Kerberos. Web applications that require data encryption should utilize Secure Socket Layer (SSL).

6. Network Protocols
   Client/Server applications must operate on the current MITnet communications protocol (TCP/IP).

   Although MITnet currently also routes AppleTalk, it is not considered a robust nor reliable protocol for Client/Server applications. 

7. Accessible User Interface (Added in November 1998)
   Applications, must be accessible to individuals with disabilities.

   Both internally developed and vendor provided software, must include interfaces, on at least one desktop, that accommodate individuals with disabilities. Exceptions to this requirement are granted, with appropriate documentation, only when there are no compliant packages in the marketplace and when building such an interface is excessively expensive.

8. Desktop Configurations
   Client applications must run on all currently supported desktop configurations.
   

   For information about current and future supported applications, contact itag@mit.edu.

9. Server Configurations
   Server software must support one of the standard server platforms.

   For information about current and future supported applications, contact itag@mit.edu.
   
   Servers other than those run by Network Operations must not collect or store Kerberos passwords.

10. Relational Databases
    Applications needing to use relational databases must use MIT's standard database server technology and data models.

    For information about current and future supported applications, contact itag@mit.edu.
    
    The MIT data models are defined by the MIT Data Administrators. Development teams need to submit proposed application data models with a statement of scope to the MIT Data Administrator for review. The Data Administrator will ensure that the data model is consistent with existing MIT data models. For more information on Data Administration Requirements, see the document "Data Administration Requirements".

11. Development Environment
    The development environment should be appropriate to the desktops being supported. This usually means a cross-platform tool.
     
12. Development Guidelines
    I/T teams need to follow the I/T development guidelines for internally developed and purchased vendor products.

    I/T development guidelines include the following:

    • Use development tools that support writing and calling external functions (e.g. in C).
    • Minimize custom changes to purchased software to those required to make the software work properly with the MIT infrastructure. Changes significantly increase the ongoing maintenance and upgrade costs to the software.
    • Applications must not duplicate or use conflicting infrastructure components.
    • Make use of existing infrastructure components. (See the document "The MIT Information Technology Infrastructure" for a list of components.)
    • Applications should have the ability to export data from the system in a non-proprietary format.