Basic Protection Scheme for the WWW

The Basic Protection Scheme consists of the following steps:
  1. (Server sends an Unauthorized status).
  2. Client authenticates himself.
  3. Server checks authentication and authorization.
  4. If previous was step successful, document is sent normally by the server.
  5. Document is recieved normally by the client.

If the server protection hierarchy is clear and the browser sophisticated enough to figure out right away if a document is protected, first step is visited very seldom (possibly only once) during the entire browsing session for each protected server.

A discussion of the basic protection scheme follows this information.

Step 1: Server Sends an Unauthorized Status

Once a server receives a request without an Authorization: field to access a document that is protected, it sends an Unauthorized 401 status code, and a set of WWW-Authenticate: fields containing valid authentication schemes and their scheme-specific parameters.

In Basic scheme the reply is following:

HTTP/1.0 401 Unauthorized -- authentication failed
WWW-Authenticate: Basic realm="CollabName"

where realm specifies used password file; same server can use different password file for different trees of documents (this is the server-id specified in CERN server protection setup file). Client can thus figure out which password to use at any given time.

Step 2: Client Authenticates Himself

After receiving Unauthorized status code, the browser prompts for user name and password (if they are not already given by the user), and constructs a string containing those two separated by a colon:


This string is then encoded into printable characters, and sent it along with the next request in the Authorization: field as follows:

Authorization: Basic encoded_string

Step 3: Server Checks Authentication and Authorization

When the server receives a request to access a document protected by the Basic Scheme, and the request is a full request containing Authorization: field which contains the Basic Scheme information, it will execute the following Access Request Validation Procedure:

  1. The server receives an Authorization: field with the scheme name Basic and encoded authorization string.
  2. If the scheme name is wrong, access is denied, and an Unauthorized 401 status with WWW-Authenticate: field containing appropriate scheme name (Basic) and realm name is sent back (as if no authorization information was given).
  3. If scheme name is correct the authorization string is decoded.
  4. If the access information is correct, the result should have two fields separated by a colon, of which at least the first must be non-empty (there can be a username without a password).
  5. If not, access is denied, and an Unauthorized 401 status with appropriate WWW-Authenticate: field is sent back.
  6. Otherwise, username and password are checked for validity from the password file.
  7. If the username-password pair is incorrect, access is denied with an Unauthorized 401 status and WWW-Authenticate: field etc.
  8. If the username-password pair is correct, the server checks if user and connecting IP address are members of mask-group (if) specified in protection setup file (using group file).
  9. Server then looks for an entry for the requested file in the corresponding Access Control List File, which is in the same directory as the file to be accessed, named .www_acl (if any).
  10. If there is no mask-group nor ACL, or if ACL exists, but there is no entry for that file, access is denied with a Frobidden 403 status code.
  11. If there is an ACL entry for it, server checks if the user and connecting IP address belong to the list of groups and users allowed to access it (using group file).
  12. If not, an Unauthorized 401 status etc. is sent.
  13. Otherwise, the server checks if the requested file exists.
  14. If not, a Not found 404 status is sent back.
  15. Otherwise access is allowed, and the server sends the document normally to the browser.

Section of RFC-1421 -- Printable Encoding

This printable encoding step is applicable to PEM message types ENCRYPTED and MIC-ONLY. The same processing is also employed in representation of certain specifically identified PEM encapsulated header field quantities as cited in Section 4.6. Proceeding from left to right, the bit string resulting from step 3 is encoded into characters which are universally representable at all sites, though not necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent).

A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure.

To represent the encapsulated text of a PEM message, the encoding function's output is delimited into text lines (using local conventions), with each line except the last containing exactly 64 printable characters and the final line containing 64 or fewer printable characters. (This line length is easily printable and is guaranteed to satisfy SMTP's 1000-character transmitted line length limit.) This folding requirement does not apply when the encoding procedure is used to represent PEM header field quantities; Section 4.6 discusses folding of PEM encapsulated header fields.

The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group extracted from the output of step 3, each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 1, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "<CR>", "<LF>").

Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.

Printable Encoding Characters
Value Encoding
0A 8I 16Q 24Y 32g 40o 48w 564
1B 9J 17R 25Z 33h 41p 49x 575
2C 10K 18S 26a 34i 42q 50y 586
3D 11L 19T 27b 35j 43r 51z 597
4E 12M 20U 28c 36k 44s 520 608
5F 13N 21V 29d 37l 45t 531 619
6G 14O 22W 30e 38m 46u 542 62+
7H 15P 23X 31f 39n 47v 553 63/
Padding Character is =

Discussion About the Basic Protection Scheme

Because the password flies (almost) unencrypted through the Internet, anyone who is listening to the Internet traffic can find out people's user names and corresponding passwords. Thus this kind of a telnet-level protection only protects from accidental viewing of classified documents.

You migth think of this as a door. If you really want to get in, you can always break the lock, and get what you want, but the bottom line then is that then you have broken something, and that is wrong.

Thus the Basic Protection Scheme only provides the means of telling people that a document is a protected one; it does not prevent the document from being accessed by someone who wants it badly enough to go through the trouble of listening to the Internet traffic, finding out which printable encoding scheme we use, and decoding your username and password.

However, using IP address masking together with usernames ("only these people from these internet addresses") makes it more secure, because an intruder would also have to have access to the machine having the required IP address.

12 December 1993

Free Spam Protection   Eggnog Recipe   Android ORM   Simple Java Magic   JMX using HTTP   OAuth 2.0 Simple Example   Great Eggnog Recipe