The first four bytes of the security context are the length of the entire security context in bytes or octets. They represent a four-byte unsigned integer in network byte order. This count includes the four bytes that specify the length of the context.
The rest of the security context is composed of zero or more blocks. These blocks may cross packet boundaries. Each security context block starts with one byte, the service byte. The bits of the service byte are allocated as follows:
| Bit Number | Meaning | Additional Information |
|---|---|---|
| 7 | Criticality bit | If this bit is set and the
recipient either does not understand this security service and
mechanism, or some aspect of processing it fails (e.g.,
unable to verify a checksum), then the
recipient should refuse the message with ARDP option 9.
If the criticality bit is not set in a block of the security context, the context's recipient may ignore any part of that block that is not understood. |
| 6 | Me | This block contains security context information that the originator generated. |
| 5 | You | The recipient is requested to generate a security context block with this service and mechanism. |
| 4--0 | Service Code | A numeric code representing a security service. |
The currently defined security services are PAYMENT, INTEGRITY, AUTHENTICATION, ENCRYPTION. and CLASS-OF-SERVICE.
Most security services can be performed by different algorithms or mechanisms. For example, authentication may be done, among other means, via Kerberos or via simple passwords (as FTP and TELNET do). The second octet of a security context block indicates the particular mechanism implementing the service specified by the first octet.
The numeric codes for security services and mechanisms are defined in the table below. They may also be seen in the ARDP source code, in ardp_sec.h.
The next four bytes are the length of the arguments to this block. This is an unsigned integer in network byte order. Some security contexts (especially ones being requested but not sent, where the you bit is set but the me bit is not) will have no arguments.
After this length count, that many bytes of arguments are present. The arguments and their format are interpreted by each security service and mechanism.
| Mechanism (value) | Service (value) | C Identifier | Argument Format |
|---|---|---|---|
| INTEGRITY (2) | INTEGRITY_CHECKSUM (0x01) | integrity_checksum | If the ME bit is set, the
argument is four bytes long. It is the four-byte CRC checksum of the
payload. If
the ME bit is not set, the arguments field has zero length. If the you bit is set, the sender expects that the response it receives will contain a 4-byte CRC checksum for the payload. |
| INTEGRITY (2) | INTEGRITY_KERBEROS (0x22) | integrity_kerberos |
From the client to the server, the argument is:
From the server to the client, the argument is:
|
| AUTHENTICATION (3) | AUTHENTICATION_KERBEROS (0x01) | authentication_kerberos | From the client to the server, the argument is the
authenticator produced as the output of the krb5_mk_req() Kerberos
library call. The length of the authenticator is known because it
is the same as the length of the total argument.
The authenticator is all that is required for Kerberos authentication. |
| CLASS_OF_SERVICE (5) | CLASS_OF_SERVICE_TAGS (0x00) | class_of_service_tags | The arguments are two null-terminated ASCII strings. They represent tag/value pairs. The first string is the name of the tag. The second is the tag's value. |