6.9.1 Authentication

The Authentication object allows a system that stores usernames and/or passwords to share them with other applications through SIF. The provider of the Authentication object may only support providing a username or a password, or it may support both.

The Authentication object is also able to transmit a user's network identity through SIF. If the user has an account in a network directory system that supports LDAP, the user's distinguishedName or username is shared to uniquely identify the user to applications that support LDAP or native network authentication options.

Details of how to implement the password element are included below the object definition.

SIF_Events are reported for this object.

6.9.1.1 Password Implementation Details

While Authentication objects transported over SIF HTTPS are typically secure in transit, SIF objects are often stored in logs and databases. If the network infrastructure is not secure, the passwords could be subject to snooping from system users. Because of this, the design of the Authentication object requires that passwords never be transmitted in plain text, to prevent casual viewing. The design of this object allows passwords to be securely encrypted using a variety of encryption algorithms.

Passwords in the Authentication object can be shared in one of three ways as documented in the sections below.

6.9.1.1.1 Encoded Text

Sharing a password using encoded text is a very insecure method, because it uses a well-known algorithm and the value is not encrypted. The only merit of using this method is that the password is not readable as plain text, and thus deters any casual attempt to read a password. To share passwords in this manner, the following steps must be followed:

1. The publishing agent creates a Password element with the algorithm set to base64.
2. The agent encodes the Unicode representation of the password using the UTF-8 encoding.
3. The resulting binary value is then base64 encoded.
4. Write the result as the payload of the Password element.

6.9.1.1.2 Hashed Text

Sharing a hashed text version of a password means that the original password is not shared. Clear text passwords are not retrievable from values stored as hashes. These hashed values can only be used to verify passwords input by a user.

What is shared is a cryptographically secure hash of the password. This hash allows other applications to verify a user's password when s/he logs in by comparing the hash value, not the original password. To share passwords in this manner, the following steps must be followed:

1. The publishing agent creates a Password element with the algorithm set to MD5 or SHA1.
2. The agent encodes the Unicode representation of the password using the UTF-8 encoding.
3. Hash the resulting binary value with the chosen hash algorithm.
4. Encode the binary result using base64 encoding.
5. Write the result as the payload of the Password element.

6.9.1.1.3 Encrypted Text

Sharing a password using encrypted text can be very secure. The key being used to encrypt the data should be known only to the applications. The KeyName attribute is used to allow agents to uniquely identify keys that are being used. To share passwords in this manner, the following steps must be followed:

1. The publishing agent creates a Password element with the algorithm set to DES, TripleDES, RC2, or AES.
2. The agent encodes the Unicode representation of the password using the UTF-8 encoding.
3. Generate a cryptographically secure Initialization Vector (IV).
4. Configure the encryption algorithm to use a cipher mode of CBC.
5. Configure the encryption algorithm to use a block size of 64 bits (8 bytes).
6. Configure the encryption algorithm to use the generated IV.
7. Configure the encryption algorithm to use the specified key for encryption.
8. Configure the encryption algorithm to use PKCS#7/PKCS#5 padding mode.
9. Encrypt the binary representation of the password that was generated in step 2.
10. Encode the binary result using base64 encoding.
11. Write the result as the payload of the Password element.

6.9.1.1.3.1 Example Keys

The XML in the Authentication example can be used to verify an agent's implementation of any of the published algorithms. The password being shared for the sake of the example is ¿sècrèt. High-Unicode characters are being used in this example to validate proper encoding. The actual Unicode characters are: U+00BF, U+0073, U+00E8, U+0063, U+0072, U+00E8, U+0074.

The encryption keys being used are as follows (in base 64 format)

NOTE: Real-world implementations of password sharing should use keys other than the ones used for this documentation. These keys are provided for example's sake only. Keys should be generated using a secure cryptographic key generator.

6.9.2 SIF_LogEntry

This object captures an occurrence within a SIF node (ZIS or agent)—error, warning or information—for storage in an optionally provided zone log. SIF_LogEntry Adds are reported and are used to post new log entries to the provider of the log. Of course, subscribing agents may also filter incoming Adds as part of their own logging mechanism. Any Change or Delete SIF_Events should be ignored at the agent level, but should be routed by the ZIS (though this should not be necessary). Use of the log is optional and voluntary, except where noted as mandatory in this specification. Nodes may post as much or as little log data as required with the expectation that if there is a provider of SIF_LogEntry that the logged entries be available for a provider-defined amount of time subject to provider-defined restrictions on the quantity of data logged by any given node.

SIF_Events are reported for this object.