【VIP專享】第十一講-協(xié)議安全課件(2)

1、Protocols and Security()school of computermengbomengscuecgIPSecSecurity Issues in IPsource spoofingreplay packetsno data integrity or confidentiality DOS attacks Replay attacks Spying and moreFundamental Issue: Networks are not (and will never be) fully secureIPSec and SSLIPSec lives at the network

2、layerIPSec is transparent to applicationsapplicationtransportnetworklinkphysicalSSLOSUserNICIPSecAn IPSec scenarioIPSec and ComplexityIPSec is a complex protocolOver-engineeredLots of generally useless extra featuresFlawedSome serious security flawsInteroperability is serious challengeDefeats the pu

3、rpose of having a standard!ComplexDid I mention, its complex?IPSec ArchitectureESPAHIKEIPSec Security PolicyEncapsulating SecurityPayloadAuthentication HeaderThe Internet Key ExchangeIKE and ESP/AHTwo parts to IPSecIKE: Internet Key ExchangeMutual authenticationEstablish shared symmetric keyTwo “pha

4、ses” like SSL session/connectionESP/AHESP: Encapsulating Security Payload for encryption and/or integrity of IP packetsAH: Authentication Header integrity onlyIPsec servicesIKESecurity Associationsa one-way relationship between sender & receiver that affords security for traffic flowIf a peer relati

5、onship is needed, for two-way secure exchange, then two security associations are required. uniquely identified by 3 parameters:Security Parameters Index (SPI)IP Destination AddressSecurity Protocol Identifierhas a number of other parametersseq no, AH & EH info, lifetime etchave a database of Securi

6、ty AssociationsSecurity services are afforded to an SA for the use of AH or ESP, but not both.Authentication Header (AH)provides support for data integrity & authentication of IP packetsend system/router can authenticate user/appprevents address spoofing attacks by tracking sequence numbersbased on

7、use of a MACHMAC-MD5-96 or HMAC-SHA-1-96parties must share a secret keyEncapsulating Security Payload (ESP)provides message content confidentiality & limited traffic flow confidentialitycan optionally provide the same authentication services as AHsupports range of ciphers, modes, paddingincl. DES, T

8、riple-DES, RC5, IDEA, CAST etcCBC & other modespadding needed to fill block size, fields, for traffic flowIKEIKE has 2 phasesPhase 1 IKE security association (SA)Phase 2 AH/ESP security associationPhase 1 is comparable to SSL session Phase 2 is comparable to SSL connection Not an obvious need for tw

9、o phases in IKEIf multiple Phase 2s do not occur, then it is more expensive to have two phases!IKE Phase 1Four different “key” optionsPublic key encryption (original version)Public key encryption (improved version)Public key signatureSymmetric keyFor each of these, two different “modes”Main modeAggr

10、essive modeThere are 8 versions of IKE Phase 1!Evidence that IPSec is over-engineered?IKE Phase 1Well discuss 6 of 8 phase 1 variantsPublic key signatures (main and aggressive modes)Symmetric key (main and aggressive modes)Public key encryption (main and aggressive)Why public key encryption and publ

11、ic key signatures?Always know your own private keyMay not (initially) know other sides public keyIKE Phase 1Uses ephemeral Diffie-Hellman to establish session keyAchieves perfect forward secrecy (PFS)Let a be Alices Diffie-Hellman exponentLet b be Bobs Diffie-Hellman exponentLet g be generator and p

12、 primeRecall p and g are publicIKE Phase 1: Digital Signature (Main Mode)CP = crypto proposed, CS = crypto selectedIC = initiator “cookie”, RC = responder “cookie”K = h(IC,RC,gab mod p,RA,RB)SKEYID = h(RA, RB, gab mod p)proofA = h(SKEYID,ga,gb,IC,RC,CP,“Alice”)AliceAliceBobIC, CPIC,RC, CSIC,RC, ga m

13、od p, RAIC,RC, E(“Alice”, proofA, K)IC,RC, gb mod p, RBIC,RC, E(“Bob”, proofB, K)IKE Phase 1: Public Key Signature (Aggressive Mode)Main difference from main modeNot trying to protect identitiesCannot negotiate g or pAliceBobIC, “Alice”, ga mod p, RA, CPIC,RC, “Bob”, RB, gb mod p, CS, proofBIC,RC, p

14、roofAMain vs Aggressive ModesMain mode MUST be implementedAggressive mode SHOULD be implementedIn other words, if aggressive mode is not implemented, “you should feel guilty about it”Might create interoperability issuesFor public key signature authenticationPassive attacker knows identities of Alice

15、 and Bob in aggressive modeActive attacker can determine Alices and Bobs identity in main modeIKE Phase 1: Symmetric Key (Main Mode)Same as signature mode exceptKAB = symmetric key shared in advance K = h(IC,RC,gab mod p,RA,RB,KAB)SKEYID = h(K, gab mod p)proofA = h(SKEYID,ga,gb,IC,RC,CP,“Alice”)Alic

16、eBobIC, CPIC,RC, CSIC,RC, ga mod p, RAIC,RC, E(“Alice”, proofA, K)IC,RC, gb mod p, RBIC,RC, E(“Bob”, proofB, K)Problems with Symmetric Key (Main Mode)Catch-22Alice sends her ID in message 5Alices ID encrypted with KTo find K Bob must know KABTo get KAB Bob must know hes talking to Alice!Result: Alic

17、es ID must be IP address!Useless mode for the “road warrior”Why go to all of the trouble of trying to hide identities in 6 message protocol?IKE Phase 1: SymmetricKey (Aggressive Mode)Same format as digital signature aggressive modeNot trying to hide identitiesAs a result, does not have problems of m

18、ain modeBut does not (pretend to) hide identitiesAliceBobIC, “Alice”, ga mod p, RA, CPIC,RC, “Bob”, RB, gb mod p, CS, proofBIC,RC, proofAIKE Phase 1: Public Key Encryption (Main mode)CP = crypto proposed, CS = crypto selectedIC = initiator “cookie”, RC = responder “cookie”K = h(IC,RC,gab mod p,RA,RB

19、)SKEYID = h(RA, RB, gab mod p)proofA = h(SKEYID,ga,gb,IC,RC,CP,“Alice”)AliceBobIC, CPIC,RC, CSIC,RC, ga mod p, RABob, “Alice”BobIC,RC, E(proofA, K)IC,RC, gb mod p, RBAlice, “Bob”AliceIC,RC, E(proofB, K)IKE Phase 1: Public Key Encryption (Aggressive Mode)K, proofA, proofB computed as in main modeNote

20、 that identities are hiddenThe only aggressive mode to hide identitiesThen why have main mode?AliceBobIC, CP, ga mod p,“Alice”Bob, RABobIC,RC, CS, gb mod p, “Bob”Alice, RBAlice, proofBIC,RC, proofAPublic Key Encryption Issue?Public key encryption, aggressive modeSuppose Trudy generatesExponents a an

21、d bNonces RA and RBTrudy can compute “valid” keys and proofs: gab mod p, K, SKEYID, proofA and proofBAlso true of main modePublic Key Encryption Issue?Trudyas AliceTrudyas BobTrudy can create exchange that appears to be between Alice and BobAppears valid to any observer, including Alice and Bob!IC,R

22、C, CS, gb mod p, “Bob”Alice, RBAlice, proofBIC,RC, proofAIC, CP, ga mod p,“Alice”Bob, RABobPlausible DeniabilityTrudy can create “conversation” that appears to be between Alice and BobAppears valid, even to Alice and Bob!A security failure?In this mode of IPSec, it is a featurePlausible deniability:

23、 Alice and Bob can deny that any conversation took place!In some cases it might be a security failureIf Alice makes a purchase from Bob, she could later repudiate it (unless she had signed) IKE Phase 1 CookiesCookies (or “anti-clogging tokens”) supposed to make denial of service more difficultNo rel

24、ation to Web cookiesTo reduce DoS, Bob wants to remain stateless as long as possibleBut Bob must remember CP from message 1 (required for proof of identity in message 6)Bob must keep state from 1st message on!These cookies offer little DoS protection!IKE Phase 1 SummaryResult of IKE phase 1 is Mutua

25、l authenticationShared symmetric keyIKE Security Association (SA)But phase 1 is expensive (in public key and/or main mode cases)Developers of IKE thought it would be used for lots of things not just IPSecPartly explains over-engineeringIKE Phase 2Phase 1 establishes IKE SAPhase 2 establishes IPSec S

26、AComparison to SSL SSL session is comparable to IKE Phase 1SSL connections are like IKE Phase 2IKE could be used for lots of thingsBut in practice, its not!IKE Phase 2Key K, IC, RC and SA known from Phase 1Proposal CP includes ESP and/or AHHashes 1,2,3 depend on SKEYID, SA, RA and RBKeys derived fro

27、m KEYMAT = h(SKEYID,RA,RB,junk)Recall SKEYID depends on phase 1 key methodOptional PFS (ephemeral Diffie-Hellman exchange)AliceBobIC,RC,CP,E(hash1,SA,RA,K)IC,RC,CS,E(hash2,SA,RB,K)IC,RC,E(hash3,K)IPSecAfter IKE Phase 1, we have an IKE SAAfter IKE Phase 2, we have an IPSec SABoth sides have a shared

28、symmetric keyNow what?We want to protect IP datagramsBut what is an IP datagram?From the perspective of IPSecIP ReviewWhere IP header is IP headerdataIP datagram is of the form IP and TCPConsider HTTP traffic (over TCP)IP encapsulates TCPTCP encapsulates HTTPIP headerTCP hdrHTTP hdrapp dataIP header

29、dataIP data includes TCP header, etc.IPSec Transport ModeIPSec Transport ModeIP headerdataIP headerESP/AHdataTransport mode designed for host-to-hostTransport mode is efficientAdds minimal amount of extra headerThe original header remainsPassive attacker can see who is talkingIPSec Tunnel ModeIPSec

30、Tunnel ModeIP headerdatanew IP hdrESP/AHIP headerdataTunnel mode for firewall to firewall trafficOriginal IP packet encapsulated in IPSecOriginal IP header not visible to attackerNew header from firewall to firewallAttacker does not know which hosts are talkingComparison of IPSec ModesTransport Mode

31、Tunnel ModeIP headerdataIP headerESP/AHdataIP headerdatanew IP hdrESP/AHIP headerdataTransport ModeHost-to-hostTunnel ModeFirewall-to-firewallTransport mode not necessaryTransport mode is more efficientCombining Security AssociationsSAs can implement either AH or ESPto implement both need to combine

32、 SAsform a security association bundlemay terminate at different or same endpointscombined bytransport adjacencyiterated tunnelingissue of authentication & encryption order IPSec ModesTransport Mode vs. Tunnel Mode EncryptionTransport Mode vs. Tunnel Mode EncryptionCombining Security AssociationsCom

33、bining Security AssociationsCombining Security AssociationsCombining Security AssociationsIPSec SecurityWhat kind of protection?Confidentiality?Integrity?Both?What to protect?Data?Header?Both?ESP/AH do some combinations of theseSSL vs IPSecIPSec discussed in next sectionLives at the network layer (p

34、art of the OS)Has encryption, integrity, authentication, etc.Is overly complex (including serious flaws)SSL (and IEEE standard known as TLS)Lives at socket layer (part of user space)Has encryption, integrity, authentication, etc.Has a simpler specificationSSL vs IPSecIPSec implementationRequires cha

35、nges to OS, but no changes to applicationsSSL implementationRequires changes to applications, but no changes to OSSSL built into Web application early on (Netscape)IPSec used in VPN applications (secure tunnel)Reluctance to retrofit applications for SSLReluctance to use IPSec due to complexity and i

36、nteroperability issuesResult? Internet less secure than it should be!KerberosKerberos trusted key server system from MIT provides centralised symmetric encryption third-party authentication in a distributed network allows users access to services distributed through network without needing to trust

37、all workstations rather all trust a central authentication server two versions in use: 4 & 5Kerberos Requirements its first report identified requirements as: secure reliable transparent scalable implemented using an authentication protocol based on Needham-SchroederMotivation for KerberosAuthentica

38、tion using public keysN users N key pairsAuthentication using symmetric keysN users requires about N2 keysSymmetric key case does not scale!Kerberos based on symmetric keys but only requires N keys for N usersBut must rely on TTPAdvantage is that no PKI is requiredKerberos KDCKerberos Key Distributi

39、on Center or KDCActs as a TTPTTP must not be compromised!KDC shares symmetric key KA with Alice, key KB with Bob, key KC with Carol, etc.Master key KKDC known only to KDCKDC enables authentication and session keysKeys for confidentiality and integrityIn practice, the crypto algorithm used is DESKerb

40、eros TicketsKDC issues a ticket containing info needed to access a network resourceKDC also issues ticket-granting tickets or TGTs that are used to obtain ticketsEach TGT containsSession keyUsers IDExpiration timeEvery TGT is encrypted with KKDCTGT can only be read by the KDCKerberized LoginAlice en

41、ters her passwordAlices workstationDerives KA from Alices passwordUses KA to get TGT for Alice from the KDCAlice can then use her TGT (credentials) to securely access network resourcesPlus: Security is transparent to AliceMinus: KDC must be secure its trusted!Kerberized LoginAliceAlicesAlice wantspa

42、ssword a TGTE(SA,TGT,KA)KDCKey KA derived from Alices passwordKDC creates session key SAWorkstation decrypts SA, TGT, forgets KATGT = E(“Alice”,SA, KKDC)ComputerAlice Requests Ticket to BobAliceTalk to BobI want totalk to BobREQUESTREPLYKDCREQUEST = (TGT, authenticator) whereauthenticator = E(timest

43、amp,SA)REPLY = E(“Bob”,KAB,ticket to Bob, SA)ticket to Bob = E(“Alice”,KAB,KB)KDC gets SA from TGT to verify timestampComputerAlice Uses Ticket to Bobticket to Bob, authenticatorE(timestamp + 1,KAB)ticket to Bob = E(“Alice”,KAB, KB)authenticator = E(timestamp, KAB)Bob decrypts “ticket to Bob” to get

44、 KAB which he then uses to verify timestampAlices ComputerBobKerberosSession key SA used for authentication Can also be used for confidentiality/integrityTimestamps used for mutual authenticationRecall that timestamps reduce number of messagesActs like a nonce that is known to both sidesNote: time is a security-critical parameter!Kerberos v4 Overview a basic third-party authentication scheme have an Authentication Server (AS) users initially negotiate with AS to identify self AS provides a non-corruptible authentication credentia