TCP IP

Podstrony

[ Pobierz całość w formacie PDF ]
.Chapter 5.TCP/IP Security Overview 321HashA Hash Payload must immediately follow the ISAKMP header.HASH_1uses the keyed pseudo-random function that was negotiated during thePhase 1 exchanges, and is derived from the following information:SKEYID_a was derived from the Phase 1 exchanges.M-ID is the message ID of this message.SA is the Security Association payload carried in this message,including all proposals that were offered.Nonce is a new value different from the one used in Phase 1.KE is the public Diffie-Hellman value carried in this message.Thisquantity is chosen by Host-A, and is denoted as gqmx.Note that thisis not the same quantity as gx that was used in the Phase 1exchanges.IDs, which can identify either the endpoints of the Phase 1 exchangeor endpoints on whose behalf the protocol SA should be negotiated(proxy IDs when IKE is used in client mode).These cansubsequently be different from the IDs used in Phase 1.Note: The use of KE and ID is optional depending if PFS is desired.HASH_1 = prf(SKEYID_a, M-ID, SA, Nqmi, KE, IDqmi, IDqmr)Security AssociationIndicate IP as the Domain of Interpretation.Proposal, Transform PairsThere can be one or more of these pairs in this message.The firstproposal payload will be numbered 1, will identify an IPSec protocol to beused, and will include an SPI value that is randomly chosen by Host-A foruse with that protocol.The proposal payload will be followed by a singletransform payload that indicates the cryptographic algorithm to be usedwith that protocol.The second proposal payload will be numbered 2, etc.Nonce PayloadThis contains the nonce Nqmi that was chosen randomly by Host-A.KE This is the key exchange payload that will carry the public Diffie-Hellmanvalue chosen by Host-A, gqmx.There is also a field called Group, thatindicates the prime number and generator used in the Diffie-Hellmanexchange.ID PayloadSpecifies the endpoints for this SA.2.IKE Phase 2, Message 2After Host-B receives Message 1 from Host-A and successfully authenticates itusing HASH_1, it constructs a reply, Message 2, to be sent back to Host-A.The Message ID of the reply will be the same one that Host-A used inMessage 1.Host-B will choose new values for the following:HashThe hash payload now carries the value HASH_2, which is defined as:HASH_2 = prf(SKEYID_a, Nqmi, M-ID, SA, Nqmr, KE, IDqmi, IDqmr)322 TCP/IP Tutorial and Technical OverviewSecurity AssociationThe Security Association payload only describes the single chosenproposal and its associated transforms, not all of the protection suitesoffered by Host-A.Host-B also chooses an SPI value for the selectedprotocol.Host-B's SPI does not depend in any way on the SPI thatHost-A assigned to that protocol when it offered the proposal.That is, itis not necessary that SPIA be the same as SPIB; it is only necessary thatthey each be non-zero and that they each be randomly chosen.NonceNonce payload now carries Nr, a random value chosen by Host-B.KE Key exchange payload now carries Host-B's public Diffie-Hellman value,gqmy.At this point, Host-A and Host-B have exchanged nonces and publicDiffie-Hellman values.Each one can use this in conjunction with otherinformation to derive a pair of keys, one for each direction of transmission.3.Generating the Keys (Phase 2)Using the nonces, public Diffie-Hellman values, SPIs, protocol code pointsexchanged in Messages 1 and 2 of Phase 2, and the SKEYID value fromPhase 1, each host now has enough information to derive two sets of keyingmaterial.a.When PFS is used:For data generated by Host-A and received by Host-B, the keyingmaterial is:KEYMATAB = prf(SKEYID_d, gqmxy, protocol, SPIB, Nqmi, Nqmr )For data generated by Host-B and received by Host-A, the keyingmaterial is:KEYMATBA = prf(SKEYID_d, gqmxy, protocol, SPIA, Nqmi, Nqmr)b.When PFS is not used:For data generated by Host-A and received by Host-B, the keyingmaterial is:KEYMATAB = prf(SKEYID_d, protocol, SPIB, Nqmi, Nqmr )For data generated by Host-B and received by Host-A, the keyingmaterial is:KEYMATBA = prf(SKEYID_d, protocol, SPIA, Nqmi, Nqmr)Note: Depending on the particular case, Host-A may need to derive multiplekeys for the following purposes:Generating the integrity check value for transmitted datagramsValidating the integrity check value of received datagramsChapter 5.TCP/IP Security Overview 323 Encrypting transmitted datagramsDecrypting received datagramsLikewise, Host-B needs to derive the mirror image of the same keys.For example, the key that Host-B uses to encrypt its outboundmessages is the same key that Host-A uses to decrypt its inboundmessages, etc.4.IKE Phase 2, Message 3At this point, Host-A and Host-B have exchanged all the information necessaryfor them to derive the necessary keying material.The third message in theQuick Mode exchange is used by Host-A to prove its liveness, which it does byproducing a hash function that covers the message ID and both nonces thatwere exchanged in Messages 1 and 2.Message 3 consists only of theISAKMP header and a hash payload that carries:HASH_3 = prf(SKEYID_a, , M-ID, Nqmi, Nqmr)When Host-B receives this message and verifies the hash, then both systemscan begin to use the negotiated security protocols to protect their user datastreams.5.5.5.3 Negotiating Multiple Security AssociationsIt is also possible to negotiate multiple security associations, each with its own setof keying material, within a single 3-message Quick Mode exchange.The message formats are very similar to the previously illustrated ones, so only thedifferences will be highlighted below:Message 1 will carry multiple security association payloads, each offering arange of protection suites.HASH_1 will cover the entire set of all offered Security Associations carried inMessage 1.That is, each Security Association and all of its offered proposalsare included.In Message 2, for each offered SA, Host-B will select a single protection suite.That is, if n SAs are open for negotiation, then Host-B will choose n protectionsuites, one from each proposal.As was the case for HASH_1, HASH_2 will now cover the entire set of alloffered security associations carried in Message 1.That is, each securityassociation and all of its offered proposals are included.After Messages 1 and 2 have been exchanged, then Host-A and Host-B will beable to generate the keying material for each of the accepted protection suites,using the same formulas as in 3 on page 323, applied individually for eachaccepted SA.Even though the nonces and the public Diffie-Hellman valuesare the same for all selected suites, the keying material derived for eachselected protection suite will be different because each proposal will have adifferent SPI.Because multiple security associations have been negotiated, it is a matter oflocal choice as to which one is used to protect a given datagram.A receivingsystem must be capable of processing a datagram that is protected by any SAthat has been negotiated.That is, it would be legal for a given source host to324 TCP/IP Tutorial and Technical Overviewsend two consecutive datagrams to a destination system, where each datagramwas protected by a different SA.5.5.5.4 Using IKE with Remote AccessThe critical element in the remote access scenario is the use of Oakley to identifythe remote host by name, rather than by its dynamically assigned IP address [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

bezglutenowo.pev.pl