INTERNET DRAFT S. Jacobs Category: Standards Track GTE Laboratories Title: draft-jacobs-imep-auth-arch-01.txt M. S. Corson March 1999 University of Maryland MANET Authentication Architecture Status of This Memo This document is a submission by the Mobile Ad-hoc Networks (manet) Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the manet@itd.nrl.navy.mil mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Internet MANET Encapsulation Protocol (IMEP) is designed to support the operation of many routing algorithms or other Upper Layer Protocols (ULP) in Mobile Ad hoc Networks (MANET). The MANET computing environment is very different from the ordinary computing environment in that these mobile computers will be connected to the network via wireless links. Such links are particularly vulnerable to eavesdropping, replay, spoofing, and other attacks. The use of IMEP results in a mobile node relying on other MANET nodes to perform routing operations on behalf of the transmitting node. This routing function constitutes a significant vulnerability if the IMEP management messages are not authenticated. The risk of attacks on MANET routing control messages necessitates a MANET Authentication Architecture to protect these messages in some networking contexts. Consequently all MANET nodes SHOULD be able to perform authentication. The MANET Authentication Architecture provides MANET routers with the ability to choose between multiple authentication options ranging from simple to complex, while leaving the option of no authentication in some contexts. IMEP messages between MANET routers are authenticated with the IMEP Authentication object. Jacobs, Corson Expires September 1999 [Page i] INTERNET DRAFT March 1999 This document describes how MANET nodes using IMEP and desiring authentication SHOULD authenticate IMEP messages. Mechanisms described herein will allow these nodes to use either secret key type cryptosystems or public key type cryptosystems (with digital certificates and digital signatures) for authenticating IMEP management messages. The use of of secret key mechanisms will facilitate research and experimentation of MANET networks while the use of public key cryptosystems will allow MANET to scale to thousands of MANET mobile nodes. Contents Abstract ............................................................ i 1. Introduction ................................................ 1 1.1. Terminology ................................................. 2 1.2. Specification Language ...................................... 5 1.3. Security Enhancement ........................................ 5 2. Architecture Overview ....................................... 6 2.1 Processing Authentication Objects ........................... 6 2.1.1 Processing Public Key Objects ........................ 7 2.1.2 Processing Secret Key Objects ........................ 8 2.2 Generating Authentication Objects ........................... 8 3. IMEP Message and Object Formats ............................. 8 3.1 IMEP Message Format ......................................... 8 3.2 The IMEP Authentication Object ....................... 9 3.3 The IMEP Certificate Object .......................... 11 3.4. IMEP Authentication ......................................... 12 3.4.1. IMEP Authentication when = 001 .................. 12 3.4.2. IMEP Authentication when values greater than 009 . 13 3.5. Configuration and Registration Tables ....................... 13 4. Certificates ................................................ 13 4.1. Self-Signed Certificates .................................... 13 4.2. CA Signed Certificates ...................................... 14 5. Trust Hierarchy Paths ....................................... 15 6. Certificate Revocation Lists ................................ 15 7. Security Considerations ..................................... 16 8. Additional Modes ............................................ 16 A. Patent Issues ............................................... 16 References .......................................................... 17 Authors' Address .................................................... 18 Jacobs, Corson Expires September 1999 [Page ii] INTERNET DRAFT March 1999 1. Introduction The Internet MANET Encapsulation Protocol (IMEP) base protocol provides MANET Nodes with mobility mechanisms within the Internet and is designed to support the operation of many routing algorithms in Mobile Ad hoc Networks (MANET). The MANET communications environment is very different from wired communications environments in that these mobile computers are inter-connected via wireless links. Such links are particularly vulnerable to eavesdropping, replay, spoofing, and other attacks. MANET routing protocols results in a mobile node relying on other MANET nodes to perform routing operations on behalf of the transmitting node. This routing function constitutes a significant vulnerability if management messages are not authenticated. The risk of attacks on MANET routing control messages necessitates a MANET Authentication Architecture to protect these messages. Consequently all MANET nodes SHOULD be able to perform authentication. The MANET Authentication Architecture provides MANET routers with the ability to choose between multiple authentication options ranging from simple to complex, while leaving the option of no authentication for usage in some contexts. When examining the various types of MANET deployments being considered, one sees significantly different networking environments. Research test beds are relatively benign environments, provide network bandwidth from a few Kbps to Mbps within a single organization. Academic campus and business type conference center type networks face a greater level of threats, provide bandwidth ranging from Kbps to Mpbs, and may span a number of organizations. Rapid disaster response deployments are focused on a wireless environment, face many possible threats, provide bandwidth from 4.8Kbps to a few 100Kbps, interoperability across many organizations, and allow personnel from many organizations to interact with a high level of security.. Military deployments must contend with very hostile security environments, contend with available bandwidth from 4.8Kbps to Mbps, and allow personnel from many organizations to interact with a very high level of security. The number and frequency of protocol control messages has a direct impact on a protocol like MANET. The impact of control message size and control message size frequency have a direct impact on network bandwidth. As available network bandwidth decreases, network control overhead needs to be minimized. Frequent network control messages increased network overhead. MANET deployment environments face different types of threats and associated degrees of risk ranging from very few threats and low risks to many threats and very high risks. A MANET deploying organization faces a trade-off between their expected threats, the degree of risk acceptable and the cost in network security overhead necessary to mitigate risk in a specific threat context. Jacobs, Corson Expires September 1999 [Page 1] INTERNET DRAFT March 1999 There are a number of MANET control message authentication methodologies by deployment environment, such as Secret Key, Public Key & Self-signed Certificates, and Public Key & CA signed Certificates. For each authentication method there are both manual and dynamic key distribution approaches. Secret Keys may be distributed manually or dynamically, such as with the Internet Key Exchange (IKE) protocol, LDAP or DNS. Certificates containing Public keys may also be distributed manually or dynamically (via LDAP, DNS, X.500 or some other protocol). Manual key distribution approaches necessitate distributing key information to all nodes prior to deployment yet have no impact on network overhead. Dynamic key distribution approaches eliminate pre-deployment key distribution yet increase network overhead as keys are established/exchanged over the network. As the number of nodes deployed increases, the number of secret keys increases even faster, namely ((#nodes * (#nodes-1))**2)/2 which becomes unworkable quite quickly. With public keys, the number of key pairs = #nodes but one must consider certificates and certificate revocation and the network overhead managing certificates. This document describes how MANET nodes using IMEP authenticate MANET management messages. Mechanisms described herein will allow MANET Nodes to use either secret key type cryptosystems or public key type cryptosystems (with digital certificates and digital signatures) for authenticating IMEP management messages. The use of of secret key mechanisms will facilitate research and experimentation of MANET networks while the use of public key cryptosystems will allow MANET to scale to thousands of MANET mobile nodes. Also covered are: - the use of X.509 digital certificates - digital certificates issued by Certificate Authorities (CAs) - digital certificates issued by the subject of the certificate (self-signed certificates for a PGP-like informal web of trust) - use of either IP address or host name for identifying MANET nodes - digital certificate revocation and verification. 1.1. Terminology This section provides definitions for the terminology used throughout this document. Many of these definitions may be replaced by or merged with those of the MANET working group's terminology draft [1] now under development. Certification Authority (CA) A third party trusted by one or more users to create and assign digital certificates. All CAs are required to maintain a database of the Distinguished Names (DNs) which they have certified and to take measures to ensure that they do not certify duplicate DNs. Jacobs, Corson Expires September 1999 [Page 2] INTERNET DRAFT March 1999 Certificate-Revocation List (CRL) A data structure that contains that contains information about certificates whose validity an issuer has prematurely revoked. The information consists of an issuer name, the time of issue, the next scheduled time of issue, and a list of certificate serial numbers and their associated revocation times. The CRL is signed by the issuer. The data structure is defined in [RFC1422] Certificate Subject (Subject) A Certificate Subject, or Subject, is the entity referred to by the Distinguished Name (DN) contained within the Certificate. Digital Certificate (Certificate) A Digital Certificate, or Certificate, is a data structure that binds an entity's Distinguished Name (DN) to a public key with a digital signature. This data structure is defined in [X.509]. and contains information, such as identify and public key, about an entity where an authority, called a Certification Authority, has cryptographicly linked the information together using a digital signature. Digital Certification Digital Certification is the mechanism in which a Certification Authority (CA) "signs" a special data structure containing the name of some entity, or Subject, and their public key in such a way that anyone can "verify" that the message was signed by no one other than the certification authority and thereby develop trust in the subject's public key. Digital Signature the content to be signed is first reduced to a message digest with a message-digest algorithm (such as MD5), and then the octet string containing the message digest is encrypted with the RSA private key of the signer of the content. Distinguished Name (DN) A Distinguished Name, or DN, defines a "path" through an X.500 directory tree from the root of the tree to an object of interest. MANET router or router A device, identified by a ``unique Router ID" (RID), that executes a MANET routing protocol and, under the direction of which, forwards IP packets. It may have multiple interfaces, each identified by an IP address. Associated with each inter face is a physical-layer communication device. These devices may employ wireless or hardwired communications, and a Jacobs, Corson Expires September 1999 [Page 3] INTERNET DRAFT March 1999 router may simultaneously employ devices of differing technologies. For example, a MANET router may have four interfaces with differing communications technologies: two hardwired (Ethernet and FDDI) and two wireless (spread spectrum and impulse radio). MANET Security Association (MSA) A collection of security contexts, between a pair of nodes, which may be applied to IMEP protocol messages exchanged between them. Each context indicates an authentication algorithm and mode. Message-Digest Algorithm A message-digest algorithm is a method of reducing a message of Any length to a string of a fixed length, called the message digest, in such a way that it is computationally infeasible to find a collision (two messages with the same message digest) or to find a message with a given, predetermined message digest. MD2 and MD5 are message-digest algorithms described in [RFC1319] and [RFC1321]. Each inputs an arbitrary message and outputs a 128-bit message digest. Public-key algorithm An algorithm for encrypting or decrypting data with a public or Private key. When a private key is used to encrypt a message digest the public-key algorithm is called a message-digest encryption algorithm and the encrypted output is called a Digital Signature. This algorithm transforms a message of any length under a private key to a signature in such a way that it is computationally infeasible to find two messages with the same signature, to find a message with a given, predetermined signature, or to find the signature of a given message without knowledge of the private key. Typically, a digital signature is created by computing a message digest on the message, then encrypting the message digest with the private key. Public-key cryptography Public-key cryptography is the technology first identified by Diffie and Hellman [Diffie76] in which encryption and Decryption involve different keys. The two keys are the public key and the private key, and either can encrypt or decrypt data. A user gives his or her public key to other users, keeping the Private key to himself or herself. RSA RSA is a public-key algorithm invented by Rivest, Shamir, and Adleman [RSA78] involving exponentiation modulo the product of two large prime numbers. The difficulty of breaking RSA is generally considered to be equal to the difficulty of factoring Jacobs, Corson Expires September 1999 [Page 4] INTERNET DRAFT March 1999 integers that are the product of two large prime numbers of approximately equal size. Security Context A security context between two routers defines the manner in which two routers choose to mutually authentication each other, and indicates an authentication algorithm and mode. Security Parameter Index (SPI) An index, used with Secret Key authentication mechanisms, identifying a security context between a pair of MANET Nodes among the contexts available in the MANET Security Association. Self-Signed Digital Certificate (Self-Signed Certificate) A Digital Certificate, or Certificate, is a Digital Certificate that has been signed by the entity to which the Certificate appies to. This data structure is defined in [X.509] and contains information, such as identify and public key, about an entity where the entity itself has cryptographicly linked the information together using a digital signature. X.509 Digital Certificate An X.509 Digital Certificate is a data structure that binds an entity's Distinguished Name (DN) to a public key with a digital signature. This data structure is defined in [X.509]. and contains information, such as identify and public key, about an entity where an authority, called a Certification Authority, has cryptographicly linked the information together using a digital signature. X.509 Digital Certification X.509 Digital Certification is the mechanism in which a Certification Authority (CA) "signs" a special data structure containing the name of some entity, or Subject, and their public key in such a way that anyone can "verify" that the message was signed by no one other than the Certification Authority and thereby develop trust in the subject's public key. 1.2. Specification Language This document uses the terms "MUST", "SHOULD", and "MAY" as defined in RFC2119, along with the negated forms of those terms. 1.3. Security Enhancement The design goal of the MANET Authentication Architecture (MAA) is to provide an extensible authentication mechanism capable of supporting simple or strong authentication in IMEP and MANET networks. Jacobs, Corson Expires September 1999 [Page 5] INTERNET DRAFT March 1999 The MAA-enabled IMEP protocol works exactly the same way as the base protocol, yet provides a flexible approach to authentication between MANET Nodes. 2. Architecture Overview Each IMEP-enabled MANET Node SHOULD be able to support multiple authentication options ranging from simple to complex, while also permitting the possibility of no authentication (the default mode). IMEP messages between MANET routers are authenticated with the IMEP Authentication object. This object immediately follows all non authentication objects. The IMEP Authentication object identifies the Security Context between a pair of MANET Nodes and is fundamental to defining the MANET Security Association (MSA) between these nodes. BEACON, ECHO and equivelent IMEP messages between IMEP-enabled MANET Nodes MUST be authenticated with the Authentication Object (Section 3.2). This Object immediately follows all non-authentication related Objects and MAY be followed by a Certificate Object (Section 3.3) if the MSA, between the MANET Nodes utilizes Certificates. The proposed MANET Authentication Architecture changes apply to BEACON, ECHO and equivelent IMEP messages messages. The primary message change supporting the MAA is that MANET Nodes MUST include an Authentication Object in every IMEP message. The use of a Certificate Object appended to IMEP messages is optional, depending on the Security Context agreed to between the corresponding MANET Nodes. The Certificate Object includes a copy, or copies, of Certificates that bind system "distinguished names" to public keys using a digital signature. A Certificate Object will always contain at least one Certificate associated with the sender of a MANET message. There may also be present in the Certificate Object Certificates belonging to one of more CAs. When MANET Nodes share a common CA, only the Certificate of the common CA would ever appear in the Certificate Object. In the case where the communicating MANET nodes do not share a common CA then the Certificate Object would contain multiple CA Certificates from which a trust hierarchy path between the CA of one MANET Node and the CA of the other MANET Node may be established (see Section 5. For details on establishing trust hierarchy paths) 2.1 Processing Authentication Objects The MAA requires that IMEP messages include an Object that uses a digital signature to authenticate the contents of the message, and when necessary a Object so that receiving MANET Nodes can quickly obtain an authentic copy of the senders public key, necessary to verify a public key based . Jacobs, Corson Expires September 1999 [Page 6] INTERNET DRAFT March 1999 The initial authentication steps followed when a MANET Node receives an IMEP message are: 1. The receiving MANET Node locates the Object and if none is found, the receiver ceases further authentication processing and considers the message not authentic, the sender as not allowed to MANET network, the receiver logs the authentication failure and discards the received IMEP message. 2. If the receiving MANET Node locates more than one Object, the receiver ceases further authentication processing and considers the message not authentic, the sender as not allowed to MANET network, the receiver logs the authentication failure and discards the received IMEP message. 3. The receiver extracts the value of the Object field, which identifies the MSA, and whatalgorithm and public or secret key to be used in verifying the Object field. If the field is set to 001 then authentication is via secret key and authentication proceeds to step 4b. values greater than 009 specify autheintication is via public key and authentication proceeds to step 4a. values between 002 and 009 specify authentication to be by some unique user defined mechanism and beyond the scope of this document. All current valid values are shown in Table 3.2. 2.1.1 Processing Public Key Objects The specific authentication steps followed when a MANET Node receives an IMEP message authenticated using public key mechanisms are: 4a. The receiving MANET Node locates the Object and if none found the receiver ceases further authentication processing and considers the message not authentic, the receiver logs the authentication failure and discards the received IMEP message. 5a. The receiving MANET Node extracts the Certificates from the Object and, in the case where the sending and receiving MANET Nodes share the same CA or Self-signed certificates are being used, the receiving MANET Node uses the CA's, or senders, public key to validate the senders Certificate. 6a. In the case where the sending and receiving MANET Nodes do not share a common CA, then the receiving MANET Node uses any other CA Certificates contained in the Object to establish a trust hierarchy path between the receiver's CA and the sender's CA. 7a. In the case where the receiver is unable to establish a trust hierarchy path between the CAs, the receiver ceases further authentication processing and considers the message not authentic, the receiver logs the authentication failure and discards the received IMEP message. Jacobs, Corson Expires September 1999 [Page 7] INTERNET DRAFT March 1999 8a. Should the receiver be able to establish a trust hierarchy path between CAs. The receiver proceeds down the path verifying CA Certificates stopping when the Certificate of the sender has been verified. 9a. The receiver uses the sender's public key from the sender Certificate to verify the field in the Object, created using the sender's private key. 10a. Upon successful verification of the Object field, the receiver continues with normal processing of the IMEP message as specified in the base IMEP protocol. Should the Object field not pass verification, the receiver ceases further authentication processing and considers the IMEP message not authentic, the receiver logs the authentication failure and discards the received IMEP message. 2.1.2 Processing Secret Key Objects The specific authentication steps followed when a MANET Node receives an IMEP message authenticated using keyed-MD5 in the prefix+postfix mode are: 4b. The receiver proceeds to the field and if it does not correspond to a known authentication type, the receiver ceases further authentication processing and considers the message not authentic, the receiver logs the authentication failure and discards the received IMEP message. 5b. The receiver proceeds to verify the field in the Object using the prefix+postfix keyed-MD5 mode. 6b. Upon successful verification of the Object field, the receiver continues with normal processing of the IMEP message as specified in the base IMEP protocol. 7b. Should the Object field not pass verification, the receiver ceases further authentication processing and considers the IMEP message not authentic, the receiver logs the authentication failure and discards the received IMEP message. 2.2 Generating Authentication Objects The generation of Object field is covered in section 3.4 3. IMEP Message and Object Formats 3.1 IMEP Message Format The following identifies MAA changes to the message format of the proposed protocol. An IMEP message format consists of several fixed, Jacobs, Corson Expires September 1999 [Page 8] INTERNET DRAFT March 1999 mandatory fields followed by a self-formatting byte stream. An IMEP message MUST contain the Object and typically contains at least one of several optional object blocks. A message containing only the Objects is a BEACON message. The following ``grammar" describes the syntax of an IMEP message. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. : | | | | | | | | Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. Unchanged from base IMEP protocol. 3.2 The IMEP Authentication Object The IMEP Authentication Object is used to authenticate all IMEP messages. This is accomplished by calculating an Authenticator ("Digital Signature") from those fields in the IMEP message being authenticated. The Authenticator value computed for an Object MUST protect all fields from the field, in the , through, and including, the field in the Object. The field within the Object defines the security context which is used to compute the value and which MUST be used by the receiver to check that value. In particular, the Jacobs, Corson Expires September 1999 [Page 9] INTERNET DRAFT March 1999 selects the authentication algorithm and mode (see Section 6.1) and appropriate key used in computing the Authenticator All implementations of IMEP SHOULD implement the authentication algorithm (RSA-MD5) and key length of 512 bits defined above. The fields of the Object are: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | , continued ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | , continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Authentication Type) (1 byte): An identifier denoting the Security Context and type of MANET Security Association being used between two MANET Nodes signature algorithm used. Valid values for the field are shown in Table 3.2 below. (1 bytes): The Security Parameter Index (SPI), when not zero, defines the MSA which is used to compute the Authenticator value and used by the receiver to check that value. In particular, the SPI selects the authentication algorithm and mode (Section 5.1) and secret (a shared key) used in computing the Authenticator. When the field contains a value greater than 001, the field MUST be set to all zeros. (1 bytes): Length in bytes of the computed field. (variable length): Computed value. Exactly one Object MUST be present in all IMEP messages. The following table depicts the relationship between and sizes. Other values may be defined in the future. Jacobs, Corson Expires September 1999 [Page 10] INTERNET DRAFT March 1999 Table 3.2 -- Valid Authentication types. AUTH_TYPE | Authentication | Key Length | Digital Signature Value | Algorithm | in bits | Length in bytes -----------|----------------|--------------|------------------ 001 |Secret Key & MD5| 128 | 16 002 to 009 | User Defined | User Defined | User Defined 011 | RSA | 512 | 64 012 | RSA | 768 | 97 013 | RSA | 1024 | 128 014 | RSA | 2048 | 256 021 | Elliptic Curve | 80 | 10 022 | Elliptic Curve | 120 | 15 023 | Elliptic Curve | 160 | 20 030 | DSA | 512 | 64 When AUTH_TYPE = 001 then authentication is performed in a Prefix-Postfix fashion. 3.3 The IMEP Certificate Object The Certificate Object is used to transfer authentication information (Certificates) between communicating MANET Nodes when the Object field contains a value greater than 001. The fields of the Object are: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | , continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | , continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | additional s as necessary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (2 bytes) The length of the Object in bytes. : (2 bytes) The number of certificates contained in the Object Jacobs, Corson Expires September 1999 [Page 11] INTERNET DRAFT March 1999 : (2 bytes) Length in bytes of the X.509 Type 3 formatted Certificate of the message sender. : (variable length), The X.509 Type 3 Formatted Certificate of the message sender which contains the public key of the message sender. : (2 bytes) Length in bytes of the X.509 Type 3 formatted certificate of a Certificate Authority (CA). : (variable length), The X.509 Type 3 formatted certificate of a CA which contains the public key of the CA used to sign Certificates. 3.4. IMEP Authentication 3.4.1. IMEP Authentication when = 001 When = 001 the Authenticator is calculated using keyed-MD5 [RFC1321] in "prefix+suffix" mode to compute a 128-bit "digital signature" of the IMEP message. The resulting authenticator is a 128-bit value computed as the MD5 checksum over the following stream of bytes: - the shared secret key, defined by the MANET Security Association ( = 001 ) between the nodes and the value specified in the Object, followed by - the protected fields from the IMEP message from the field, in the , through, and including, the field in the Object, followed by - the shared secret key again. Note that the field itself is NOT included in the computation of the Authenticator value. The Security Parameter Index (SPI) defines the security context which is used to compute the Authenticator value and which MUST be used by the receiver to check that value. In particular, the SPI selects the authentication algorithm and secret shared key used in computing the Authenticator. For keyed MD5 authentication to be useful, the 128-bit Jacobs, Corson Expires September 1999 [Page 12] INTERNET DRAFT March 1999 key must be both secret and pseudo-random. It is the responsibility of the implementor to preload secret keys, and associated SPI values, into MANET Nodes that use this form of authentication. 3.4.2. IMEP Authentication when value greater than 009 The MD5 hashing algorithm is used to compute the 128-bit "message digest" of the IMEP message. The "message digest" is then encrypted using the specified public key authentication algorithm in conjunction with a specified length private key resulting in an Authenticator covering the fields from the IMEP message. Note that the Authenticator field itself is NOT included in the computation of the Authenticator value. See Table 3.2 for public key lengths and algorithms 3.5. Configuration and Registration Tables MANET Nodes using = 001 MUST be configured with MSAs of each authorized MANET node that it will interact with. MANET Nodes using gteater than 009 MUST be configured with an X.509 Certificate for itself, either self-signed or issued by Certificate Authority and a copy of the X.509 Certificate of the issuing Certificate Authority. 4. Certificates MAA provides for two forms of certificates: 1) certificates signed by the subject of the certificate and issued by the subject and 2) certificates signed by Certificate Authorities and issued on behalf of the certificate subject by a certificate Authority. 4.1 Self-Signed Certificates With self-signed certificates each node acts as its own CA by creating a certificate for itself containing a public key that the node "certifies" as it's public key. This form of public key authentication is typically called an informal web of trust similar to that used with Pretty Good Privacy (PGP) public keys. Self-signed Certificates used with SSA Mobile IP MUST include the same fields as Certificate Authority Signed Certificates except for the following: Signer Distinguished Name - This field replaces the CA Distinguished Name field and contains the Distinguished Name (DN) of the node which created the certificate. Signer Digital Signature - This field replace the CA Digital Signature field and contains the digital Jacobs, Corson Expires September 1999 [Page 13] INTERNET DRAFT March 1999 Signature, generated by the certificate creator, that binds the other fields of the Certificate together cryptocraphicly. Certificate Serial Number - A unique number assigned to a Certificate by the node that creates and digitally signs the Certificate. This serial number is used to positively identify the Certificate 4.2. Certificate Authority Signed Certificates Certificate Authority Signed Certificates used with MAA MUST include the following fields: Distinguished Name - The Distinguished Name (DN) is the sender's Router ID (RID). The use of this field is a variation of the DN approach defined in [X.500]. Not Valid Before Date - Not Valid Before Date (NVBD) is that date prior to which the Certificate is not valid Not Valid After Date - Not Valid After Date (NVAD) is that date After which the Certificate is not valid CA Distinguished Name - The CA Distinguished Name (DN) is as defined in [X.500] Subject Public Key - Subject Public Key is the binary string of Octets containing the public key of the sender Public Key Algorithm - Public Key Algorithm is the field that Identifies the type of public key algorithm the sender's public key must be used with Public Key Size - Public Key Size is the field that identifies the size of the sender's public key in octets CA Digital Signature - CA Digital Signature is the digital Signature generated by the sender's CA that binds the other fields of the Certificate Certificate Serial Number - A unique number assigned to a Certificate by the CA that creates and digitally signs the Certificate. This serial number is used to positively identify the Certificate Jacobs, Corson Expires September 1999 [Page 14] INTERNET DRAFT March 1999 5. Trust Hierarchy Paths A Trust Hierarchy Path is the establishment of a logical chain between two Certificate Authorities (CAs) and reflects a trust relationship that can be established through intervening CAs. Validation of a Certificate involves constructing a Trust Hierarchy Path between the sender Certificate, the CA that issued the sender Certificate and the CA of the validating system. The validity interval for every Certificate in this path must be checked. Establishing a trust hierarchy path MUST be performed to verify the authenticity and usability of Certificates within IMEP. This process assumes that the receiver knows the public key of the Sender's CA. The receiver can develop trust in the public key of the Sender's CA recursively, if the receiver has a Certificate containing the CA's public key signed by a superior CA whom the receiver already trusts. In this sense, a certificate is a stepping stone in digital trust. Each certificate is processed in turn, starting with that signed using the input trusted public key. The following checks are applied to all Certificates: - Check that the signature verifies - That dates are valid - The subject and issuer names chain correctly - The certificate has not been revoked. If any of the above checks fails, the procedure terminates, returning a failure indication. If none of the above checks fail on each Certificate, the procedure terminates successfully. 6. Certificate Revocation Lists Each digital certificate should be checked against the current Certificate Revocation List (CRL) from the issuing CA to ensure that revoked Certificate are not employed. The IMEP MAA recognizes that network performance could be seriously degraded if a receiving node always retrieves the most recent CRL when ever a new Certificate is received. Consequently, a MANET Node SHOULD cache received Certificates along with a value ("staleness value") that indicates the last time each Certificate was checked against a CRL from the issuing CA. The node SHOULD also maintain a value that indicates the maximum degree ("staleness threshold") of Certificate staleness a given node may tolerate before the node has to retrieve the appropriate CRL and verify that the Certificate has not been revoked. This staleness checking function is a compromise between the effect on available bandwidth vs. the risk of using a revoked Certificate. In those cases where the node has high network bandwidth available the staleness threshold should be set to a relatively low value (eg. 10 Jacobs, Corson Expires September 1999 [Page 15] INTERNET DRAFT March 1999 seconds). Where the node has less network bandwidth available the staleness threshold should be set to a higher value (eg. 10 minutes). 7. Security Considerations Those implementations of IMEP which do not include authentication run the risk of denial-of-service attacks. Staleness of Certificates and frequency for Certification Revocation List retrieval is a trade-off between exposure and potential threat resulting in a degree of risk from a revoked Certificate. By having implementations of the IMEP MAA provide a user tunable staleness threshold the degree of risk becomes a user managed function. 8. Additional Modes The IMEP MAA currently specifies one secret key-based authentication algorithm, and a number of public key-based algorithms, as well as providing for the usage of user defined authentication when desired. A. Patent Issues As of the time of publication, there exists a patent that is relevant to implementers of the MANET Authentication Architecture described herein: A.1. Massachusetts Institute of Technology Patent #4405829 Ronald L. Rivest, Adi Shamir, Leonard M. Adleman are the co-inventors of U.S. Patent No. 4405829, assigned to the Massachusetts Institute of Technology (MIT). The patent was filed December 14, 1977 and will expire on December 15, 1999, at which time the technology covered by the patent reverts to the public domain. Furthermore the US Government has rights to this technology pursuant to Contract No. N00014-67-A-0204, awarded to the Department of the Navy, and Grant No. MCS76-14249, awarded by the National Science Foundation. Should implementers wish to immediately proceed with implementing commercial versions of the IMEP MAA they may obtain a license from RSA Data Securities Inc. for use of the RSA asymmetric public key algorithm. This statement is for the IETF's assistance in its standard-setting procedure, and should not be relied upon by any party as an opinion Jacobs, Corson Expires September 1999 [Page 16] INTERNET DRAFT March 1999 or guarantee that any implementation it might make or use would not be covered by the MIT Patent and any other patents. References [Diffie76] Diffie, W., Hellman, M. E., "New directions in cryptography", IEEE Transactions on Information Theory, IT-22(6):644--654, November 1976. [NIST94] National Institute of Standards and Technology, NIST FIPS PUB 186, "Digital Signature Standard", US. Department of Commerce, May 1994 [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", April 1992. [RFC1321][21] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992. [RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", February 1993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", March 1997. [RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for obtaining digital signatures and public-key cryptosystems", Communications of the ACM, 21(2):120-126, February 1978. [Schneier96] Schneier, B., "Applied Cryptography 2nd Edition", Chapter 22 pp. 513-514, John Wiley & Sons Inc., 1996 [X.500] "CCITT. Recommendation X.500: The Directory-Overview of Concepts, Models and Services", 1988 [X.509] "CCITT. Recommendation X.509: The Directory-Authentication Framework", 1988. Jacobs, Corson Expires September 1999 [Page 17] INTERNET DRAFT March 1999 Authors' Address Questions about this memo can also be directed to: Stuart Jacobs Network Security Department GTE Laboratories, 40 Sylvan Road, Waltham, MA 02454, USA. Phone: 781-466-3076 Fax: 781-466-2838 sjacobs@gte.com M. Scott Corson Institute for Systems Research A.V. Williams Building (115) University of Maryland College Park, MD 20742 (301) 405-6630 corson@isr.umd.edu Jacobs, Corson Expires September 1999 [Page 18]