IPSEC Working Group K. Martius INTERNET-DRAFT secunet Security Networks AG draft-martius-ipsec-mike-00.txt June 1999 Multi-Domain Authentication and Key Exchange Protocol <draft-martius-ipsec-mike-00.txt> Status of this Memo 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. Table of Contents 1. Abstract ................................................... 2 2. Terms and Definitions ...................................... 3 3. Introduction ............................................... 4 3.1 Infrastructure requirements ............................. 4 3.2 Secure packet filters and IPSec ......................... 4 3.3 Restrictions of IKE ..................................... 6 3.4 Problems to solve ....................................... 7 4. Security Policies in complex networks ...................... 7 4.1 Automated Security Policy Management .................... 7 4.2 Example Scenarios ....................................... 8 5. MIKE .......................................................10 5.1 Design Objectives .......................................10 K. Martius [Page 1]
Internet Draft MIKE June 1999 5.2 SPS Relation ............................................11 5.3 Protocol Engine .........................................12 5.4 Message construction ....................................13 5.4.1 Message-Block "Superstructure" ......................13 5.4.2 Unicast Message construction ........................14 5.5 MIKE Authentication schemes .............................14 5.5.1 Scope of Authentication .............................15 5.5.2 Proxy Authentication / Multi-Message Authentication .16 5.5.3 Construction of authentication fields / Authentication Schemes ............................18 5.6 Using ISAKMP Payloads to build the Message Structure ....20 6. Message processing description .............................21 6.1 First Message Upflow (I->R) .............................22 6.2 First Message Downflow (R->I) ...........................23 6.3 Second (last) Message Upflow (I->R) .....................25 7. Key Generation .............................................25 8. Restrictions ...............................................26 8.1 Overlapping Tunnels .....................................26 8.2 Rekeying / Fault Management .............................27 9. Comparison .................................................27 10. Logical Overview ..........................................29 11. Security Considerations ...................................29 12. Acknowledgments ...........................................29 Appendix A Pseudo Code Notation ...............................30 Appendix A.1 - Symbolic functions, Variables and ............30 Appendix A.2 - Pseudo Code of MDAKMP ........................32 Appendix B - Payload Explosion Example ........................35 References ....................................................38 1. Abstract This document describes a protocol which allows to authenticate systems and establish Security Associations in networks with different domains of security. The protocol is not only end-to-end, but it involves all participating systems in a single exchange. Further it allows security gateways to derive sub-policies for crossing (encrypted) IPSec-traffic from "conventional" packet filtering rules in a trusted manner. MIKE uses IKE-like mechanisms for authentication and key derivation [HC98] (thats why it's called MIKE). First, E-IKE [MA98-1] was developed for a combined key- and policy management. This document describes a successor of this protocol (MIKE) allowing to take advantage of trust relations (proxy authentiation) and provides gateways with the necessary information to apply packet filters on crossing IPSec-traffic by deriving rules (src, dst, spi) from K. Martius [Page 2]
Internet Draft MIKE June 1999 conventional filter rules. Consitant security policies of all involved systems must be negotiated "out-of-band". 2. Terms and Definitions The following special terms, acronyms and naming conventions are used in this document: Identifiers, like IDi1, IDr1, IDi2, IDr2, SA, SKEYID_x etc., are used in the same context as in [HC99]. Message (MSG) A combination of fields belonging to an authentication / key exchange process between exactly two systems Message-Block (MSG-Block) A frame containing a number of messages, preceded by a header System Any host involved in a authentication / key exchange (Security) Gateway (SG) A subset of "system", which protects a ->security domain enforcing security policies on data flows crossing the SG Security Domain Any set of hosts sharing the same security policy. TRD Trusted Rule Derivation (see sect. 3.2) MMA Multi Message Authentication; special authentication mechanism provided by MIKE System / gateway numbering and naming conventions: --- ------ ------ ---- ------ ------ --- | I |--|S(I+1)|- . -|S(n-1)|--|S(n)|--|S(n+1)|- . -|S(R-1)|--| R | --- ------ ------ ---- ------ ------ --- Upflow / Downflow Message-Block sent in direction I --> R resp. R --> I X / Y Any system of I .. S(n) .. R, where X is located left-hand of Y K. Martius [Page 3]
Internet Draft MIKE June 1999 A(X/Y) Authentication of X against Y, that is, X proofs Y it's identity and it's participation in the exchange (whereas A1(X/Y) means Y requests authentication, and A2(X/Y) means X replies with an cryptographically calculated value authenticating itself. 3. Introduction 3.1 Infrastructure requirements Today's network topology becomes more and more complex, both physical and logical. Different (from very small to very large) organizational units are interconnected, each with it's own security requirements forming different security domains. Security domains can consist of a single host or a huge number of nodes. Security gateways (SGs) are the transitions between different security domains enforcing a domain security policy. Security policies may conflict between different security domains, even making some kind of communication impossible. A mechanism must be provided which combines policies of involved domains and resolves conflicts, as far as possible. Finally, it gives a set of security requirements to every "policy enforcement point" (PEP), mostly both end systems and participating SGs, for a requested communication. After that, security mechanisms required to enforce the policies need to be established. IPSec mechanisms (AH and ESP) provide the flexibility to enforce security requirements in these cascaded network structures by combining transport and tunnel mode as necessary (multiple embedded tunnels). However, because only symmetric cryptographic mechanisms are used, for individual authentication and encryption a number of different SAs has to be established for a single connection. Though this is the most restrictive approach and there could be situations where sharing keys between more than 2 parties is not a problem, the key management must be flexible enough to establish this set of SAs. 3.2 Secure packet filters and IPSec Using IPSec, security gateways can implement really secure filtering rules compared to conventional packet filters relying on unauthenticated header data. Moreover, the filters can use the full set of selectors defined in [KA98], even user- and hostnames. In this light, the Security Policy Database (SPD) can be seen as a generalized filter table for Security Gateways. The simplest way to employ a secure filter would be to require AH for every permit rule. A Security Gateway between networks 10.1.1.0 and 10.1.2.0 might have a rule for incoming traffic on it's K. Martius [Page 4]
Internet Draft MIKE June 1999 10.1.1.1-interface like this (the same rule applies for outgoing traffic on the 10.1.2.1-interface; an equivalent rule for the opposite direction is required, too): src dst prot sport dport action 10.1.1.0/24 10.1.2.0/16 UDP * 52 sec This results in the use of IPSec-mechanisms like this: 10.1.1.0 ---- 10.1.2.0 | | | | | SG | | | | | ------------- | | -------------- 10.1.1.1 10.1.2.1 --- <===== AH =====> <===== AH =====> While this is the most secure way it is the most resource intensive, too: Every host traversing the gateway must establish an AH-tunnel ending at the SG, resulting in extra bandwidth, extra key management and compute resources on the gateway. If gateways trust (authenticated) endpoints to not misuse IPSec connections (for example, these end nodes do not tunnel a telnet session while the ESP connection that authenticated for FTP), they don't need to employ IPSec mechanisms by themself, but might want to apply "conventional" filtering rules to this authenticated connections. Traversing ESP-traffic renders conventional filtering impossible, however. To apply rules on encrypted traffic, the gateways must have a trusted way to derive "IPSec-policies" from their original rules. If a rule like src dst prot sport dport action 10.1.1.0/24 10.1.2.0/16 UDP * 52 permit could *trustworthy* related to a rule like dst SPI prot 10.1.1.1 0x1001 ESP the gateway could permit the traversing ESP connection exactly by this SA-identifying tuple. This is also true for multiple embedded tunnels, as long as the rule can be related to the inner data connection. Subsequently, this feature is called "trusted rule derivation" (TRD). The picture shows this in an abstract form for one SG: K. Martius [Page 5]
Internet Draft MIKE June 1999 --------- ---- --------- | H1 ext. | | SG | | H2 int. | --------- ---- --------- <-----------------> | <-----------------> "some mechanism" for authentication and request of wanted communication | <-----------------------------------------> IKE Phase I <-----------------------------------------> IKE Phase II | <-----------------> | <-----------------> "some mechanism" to announce SPIs for this IPSec connection | <=========================================> final ESP connection, "filtered" by (H1/H2, SPI1/SPI2, ESP) However, the more secure way would be to add an AH tunnel from H1 to SG so that the gateway can verify *every* incoming packet for integrity: <===================> AH tunnel The picture above obviously lacks of specification of "some mechanism" and it's non-relation to the end-to-end key management (IKE). MIKE will provide a mechanism to solve these problems. The following section outlines the restrictions given using IKE for key and policy management in complex networks with a number of security gateways and the need for secure derivation of filter rules. 3.3 Restrictions of IKE [HC98] (IKE) describes a protocol using part of Oakley [Orm96] and part of SKEME [Kra96] in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. IKE is designed to authenticate endpoints and negotiate security associations (and necessary key material) between *two* parties. IKE currently covers scenarios where: - Two systems are directly connected (on network level) and requiring end-to-end-security - Two Security Gateways (SG) form a (flat) VPN without involving end K. Martius [Page 6]
Internet Draft MIKE June 1999 systems (or other gateways) - Simple remote access scenario, IPSec ends on an SG (i.e. border of an organization) 3.4 Problems to solve There are a number of general problems to solve to provide security (i.e. key- and policy-) management in the outlined scenario: 1.Gateway discovery problem: The initiator of a connection normally does not know in advance, which gateways it has to traverse to reach the final destination. In some situations there could be more than one gateway to a specific domain, i.e. for backup purposes. This holds for both normal data traffic and security management traffic. 2.System's security policy distribution and conflict resolution: The policies of involved hosts and gateways are normally not available to systems of other security domains beforehand. IPSec itself relies on known security policies, however. [KA98] specifies, that incoming packets, that do not match local policies, have to be silently discarded. A very flexible and scalable approach is to run a separate protocol for "policy distribution, decorrelation and resolution". Such a "Security Policy System" is described in [SC98]. Section 4 gives a short overview of it. 3.Authentication / Key Management / Trusted Rule Derivation After knowing the involved systems and their security requirements, authentication, possibly using trust relations established by the policy management, key / SA establishment for security requirements and a secure way to derive policies on gateways as described in sect. 3.2 must be provided. To get this functionality, an extended key management protocol MIKE is developed (sect. 5) which builds on IKE in it's authentication and message types. 4. Security Policies in complex networks 4.1 Automated Security Policy Management [SC98] describes a "Security Policy System" (SPS) which solves the first two points outlined in the above section: "Gateway Discovery" and "Policy Distribution, Decorrelation and Resolution". K. Martius [Page 7]
Internet Draft MIKE June 1999 In short, SPS is a distributed system using policy clients and policy servers. A "Security Policy Protocol" (SPP) allows to distribute local security policies to authenticated, authorized policy clients and servers. A policy server holds a database of policy information for the domain it is authoritative for. This local database MUST be decorralated, that is the policies MUST NOT overlap. For examples demonstrating this process, see [SC98]. Further, [SC98] describes an algorithm for policy resolution. If a policy server receives a remote policy, it must compare it to it's local database for possible conflicts. There could be policy combinations which don't allow a requested communication (a simple example would be that one domain permits outgoing telnet, the other deny incoming telnet). In some implementation there could be a user (i.e. administrator) interaction to request for an exception or there could be "hard-" and "soft policies" (however this is ranked in a database). Finally, if a communication is allowed, SPS returns an ordered list of Security Gateways on the way together with their security requirements to the Initiator of the policy request. If policies ask for intermediate tunnels, the concerning PEPs (i.e. gateways) are instructed by their local policy managers, too. The PEPs then are responsible to establish necessary SAs to realize the policies. This approach has the following advantages: - With a global view on the final connection by the policy management instances they can provide the systems with a resolved, decorrelated "over-all"-policy and the correct SA ordering. - specialized services and protocol(s) can be used to resolve policy conflicts in complex networks. - trust relations can be established by the policy management - It is independent from the key exchange protocol. For instance, IKE can be used as it is. However, this has some disadvantages outlined above. 4.2 Example Scenarios The next paragraph outlines possible scenarios in 3 examples demonstrating the richness of configurations that have to be covered by a generalized Key Management, i.e. MIKE. In every example, an ordered list of security policies must be configured on the systems (H1, SG, H2). This might be set up automatically by SPS (like described in sect. 4.1) or it could be configured by hand. The arrows in the figures show the final set of security mechanisms K. Martius [Page 8]
Internet Draft MIKE June 1999 for a communication between H1 and H2; MIKE can be used for authentication, key establishment and for secure filter setup. 1. only IPSec-mechanisms are used, neither trust relations exist nor secure filters shall be applied by the gateways. __________ SPS _____________ | | | | | | --------- ---- --------- | H1 ext. | | SG | | H2 int. | --------- ---- --------- H1<->H2: ESP SG<->H2: AH H2<->H1: ESP H1<->SG: AH SG<->H1: AH H2<->SG: AH That is, in this example finally the following IPSec-Tunnels / transports are to be used: AH tun. AH tun. <-----------------> <-------------------> <=========================================> ESP transport 2. H1 and H2 want to set up end-to-end-encryption using ESP, for instance for HTTP. SG has a filter rule allowing H1 to access H2's HTTP service. SG now has to securely derive a rule allowing a related ESP-connection to pass: {H1, SPI-H1, ESP} and {H2, SPI-H2, ESP}. TRD is used to derive this rules. --------- ---- --------- | H1 ext. | | SG | | H2 int. | --------- ---- --------- H1<->H2: ESP H2<->H1: ESP SG : TRD(H2) SG : TRD(H1) | Dst./SPI/Proto <===================|=====================> ESP transport 3. H2 trusts SG to authenticate H2's messages, that is, H2 sends it's messages to H1, but SG authenticates them. This saves one public-key- operation (in the case a public-key-based authentication mode is selected) because both, SG's message and H2's message to H1 are authenticated at once. K. Martius [Page 9]
Internet Draft MIKE June 1999 --------- ---- --------- | H1 ext. | | SG | | H2 int. | --------- ---- --------- H1<->H2: ESP H2<->H1: ESP H1<->SG: AH SG<->H1: AH SG : trustee(H2) SG: trustee(H2) AH tun. | <-----------------> | <=========================================> ESP transport In the following section a protocol is developed providing authentication, possibly using trust relations established by the policy management, as well as key / SA establishment and a secure way to derive policies on gateways as described in sect. 3.2. 5. MIKE 5.1 Design Objectives IKE uses different mechanisms for strong authentication and key exchange between two points. Beside the basic key exchange function, especially the flexibility choosing different authentication mechanisms should be available in the new protocol MIKE, too. So, MIKE might be called a "multi-point" version of IKE. Phase II, which carries information on client IDs, their security requirements and chosen SPIs (in the SA payload), is encrypted in IKE, however. In the multi-domain protocol these information must be visible to every involved system, nevertheless, it must be authenticated. This is exactly one point E-IKE was designed for, so many arguments and design principles from E-IKE are used here again. At the end, MIKE is a simplified E-IKE protocol in the sense of "outsourcing" policy management to SPS. The basic approach is to build a secure channel along all gateways by IKE phase-I-SAs. Then, newly designed messages are send through this secure channel carrying a kind of (unencrypted) phase-II messages. K. Martius [Page 10]
Internet Draft MIKE June 1999 ----- ----- ----- ----- | I | | SG1 | | SG2 | | R | ----- <=IKE P1=> ----- ----- ----- ============ <=IKE P1=> MSG-Block .....> : ========== <=IKE P1=> : MSG-Bl. .......> =========== : : : : MSG-Bl. ......> : : : : : : <...... MSG-Bl. : : : ... : : : : : : : ============ ========== =========== For MIKE, IKE protocol design has been taken as a basis. This leads to an equal level of security according to authentication of messages, nonce and DH public values. Especially the DoS-defense mechanisms in phase I and the different authentication schemes are used unchanged between neighbored systems and only slightly adapted for new MIKE messages. By authenticating neighbored systems in phase- I-exchanges the resulting IKE-SAs lead to the secure channel along the gateways, independent of the security level of intermediate links. Authentication between not directly neighbored systems is a functionality MIKE provides. However, DoS by malicious gateways can not be prevented this way. The protocol must be able to provide individual key material, that is, keys are only shared between pairs of systems. The final key generation algorithms have been changed only marginally, however. MIKE should further allow to authenticate IPSec-identifying information (basically destination address, and SPI / protocol in SA payload) of other systems providing the possibility to securely relate final IPSec connections to the requested end-to-end communication. Another important design goal was to optimize the protocol according to the number of messages, round trips and number of public key operations. MIKE should be able to take advantage of trust relations established by SPS. 5.2 SPS Relation SPS provides MIKE with an ordered list of necessary SAs. Gateways need extra information about the related end-to-end connection, if intermediate tunnels are required, which is also provided by SPS. Finally, SPS informs involved systems about SGs, which are trustees of other systems and/or want to do TRD (that is to simplify protocol processing of MIKE). K. Martius [Page 11]
Internet Draft MIKE June 1999 SPS results in a list of requirements for the specific end-to-end- connection and establishes trust relations MIKE can take advantage of. Otherwise, this configuration would have to be done by some other means (for instance static manual configuration) before MIKE protocol processing. 5.3. Protocol Engine The Initiator of a communication request starts MIKE performing the following two steps: 1. Running IKE-phase-I-exchange to it's next security gateway (Of course, already established IKE-SAs to this gateway can be used, too). 2. The first MIKE message-block is sent to this gateway (secured by IKE phase 1 SA) containing unicast messages to all systems I needs SA's to. Combining single messages in a "Message-block", which is sent through a secure channel along involved systems is a basic concept of MIKE. Message-blocks are a kind of container which is "loadable" and "unloadable" by systems traversed. Message-block addressing is end-to-end (further called "message-block address"). That is, every system can identify an ongoing exchange by the message-block end-to-end address. If multiple exchanges between theses systems are running at the same time, MIKE cookies instantiate these exchanges. Every system can add own messages to the message- block, as well as extract them when they are addressed to itself. The next system the message-block is sent to is preconfigured by some mechanism (like SPS). That is, every system knows it's neighbor. The secure channel is iteratively build on the first upflow of the message-block from I to R. MIKE messages are designed comparable to IKE Aggressive Mode. Therefore, 3 messages are needed to complete authentication and key exchange. That is, every unicast message inside the message-block must be carried 3 times, once from "left to right", once back from "right to left" and finally once up again. The secure channel, which has been set up during the first upflow, can be used for completion of the current exchange as well as for subsequential exchanges, too. The structure and handling of message-blocks and transported messages is described in the following section. K. Martius [Page 12]
Internet Draft MIKE June 1999 5.4 Message construction In general, the protocol has to provide the same functionality as like as IKE between two systems: - It has to guarantee freshness and integrity of parameters exchanged (nonce, DH-exponent, resulting keys). - Because there is no IKE-phase-I-exchange for authentication of non- directly neighbored systems, the protocol must provide a mechanism to perform this authentication. - inside the secure channel the single messages are not protected against tempering with on malicious gateways. From this point of view this channel has to be treated as insecure and therefore the proof of correct reception of a message must be provided by the protocol itself. Further, the construction of authentication information must support authentication of IPSec-identifying information of other systems and take advantage of trust relations. 5.4.1 Message-Block "Superstructure" As mentioned above, all parameters are carried in single messages which are combined to a message-block. This message-block is secured between two neighbored systems S and S1 by an IKE-SA, that is, the message-block is encrypted by SKEYID_e and authenticated by SKEYID_a using the exchanged Encryption- and Hash-(prf-)function. An exchange is instantiated by MIKE cookies, because it is necessary to crpytographically combine the single messages and their parameters with the current run of the protocol. There are the same requirements for these cookies as like as for IKE cookies except anti-clogging mechanisms. One part is selected by the first Initiator, the other by the final Responder. MSGBLOCK S->S1: { M_Cookie_I, [M_Cookie_R], HMAC{remainder}SKEYID_a(S,S1) MSGBLOCK src-ID, MSGBLOCK dst-ID; MSG(1),.. MSG(n) } SKEYID_e(S,S1) MSG(x) is a single unicast message addressed to any system involved. Depending on the requirements of the sender and receiver of MSG(x), it can be used only for SA establishment (1), for SA establishment and authentication (2) or just for authentication (3). Authentication might be required for parameters of a single message or for K. Martius [Page 13]
Internet Draft MIKE June 1999 parameters of other messages designated to the same recipient, which is further called "multi-message authentication" (MMA). (1) System X requires IPSec mechanisms, but trusts some other system (2) common case (same as covered by IKE today), except X is trustee of some other system (3) System X is a secure filter or trustee of some other system, but doesn't need own IPSec mechanisms 5.4.2 Unicast Message construction Three messages derived from IKE aggressive mode are defined. They are exchanged between X and Y in the message-block up- and downflow. Depending on authentication requirements and selected authentication scheme, SA payload and DH exponent are optional in the message structure. Nonce might be encrypted, if public key encryption authentication scheme is used. Further, Nonce is only required if authentication or SA is needed in the specific direction. The concrete message construction for different authentication schemes and requirements is described in paragraph 5.5. MSG1: X->Y { IDx1, IDy1, [IDx2, IDy2], [N(i)|<N(i)>Pub(IDr1)], [SA], [g^i], [A1(Y/X)] } MSG2: Y->X { IDx1, IDy1, [IDx2, IDy2], [N(r)|<N(r)>Pub(IDi1)], [SA], [g^r], [A2(Y/X)] [A1(X/Y)] } MSG3: X->Y { IDx1, IDy1, [A2(X/Y)] } ID1 payloads address the actual message. ID2-payloads are (optional) phase-II-payloads, i.e. for IPSec.The SA field is either the proposed security association (MSG1) or the selected one (MSG2). Nonce and public DH exponent are parameters for the individual key material and serve to provide freshness. In some authentication schemes, they are required for authentication, too. The last message is (as like as in IKE) for liveliness proof and optional authentication response. Authentication fields are seperately described in the next section. 5.5 MIKE Authentication schemes Essentially, the new dimension of MIKE lies in it's very flexible and fine-grained authentication mechanisms. First, every message can serve to authenticate a very individual range of parameters and second, the scheme used to actually calculate the authentication value can be selected on a per message / per direction - basis. Both K. Martius [Page 14]
Internet Draft MIKE June 1999 basically lies in the construction of the authentication fields in the single message (A1 and A2). 5.5.1 Scope of Authentication MIKE authentication mechanisms provide the possibility to choose different scopes of authentication depending on security requirements and trust relations. As outlined in sect. 5.4.1 a single message can serve for SA establishment with or without authentication or just for authentication, whereas authentication might be required for the single message (case (2)) or for other messages, too (cases (1) and (3)). The requirement to authenticate other messages (literally spoken: specific parameters of other messages) in messages of system X raises, when: - X is trustee of other systems to perform authentication of their parameters. X might have own SA requirements to Y, SA / KE payloads could be available in this message. - X is a gateway trusting authenticated end nodes, but wants to authenticate IPSec-identifying information of the negotiated end- to-end-connection to securely derive filtering rules (TRD). In this case SA / KE payloads are not included. Table 1 shows possible combinations of IPSec-specific information and authentication requirements that could araise in a message. Table 1: X is | X includes SA MMA ----------------------------------------------------- 1. IPSec GW / endpoint | Y N 2. Trustee and IPSec GW | Y Y 3. Only Trustee | N Y This results in formal requirements what information the messages resp. their authentication fields A1 resp. A2 must include: 1. Authentication of systems (Y) to which someone (X) wants to establish an SA. A1 requests for authentication, A2 then authenticates Y's nonce and public DH values (only those for X) as like as to prove Y's participation in the exchange and its identity (Authentication requirements in the opposite direction might differ). MSG1: X->Y { IDx1, IDy1, [IDx2, IDy2], N(i)|<N(i)>Pub(IDy1), SA, g^i, A1(Y/X) } K. Martius [Page 15]
Internet Draft MIKE June 1999 MSG2: Y->X { IDx1, IDy1, [IDx2, IDy2], N(r)|<N(r)>Pub(IDx1), SA, g^r, A2(Y/X), [A1(X/Y)]} MSG3: X->Y { IDx1, IDy1, [A2(X/Y)] } 2. Same as (1), but Y has to include it's nonce and public DH values for X and other systems (X is trustee for) in it's authentication. MSG1: X->Y { IDx1, IDy1, [IDx2, IDy2], N(i)|<N(i)>Pub(IDy1), SA, g^i, A1(Y/X,...) } MSG2: Y->X { IDx1, IDy1, [IDx2, IDy2], N(r)|<N(r)>Pub(IDx1), SA, g^r, A2(Y/X...), [A1(X/Y)]} MSG3: X->Y { IDx1, IDy1, [A2(X/Y)] } 3. Same as (2), but X doesn't send own values Y would have to authenticate (except Nonce, which serves for authentication purposes). MSG1: X->Y { IDx1, IDy1, [IDx2, IDy2], N(i)|<N(i)>Pub(IDy1), [g^i], A1(Y/X...) } MSG2: Y->X { IDx1, IDy1, [IDx2, IDy2], N(r)|<N(r)>Pub(IDx1), [g^r], A2(Y/X...), [A1(X/Y)]} MSG3: X->Y { IDx1, IDy1, [A2(X/Y)] } 5.5.2 Proxy Authentication / Multi-Message Authentication If authentication is required is subject to local policy and established trust relations. To allow such a selective authentication the authentication field (A) is used unidirectional. Therefore it has two states to indicate authentication request and -response. This allows very fine-grained policies according to trust relations. Request for "individual" authentication by a system X is necessary, if X does not trust it³s direct neighbor or a chain of systems. For instance, a boundary gateway of an organization normally must always request for authentication, while internal gateways may trust this K. Martius [Page 16]
Internet Draft MIKE June 1999 boundary gateway (or a chain of gateways to the boundary gateway) and delegate the authentication to this system. So, this trustee must authenticate every message from internal systems trusting it. That is, it has to authenticate parties and their values not only for itself. This kind of authentication is further referred to as "proxy- authentication", the system performing this is the "trustee". Using unidirectional authentication fields, an external system does not need to verify internal trust relations (i.e. verify that S3 is authoritative to speak for other systems in the example below). For example, S3 in a boundary gateway and trustee for S1 and S2 (where this trust relation was established outside of MIKE), S4 is an external system, authentication can be performed as follows: S1 -> S2 -> S3[req. S4 to authenticate S1 and S2's msg] -> S4 ..... <- S4[resp. auth.(S1,S2,S3)][req. S3, req.S2, req. S1] S1[resp. S4] -> S2[resp. S4] -> S3[resp. S4] -> S4 Proxy-authentication can reduce the number of cryptographic operations, because a trustee can perform authentication for all systems trusting it at once. If the trustee needs an own SA to the "outside" system, proxy authentication can be performed using the same AUTH-field used to request authentication for own parameters (see below). This should be normally the case for a "boundary gateway", for instance, the gateway (trustee) requires AH to authenticate every incoming packet. However, if there is no SA requirement by the trustee, it has to use an own message especially for proxy authentication, which does not need to contain an SA proposal and (except for signature authentication mode) no DH-value. Multi-message authentication (MMA) uses the same mechanism like proxy-authentication, however, it serves a different purpose: While proxy-authentication is used to authenticate several messages at once utilizing trust relations, MMA serves to request *extra* authentication and cryptographically combine content of other messages. Modifying the example above so, that no trust relation exists between S1, S2 and S3, but S3 wants to authenticate S4's parameters for S1 and S2 (i.e. it wants to do TRD to finally apply a filter rule on an IPSec connection), the messages would look like: S1[req. S4] -> K. Martius [Page 17]
Internet Draft MIKE June 1999 S2 [req. S4] -> S3[req. S4 to authenticate S1, S2 and S3's msg] -> S4 <- S4 [resp. (S1,S2,S3)][req. S3] [resp. S1] [req. S1] [resp. S2] [req. S2] S1[resp. S4] -> S2[resp. S4] -> S3[resp. S4] -> S4 This way, S3 can securely relate information (especially IPSec SPI) used between S4 and S1 to parameters used between S4 and S2 (and possibly also such between S4 and S3). (S3 needs to authenticate S1's and S2's information too, which is not demonstrated in the picture). Authentication fields and -methods are described in detail in the next paragraph. 5.5.3 Construction of authentication fields / Authentication Schemes Depending on local policies, no authentication, unidirectional or mutual authentication, even with different methods, is possible. The same authentication mechanisms as like as in IKE are provided. This addresses individual needs in security and infrastructure. A1-field requests for authentication of the other party by a specific mechanism. Currently pre-shared key, DSA/RSA signatures and RSA encryption are supported. The same attribute values described in [HC98] are used. In the case of proxy- and multi-message- authentication, A1 contains a list of IDs for messages the authentication is to be extended to. So, the IDs in some sense are pointers to messages inside the message-block). Depending on the direction of the current message flow, these IDs are IDx1 or IDy1 of the messages to be authenticated. A1(Y/X){ PSK | SIG | PKE, [IDi1]...[IDs(y-1)1] } A1(X/Y){ PSK | SIG | PKE, [IDr1]...[IDs(x+1)1] } Depending on the required authentication mode, the nonce value in the message is to be interpreted as encrypted (PKE) or in clear (PSK/SIG). A2 contains the calculated authentication value of the party to be authenticated. A2 is, as like as in IKE, a hash computed by a HMAC- function over relevant data, parameterized by a key SKEYID, which actually authenticates the party. K. Martius [Page 18]
Internet Draft MIKE June 1999 For case 1 (Table 1) A2 is defined as follows: A2(Y/X) = prf(SKEYID,g^y | g^x | M-CKYI|M-CKYR | SA | IDx1 | IDy1) A2(X/Y) = prf(SKEYID,g^x | g^y | M-CKYR|M-CKYI | SA | IDy1 | IDx1) In the case of MMA and proxy authentication, for a simplfied protocol processing the whole messages excluding the generic message header next pointer (see next paragraph) of the other "parties" are included in the HMAC calculation. Both messages, the received one and the own sent are included into the calculation. This makes it possible for a trustee to verify correct reception by Y of parameters sent by X as well as to authenticate Y's parameters sent to X in the second message (comparable to I-digest and R-digest in IKE). A2(Y/X)=prf(SKEYID, [g^y|g^x |] M-CKYI | M-CKYR | [SA |] IDx1 | IDy1 [IDx2 | IDy2 |] MSG(ID1->Y), MSG(Y->ID1)...MSG(Y->IDn)) A2(X/Y)=prf(SKEYID, [g^x|g^y |] M-CKYR | M-CKYI | [SA |] IDy1 | IDx1 [IDx2 | IDy2 |] MSG(X->ID1), MSG(ID1->X,...MSG(IDn->X)) Actually, the authentication information lies in SKEYID, which is calculated equivalent to IKE, depending on the requested authentication mode: Pre-Shared Key (PSK) SKEYID = prf(pre-shared key, Nx | Ny) SKEYID can only be calculated by someone who possesses the pre- shared key, normally only the legitimate parties. Therefore, A2 can only be calculated correctly, if all values are left unchanged. Signature (SIG) SKEYID = prf(Nx | Ny, g^xy) Using signature mode, no (shared) secret is available yet. According to design criteria of cryptographic protocols, a secret value has to be included, however. This can only be the shared DH key. Further, signature mode needs an extra step to encrypt A2 value by using one³s private key (i.e. to sign it). A2(Y/X) = { prf(SKEYID, g^y | g^x ...)} PrivKey(Y) A2(X/Y) = { prf(SKEYID, g^x | g^y ...)} PrivKey(X) K. Martius [Page 19]
Internet Draft MIKE June 1999 Public Key Encryption (PKE) SKEYID = prf(hash(Nx | Ny), M-CKYI | M-CKYR) For public key encrytion mode, a shared secret is available with the previously encrypted Nonce value. Only the other party could decrypt this value by it³s private key. To have something to hash, MIKE-Cookies are used. Some remarks on authentication of IDs and SA payloads: Beside the obvious need to authenticate nonce and DH values - they are used to generate the final key material - it³s also important to include responder³s selected SA-proposal and identities. Otherwise an attacks could be mounted like changing responder³s SA selection (for instance into a weaker encryption algorithm). Authentication of IDs is important to provide information on who authenticated a certain message to whom (this is also a basic design criteria of cryptographic protocols). This avoids masquerading and replay attacks, if one party should choose bad nonce values. For a detailed review on design rationales of IKE and MIKE authentication and key generation principles see [Ma98-2]. 5.6 Using ISAKMP Payloads to build the Message Structure A basic design goal of MIKE was to build on IKE and ISKAMP not only in their principles, but also to use ISAKMP messages, DOI identifiers and so on. This approach allows to build on available implementations of IKE for message generation and -parsing. Building the described message structure is done as follows: IKE header between two neighbored systems is used (almost) unchanged. The only modification is the definition of a new exchange type to provide information for an implementation, that the following IKE payload is structured like described in this draft. This extends the values assigned in [MSST98] (currently used value: 34). Message IDs and (IKE-) Cookies are only used between neighbored instances. "Length" defines the length of the entire IKE-Message including all MIKE-messages (that is the MIKE-Cookies, MAC, message-block addresses and all MIKE messages). MIKE-Cookies are handled by a NONCE payload (this is less efficient than a defined length like in the IKE header. However, a fixed length field would violate IKE payload processing). The MAC (Message Authentication Code) for the message-block is also carried by a HASH payload. K. Martius [Page 20]
Internet Draft MIKE June 1999 ID payloads, nonce, SA proposals / responses and DH public values inside a message are represented the same way as like as in IKE. To structure payload in separate messages like described in paragraph 5.4, a generic ISAKMP-header is used as MIKE header. It precedes every single message inside the message-block. "payload length" covers the length of the whole message. Authentication field inside the message is represented by a HASH- payload. Presence of a HASH payload in the first message signals authentication request (Y/X). A1 HASH payload MUST be filled with the identifier of the requested authentication mode (pre-shared key, RSA signature, etc.), which are defined in [HC98]. For proxy- and multi- message authentication, HASH payloads representing A1 might be followed by a number of ID payloads. Presence of one HASH payload in the second message signals either authentication response (A2) or authentication request (X/Y), depending on state information on X (i.e. if X requested authentication of Y or not). Two HASH payloads carry Y³s response and it³s authentication request for X, respectively. The last messages can only reply an authentication response of I (A2). An detailed example for a full packet ("payload explosion") is provided in Appendix B). 6. Message processing description A "technical" description of how a specific message-block will be processed on a system in different situations is given by the pseudo code notation in Appendix A.2. It shows the logic of operation on an Initiator as well as on gateways and Responder and abstracts the verbal description of message processing in this paragraph. To fulfil the assumption of a secure channel along the way, in the first message upflow, every system has to extend this channel to it's next gateway (or the final responder) by an IKE-phase-I exchange, before it compiles and sends a new message-block. This channel now can be used for many subsequent exchanges not necessarily originating from the same Initiator. (If IKE-SA expires, rekeying of parts of this channel may be necessary, however. Because this is not defined by IKE yet, a very new phase I exchange must be done.) The Initiator has an ordered list of IDs (retrieved, for instance, from SPS) to which it needs extra security associations in order to fulfil security requirements of it's end-to-end communication. The list also contains information about gateways that are trustees K. Martius [Page 21]
Internet Draft MIKE June 1999 and/or want to do TRD. The first message-block contains all the messages to these systems. For the latter case, no SA payload and (except for SIG authentication mode) no KE payload is required.(see sect 5.4.2) Message-block 1: I->S1 { M_Cookie_I, 0, HASH(MBlock1), IDci, IDcr M1: I->R; [... Mn: I->S1] } The number of messages in a message-block may increase on the way from Initiator to Responder. 6.1 First Message Upflow (I->R) Every system S(n) appends own messages for systems on the way to R, if it needs own SAs. Further messages are needed if S(n) is trustee of systems before it or S(n) wants to derive it's filtering rules in a secure manner. A system S(n) getting a message-block now has to evaluate: - The entire message-block is addressed to itself (that means S(n) = R): - evaluate all messages according to their SA proposals, select one due to local policy - generate own key components (Nr, g^r), if required - authenticate, if requested - request authentication (if no trust relation exists) - send back appropriate message-block Only Messages addressed to S(n) can be contained. - The message-block is not addressed to itself: - extract messages addressed to S(n) - append own proposals and authentication request according to configured policies - if S(n) is trustee of systems before it (S(n-x)), do proxy authentication for these system³s messages. - If S(n) wants to securely derive it's filtering rules (TRD) but doesn't need own SAs, request authentication of according messages An incoming message-block on system S(n) has the following format. K. Martius [Page 22]
Internet Draft MIKE June 1999 For clearness only the relevant fields in a message are shown; MDKMP Header - E-Cookies, HMAC and message-block addresses - are omitted): Messageblock 1 S(n-1) -> S(n): { M1 : I->R [M2 : I->S(R-1) ] ... [M(x) : I->S(n) ] - [M(x+1): S(1)->R ] ... [M(y) : S(1)->S(n) ] - .. .. [M(z) : S(n-1)->S(n) ] - } After processing on system S(n) it sends the following block to system S(n+1): Messageblock 1 S(n) -> S(n+1): { M1 : I->R [M2 : I->S(R-1) ] ... [M(x) : I->S(n+1) ] [M(x+1): S(1)->R ] ... [M(y) : S(1)->S(n+1) ] .. .. [M(z) : S(n)->R ] + ... [M(z+a): S(n)->S(n+1) ] + } 6.2 First Message Downflow (R->I): Message processing: Receiving a message-block a second time, S(n) performs the following operations: - The entire message-block is addressed to itself (i.e. SG(n) is identical to the Initiator and every remaining message in the block must be addressed to it): - all messages are responses to by all systems I has send MSG1's K. Martius [Page 23]
Internet Draft MIKE June 1999 to. No further messages are allowed. - S(n) (=I) builds a new message-block for the second (last) upflow, verifies authentication fields, if requested and calculates authentication responses if necessary. - The message-block is not addressed to itself: - S(n) extracts messages addressed to itself (from systems S(n+1)...R). These messages MUST be responses to requests inserted in the first upflow. - if S(n) got SA requests from systems S(n-x) in the first upflow, insert responses - if S(n) is trustee of systems behind it (S(n+x)), do proxy authentication for these system³s messages. - If S(n) wants to securely derive it's filtering rules (TRD) but doesn't need own SAs, request authentication of according messages Message-block format: S(n) receives a message-block in the following format. Messages to be removed are marked by a "-". Message-block 2 S(n-1) -> S(n): { R -> I [ R -> S(I+1) ] ... [ R -> S(n) ] - [S(R-1)->I ] [S(R-1)->S(I+1) ] ... [S(R-1)->S(n) ] - .. .. [S(n+1)->I ] ... [S(n+1)->S(n) ] - } After processing on system S(n) it sends the following block to system S(n-1) (Messages added are marked by a +): Message-block 2 S(n) -> S(n-1): { R -> I [ R -> S(I+1) ] K. Martius [Page 24]
Internet Draft MIKE June 1999 ... [ R -> S(n-1) ] [S(R-1)->I ] [S(R-1)->S(I+1) ] ... [S(R-1)->S(n-1) ] .. .. [S(n) ->I ] + ... [S(n)->S(n-1) ] + } 6.3 Second (last) Message Upflow (I->R): The last message upflow delivers all pending "ACK" messages to authenticate Initiator(s) and their parameters as well as prove their participation in the exchange ("liveliness prove"). S(n) processes the message-block like this: - The message-block is addressed to itself (i.e. SG(n) is identical to the final Responder), every remaining message in the block must be addressed to it. All messages MUST be addressed to S(n) (==R). The exchange ends here and R can generate appropriate key material as well as authenticate all systems it wants to. - The message-block is not addressed to S(n): - extract messages addressed to S(n) - append own messages (responses) resulting from the first downflow. Authenticate messages for systems S(n+x) if required Messageblock format is the same like in the first upflow. 7. Key Generation The final key generation is derived from IKE. However, there are some special conditions to consider: - The secured channel exists along the gateways, but doesn³t protect messages from tampering with by malicious gateways. MIKE therefore provides it³s authentication fields to authenticate parties, if necessary. - Except in PKE mode, all parameters are transmitted in clear (for the involved systems), so no shared secret key from the protocol is available to the parties at this point. K. Martius [Page 25]
Internet Draft MIKE June 1999 - The most important part is the shared Diffie-Hellman secret, calculated by g^xy. It provides the possibility to generate secret individual keys (i.e. only shared between two parties). Basically, this is equivalent to key generation in IKE phase I. So, according to this scheme, a masterkey M_SKEYID is produced, first. For MIKE there is another special situation compared to IKE: Authentication is not absolutely necessary, depending on trust relationships to neighbored systems (see paragraph 5.5.2). That is, a shared authentication value is not necessarily available on both ends. Therefore a default key "1" is introduced. M_SKEYID is calculated initializing the shared prf with the default key and hashing one (if only one-side authentication took place) or the XOR of both authentication values (A2 calculated described in sect. 5.5.3). Cookies are used to bind the final key to the current exchange. M_SKEYID = prf(DEF-KEY,[A2_own][XOR [A2_peer]] | M-CKYI | M-CKYR) Of course, if no authentication took place, M_SKEYID can be calculated by any system on the way. However, it³s not the final key material, but only used as a seed for HMAC function: KEYMAT = prf(M_SKEYID, g^xy | protocol | SPI | Nx | Ny) This key material can only be calculate by the owners of the correct DH values and nonce now, independent of used authentication mode. 8. Restrictions 8.1 Overlapping Tunnels MIKE can establish SAs between any of the involved systems, however, not all combinations are valid. This is the case of overlapping tunnels, which are not allowed. S1 --------ESP-------- S3 S2 -------- AH -------- S4 One may think of an ESP-tunnel from S1 to S3, and AH from S2 to S4. Because packets crossing S2 always carry destination address S3 in one direction (the inner addresses are encrypted) this AH tunnel could never be used. In the other direction S4 -> S2, S4 uses AH tunnel to S2, so S3 wouldn³t apply ESP tunnel because the packet is designated to S2. K. Martius [Page 26]
Internet Draft MIKE June 1999 S1 --------AH-------- S3 S2 --------AH-------- S4 These constellations MUST be recognized (and resolved) by some mechanisms outside MIKE, for instance policy system (SPS). MIKE doesn't care about invalid SA combinations! 8.2 Rekeying / Fault Management A difficult point is the ability to handle rekeying on SA expiry and on system failures resulting in a reboot. IKE provides rekeying in phase II, moreover it³s the intention of phase II. However, if the IKE-SA itself is lost, the full exchange has to be performed again. But this is always relevant between two systems, only. MIKE doesn³t provide this mechanisms, yet, because finally MIKE itself contains only one phase for authentication and key exchange (it uses an IKE-secured channel, but the protocol *in* this channel has only one phase). Therefore, if one SA expires, the whole exchange must start again. (Optimizations are subject to further research.) 9. Comparison Beside the new functionality for "proxy authentication" and "trusted rule derivation", MIKE has a number of advantages compared to direct IKE-exchanges in terms of protocol efficiency, that is: - Minimized number of roundtrips - Only neighbored systems exchange their messages. - In average more public key operations can be done "offline" while waiting for the next message passing compared to a direct exchange (where almost every public key operation has to be performed directly to generate next message) Disadvantages: - new / extended message formats - more state information to hold - Number of public key operations for key generation stays the same because for every SA pair g^xy has to be calculated separately. - No "absolute" identity protection because on gateways ID³s are unencrypted Comparison of the number messages (assuming every gateway needs to authenticate every other system and establishes it³s own SA³s, i.e. the worst case; n: Number of gateways involved) K. Martius [Page 27]
Internet Draft MIKE June 1999 Separate IKE exchanges (assuming aggressive mode): Phase I | Phase II ------------------------------- | -------------------------------- # of exchanges | # of messages | # of exchanges | # of messages | | | ((n+1)(n+2)/2) | 3/2(n+1)(n+2) |((n+1)(n+2)/2) | 3/2(n+1)(n+2) ------------------------------------------------------------------ Total: 3(n+1)(n+2) MIKE: Phase I | MIKE messages ------------------------------- | -------------------------------- # of exchanges | # of messages | # of messages | | (n+1) | 3(n+1) | 3(n+1) ------------------------------------------------------------------ Total: 6(n+1) So for the optimized exchange the number of messages increases linear with the number of gateways, while for a conventional IKE exchange this is a quadratic dependency. Furthermore, this is the worst case in which no former exchange took place (or all established keys are outdated). Every following exchange can build on already established IKE-SA³s (depending on their lifetime). Comparison of the number of public key operations: Basic "cryptographic" idea for the protocol is, that for a given exchange every involved system only has to generate own DH exponents and nonce as like as for a "normal" phase II exchange with PFS (DH- exponents). However, the amount of DH exponentiations stays the same for a given amount of desired SAs, because for an SA between X and Y, X has to calculate g^xy from X³s secret DH value x and IDy1³s public DH value g^y. So in worst case, the number of public key operations stays the same compared to "separated" phase-I / phase-II -exchanges. However, in average more public key operations can be done "offline" while waiting for the next message-block passing, compared to a direct exchange (where almost every public key operation has to be performed "online" to generate the next message). The number of phase-I exchanges now is significantly lower, because only neighbored systems perform this exchange. Nevertheless, an public key based authentication requires 2 public key operations for K. Martius [Page 28]
Internet Draft MIKE June 1999 a one-side authentication and 4 for mutual authentication. These operations are performed by processing AUTH fields. Using proxy authentication, the number of public key operations can be reduced. Authentication requirements can be applied more precise using MIKE. 10. Logical Overview --- ----- -------- --- | I | ----- | SG1 | ... | SG(R-1)| ---- | R | --- ----- -------- --- ************************************************** for instance, Security Policy System (Policy Management) (retrieving / decorrelating / resolving policies) trust establishment ************************************************** | | | | separate lists of policies and necessary SAs | | | | <--------> <-- .... -----> <--------> MIKE authentication and key exchange | | | | SA(R) SA(R) SA(I) SA(I) SA(SG(R-1)) SA(SG(R-1)) SA(SG(1)) SA(SG(1)) ... ... ... ... 11. Security Considerations The entire document discusses a protocol for key management and authentication in complex networks. Establishing SAs and keys is proposed sending an extensible message- block along a secure channel over involved gateways. Authentication of endpoints and protocol parameters is provided by similar mechanisms like in IKE phase I. The secure channel along the gateways is assured by IKE mechanisms (IKE phase I to establish IKE SAs). An detailed review on IKE³s authentication and key generation mechanisms has been done to evaluate how to use them in this protocol [Ma98-2]. 12. Acknowledgments Many thanks to Luis Sanchez, Matt Condell and Charles Lynn from BBN for their contributions and ideas combining approaches of E-IKE (the former approach) and their policy system, which is a really good K. Martius [Page 29]
Internet Draft MIKE June 1999 development for policy management in complex networks! Appendix A Pseudo Code Notation Appendix A.1 - Symbolic functions, Variables and Identifiers - Functions activate_SA activates an SA in SAD / SPD to be ready for use after correct 3rd message add_auth1(A[I/R]) Adds an authentication request to the current messageblock to request authentication of I against R (format depends on authentication method - see "message format"). This is not used for MMA / proxy authentication. add_auth2(AUTH1) Adds an authentication response for request AUTH1. Calculation depends on selected authentication method. Further, if MMA / proxy authentication is requested (i.e. AUTH1 is followed by a number of ID payloads), other messages must be included in the calculation, too. add_msg[2][3](IDci, IDcr) adds a message of type 1, 2 or 3, identified by IDci and IDcr, at the current position into the messageblock. The message contains all the fields described in "message format" check_AUTH checks authentication data do_phase_I(X, Y) performs a "normal" phase I exchange between X and Y extract_msg(IDsg_n, IDux) Extracts current message from messageblock (because it is addressed to SGn) insert_msg(SG(n), X) inserts a temporarily (on last message passing) stored messageblock. mm_auth(S(i)(S(x)..S(n))/S(n)) proxy authentication on a system which is a trustee to some other systems. Syntax: S(i) has to authenticate messages of systems K. Martius [Page 30]
Internet Draft MIKE June 1999 S(x)...S(n) for S(n) new_msg(IDcx) creates a new message for IDcx, but doesn't insert it into the message-block, yet. new_msgblock() creates a new (empty) messageblock to fill it with one or more messages save_msg_to_state saves the current message to state information to insert it in the next message block passing. "Address information": IDci/IDcr of first "non-hash" message to identify the next passing messageblock; (IDux-1, IDuy-1) to identify the correct position of the message in the block. send_msgblock(X -> Y) sends the actual message from X to Y Select_SA(IDci) selects an SA proposal of I according to local policy - Symbolic variables policy a conditional branch (if(policy)) to identify local requirements for authenticating remote systems. trustee A system is trustee to authenticate messages in representation of other systems. TRD "Trusted Rule Derivation" - a system wants to use this feature (described in sect. 3.2 - Identifiers IDcix / IDcrx Initiator / Responder of the current message, not necessarily the initial ones. IDs(nx) ID of a system towards R (+) or I (-), relative to the current system S(n) IDci / IDcr K. Martius [Page 31]
Internet Draft MIKE June 1999 IDs of the first Initiator resp. Responder. S(nx) Any system towards R (+) or I (-). S(n) current system doing some operations. Appendix A.2 - Pseudo Code of MDAKMP - Very first Message on Initiator: S(1) = SG_next; do_phase_I(I, S(1)) new_msgblock() N = (Number of required SAs to systems -> R) for (i=N; i>0; i--) { add_msg1(IDci, IDs(n)) if (policy) add_auth1(AUTH1[S(n)/I]) } send_msgblock (I -> S(1)) end; - First Message Upflow (I->R): /* final responder */ if (IDcr = ownID) { new_msgblock() do with IDcix: { Select_SA(policy) add_msg2(IDcix, IDcr) if (AUTH1) add_auth2(AUTH1) if (policy) add_auth1(AUTH1[R/S(n-x)]) } while (for all messages) send_msgblock(S(n-1)) end; } S(n+1) = SG_next || R; K. Martius [Page 32]
Internet Draft MIKE June 1999 if (no IKE_SA(S(n+1)) do_phase_I(S(n), S(n+1)) /* intermediate gateway */ do { if (IDcrx == own_ID) { extract_msg(S(n-x), S(n)) if (AUTH1) add_auth2(AUTH1) save_msg_to_state } else { if ( (trustee || TRD) && !(SA_req(IDcrx) ) new_msg(IDcrx) } } while (for all messages) /* append own messages, ordered R...S(n+1) */ N = Number of required SAs to systems -> R + messages for trustee & TRD authentication for (i=0; i<N; i++) { add_msg1(IDs(n), IDs(i)) if ( (policy) && !(trustee || TRD) ) add_auth1(AUTH1[S(i)/S(n)]) else mm_auth(AUTH1[S(i)(I..S(n))/S(n)]) } send_message_block(S(n+1)) - Message Downflow (R->I): if (IDci = ownID) { ends_here = TRUE new_msgblock() } do { if (IDcix = ownID) K. Martius [Page 33]
Internet Draft MIKE June 1999 { extract_msg(S(n), S(n+x)) if (AUTH2) check_AUTH if (AUTH1) add_auth2(AUTH2) if (ends_here) add_msg3(IDs(n), IDs(n+x)) else save_msg_to_state } } while(for_all_messages) /* append own messages, ordered I...S(n-1) */ N = Number of required SAs to systems -> R + messages for trustee & TRD authentication for (i=0; i<N; i++) { insert_message(IDs(n), IDs(i)) if ( (policy) && !(trustee || TRD) ) add_auth1(AUTH1[S(i)/S(n)]) else mm_auth(AUTH1[S(i)(R...S(n)/S(n)]) } if (ends_here = TRUE) send_message_block(SG(n+1)) else (send_message_block(SG(n-1)) - Last Message Upflow (I->R) /* final responder */ if (IDcr = ownID) { do with IDcix: { if (AUTH2) check_AUTH if (SA_req(IDcix)) activate_SA; } while (for all messages) end; } /* intermediate gateway */ do { if (IDcrx == own_ID) K. Martius [Page 34]
Internet Draft MIKE June 1999 { extract_msg(S(n-x), S(n)) if (AUTH2) check_AUTH; if (SA_req(IDcix)) activate_SA; } } while (for all messages) /* append own messages, ordered R...S(n+1) */ N = Number of required SAs to systems -> R + messages for trustee & TRD authentication for (i=0; i<N; i++) { add_msg1(IDs(n), IDs(i)) } send_message_block(S(n+1)) Appendix B - Payload Explosion Example The following picture shows a full packet with two MIKE messages, which could occur in the first upflow. The first message requests for AH-SA (SHA), the second for ESP (DES-CBC). Beth require authentication, where the second message requests for MMA of 1st message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ - ~ ISAKMP Header with XCHG of MIKE , ~ ~ Next Payload of ISA_NONCE and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ M ! ISA_HASH ! RESERVED ! Payload Length ! I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ K ~ MIKE Initiator Cookie ~ E ~ ~ ~ MIKE Responder Cookie ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ keyed hash of remaining message ~ H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ e ! ISA_ID ! RESERVED ! Payload Length ! a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ d K. Martius [Page 35]
Internet Draft MIKE June 1999 ~ Source ID of message-block ~ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ r ! ISA_GEN ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Destination ID of message-block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ - ! ISA_GEN ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 1 ~ Source ID of 1st message ~ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Dest. ID of 1st message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_NONCE ! RESERVED ! Payload Length ! M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ e ! Domain Of Interpretation ! s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ s ! Situation ! a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ g ! 0 ! RESERVED ! Payload Length ! e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_KE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_HASH ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Public DH value of this Msg.³s Initiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_NONE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ requested authentication type ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ - ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ K. Martius [Page 36]
Internet Draft MIKE June 1999 ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 2 ~ Source ID of 2nd message ~ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Dest. ID of 2nd message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_NONCE ! RESERVED ! Payload Length ! M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ e ! Domain Of Interpretation ! s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ s ! Situation ! a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ g ! 0 ! RESERVED ! Payload Length ! e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! Proposal #1 !PROTO_IPSEC_ESP! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! Transform #1 ! DES_CBC | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_KE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_HASH ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Public DH value of this Msg.³s Initiator ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ requested authentication type ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ! ISA_NONE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ~ Source ID of 1st message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ - References K. Martius [Page 37]
Internet Draft MIKE June 1999 [HC98] D. Harkins & D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [KA98] Steve Kent, Randall Atkinson, " Security Architecture for the Internet Protocol ", RFC 2401, November 1998. [Kra96] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet", from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security. [Ma98-1] Martius, K.: "An Extended Internet Key Exchange Protocol (E-IKE)", draft-martius-ipsec-eike-01.txt, Internet Draft, work in progess [Ma98-2] Martius, K., "IKE Protocol Analysis", available at: http://www.imib.med.tu-dresden.de/imib/Internet/ike/ [MSST98] D Maughan, M. Schertler, M. Schneider, & J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 [Orm96] H. K. Orman, "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [SC98] L. Sanchez, M. Condell: "Security Policy System", draft- ietf-ipsec-sps-00.txt, Internet Draft, work in progress Author³s Address: Kai Martius secunet Security Networks AG Ammonstr. 72 01067 Dresden Germany Phone: ++49 - 3 51 - 4 39 59 20 Fax: ++49 - 3 51 - 4 39 59 59 EMail: kai@secunet.de K. Martius [Page 38]