ericssonhistory.com

More documents

Recommendations

Info

Figure 4Construction of an ESP-protected IP packet in transport mode. IPsec outgoing messagesare processed for Internet protocol version 4 (IPv4). In the encapsulation security payload(ESP) transport mode, in which the payload is encrypted and the integrity of the ESP headerand payload are protected, the communication peers share a security association databasethat contains parameters necessary for secure communication. The database containsshared secret keys and a counter that counts each packet sent over the channel. Asequence number identifies the secure session. The encryption and authentication functionsare denoted by f and h respectively.Protocols for Internet securityCryptographic algorithms make up thebasic mechanisms for secure communication.But we also need standardized ways ofauthenticating users, exchanging keys, decidingwhich algorithm and message formatsto use, and so on. This is where protocolscome into play. Several different securityprotocols are in use in the Internet; forexample, TLS 2 , SSH 5 , IPsec 4 and IKE 5 , eachof which uses common techniques to establisha secure session.• Authentication. Before a communicationsession can begin, the communicatingparties must verify each other's identity.An authentication protocol does this. Authenticationcan be based on a public orsecret key. If public keys are used, theyare often obtained using some kind ofpublic key infrastructure (PKI).• Cryptographic algorithms. The communicatingparties negotiate to determinewhich cryptographic algorithms shouldbe used for exchanging keys and protectingdata.• Key exchange. The parties exchange cryptographicsession keys. This phase oftenincludes public key cryptography.• Generation of session keys. Symmetric sessionkeys are calculated and used to en-Figure 5IKE Phase I mode, authentication withsignatures.100 Ericsson Review No. 2, 2000
crypt all subsequent packets and to appenda MAC field to each packet.The different protocols protect informationat different levels in the protocol stack. TheIP security (IPsec) protocol, which is a technologythat protects all IP packets at the networklayer, forms a secure layer from onenetwork node to another. IPsec can even beused to create IP-based VPNs. However, theprotocol does not stipulate how peers are tobe authenticated or session keys are exchanged.These tasks are handled by the Internetkey exchange (IKE) protocol.The secure shell (SSH) protocol is the basicprotocol for remote terminal connectionsover the Internet. It is used to make securetext-based management connections to networknodes. The transport level security(TLS, formerly secure socket layer, SSL) protocolis used to protect secure Web servers,such as those used in Internet banking solutions.The WAP Forum has standardizedits own version of the TLS protocol, calledwireless TLS (WTLS). An important distinctionbetween the two protocols is thatWTLS can be used over an unreliable transportlayer such as the user datagram protocol(UDP); TLS cannot (Figure 6).IPsec, SSH, and TLS are useful in theirown special areas. For a terminal-connectionFigure 6The different security layers and their positions in an IP stack.application, SSH has authentication mechanismsthat make it the best choice. Forclient-server applications where the clientside involves human interaction, TLS is preferred.However, to encrypt all packets, includingconnectionless packets and IP controlpackets, IPsec is a good choice. IPsec isBOX C, IKEThe Internet key exchange (IKE) protocol is usedto establish a security association (SA) betweentwo peers. An SA is a shared secret (togetherwith a policy for the secret) between the communicatingparties. The SA is needed to protectreal communication between peers. IKE is generallyused to negotiate an SA for IPsec. IKE isbased on the Internet security association andkey management protocol (ISAKMP), whichsuggests a key negotiation based on two differentphases:Phase IThe two peers establish a secure channel for furthercommunication by negotiating ISAKMPSAs.Phase IIUnder the protection of the SA negotiated inPhase I, the peers negotiate SAs that can beused to protect real communication; that is, theIPsec SA.IKE defines two Phase I modes:• MAIN MODE gives authenticated keyexchange with identity protection.• AGRESSIVE MODE gives quicker authenticatedkey exchange without identity protection.For Phase I, IKE defines (for main and aggressivemodes) four different authentication methods:1. authentication with signatures;2. authentication with public key encryption;3. authentication with a revised mode of publickey encryption; and4. authentication with a pre-shared key.In methods 2,3 and 4, it is assumed that the initiatorof the key negotiation has already receivedthe public key or a pre-shared key from therespondent. Figure 5 shows IKE authenticationwith the signature protocol for main and aggressivemodes. The different fields in the protocolare as follows:• HDR—the header field includes a randomcookie chosen by the initiator and respondent.The asterisk (*) in the figure indicates that allpayload following the HDR field is encryptedusing the newly negotiated keys.• SA—the security association field includesseveral parameters together with a proposalfor the cryptographic attributes that the peerwants to use during IKE negotiations. The initiatorsends the proposals; the respondentchooses from among these and returns a newSA.• KE—the value of the public key exchange.• N—a random value used to calculate keymaterials shared by the peers.• ID—an identity field; for example, an IPv4address.• CERT—a certificate that contains a signaturecheck key.• SIG—a digital signature calculated over ahash value. The initiator hash value is obtainedfrom the initiator and respondent cookie values,a "premaster secret," KE values, SAvalue, and the initiator ID. The respondenthash value is obtained in exactly the same waybut using the ID value of the respondent.IKE Phase II has only one mandatory mode:QUICK MODE. IKE Phase II is solely used fornegotiating security parameters for another protocolsuch as IPsec. No certificates are involvedin this phase.Ericsson Review No. 2, 2000 101
Page 1: Ericsson 2/2000REVIEWTHE TELECOMMUN
Page 4 and 5: ContributorsIn this issueLuis Barri
Page 6 and 7: Ericsson Review is also published o
Page 8 and 9: Evolving from cdmaOne to third-gene
Page 10 and 11: Figure 2Operators Harmonization Agr
Page 12 and 13: more features, and greater reliabil
Page 14 and 15: Figure 7Ericsson's third-generation
Page 16 and 17: Figure 11Ericsson's timeline for ev
Page 18 and 19: Third-generation TDMAChristofer Lin
Page 20 and 21: TABLE 1 MODULATION AND CODING SCHEM
Page 22 and 23: Figure 3An example of a cell patter
Page 24 and 25: Figure 5Curves illustrating maximum
Page 26 and 27: TABLE 3. DYNAMIC PACKET DATA SIMULA
Page 28 and 29: erage can be achieved in existing c
Page 30 and 31: Business solutions for mobile e-com
Page 32 and 33: Figure 2Comparison of traditional a
Page 34 and 35: BOX B, THE E-COMMERCE TIMELINE1999E
Page 36 and 37: Figure 6Mobile e-Pay end-user servi
Page 38 and 39: Figure 8Access features with push-a
Page 40 and 41: AuthenticationTo verify that end-us
Page 42 and 43: BOX C, MARKET HARMONIZATIONOn Tuesd
Page 44 and 45: Figure 2The footprint of the RBS 22
Page 46 and 47: Communications security in an all-I
Page 48 and 49: BOX B, SYMMETRIC KEY SYSTEMSGood sy
Page 52 and 53: Figure 7An X.500 database structure
Page 54 and 55: Figure 9GPRS VPN scenarios.Figure 1
Page 56 and 57: TRADEMARKSRC4 and RC4 are registere
Page 58 and 59: HIPERLAN type 2 for broadband wirel
Page 60 and 61: Figure 3Typical usage of communicat
Page 62 and 63: Figure 6Mapping of higher layer pac
Page 64 and 65: TABLE 1PHYSICAL LAYER MODES OF HIPE
Page 66 and 67: Queen City WaterfrontEMERGING PROJE
Page 68 and 69: TABLE 2. IMPORTANT PARAMETERS FOR N
Page 70: Previous issuesNo. 1,2000IPv6—The

ericssonhistory.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?