authenticatedapnic

IssueDate:Revision:CryptographyApplications:VPNandIPsec30May20152.
0-draftOverviewIntroductiontoVPNIPsecFundamentalsTunnelandTransportModeIPsecArchitectureandComponentsofIPsecInternetKeyExchangeConfiguringIPsecforIPv4andIPv62VirtualPrivateNetworkCreatesasecuretunneloverapublicnetwork–Clienttofirewall–Routertorouter–FirewalltofirewallUsestheInternetasthepublicbackbonetoaccessasecureprivatenetwork–RemoteemployeescanaccesstheirofficenetworkTwotypes:–Remoteaccess–Site-to-siteVPN3VPNImplementationHardware–UsuallyaVPN-typerouter–Pros:highestnetworkthroughput,plugandplay,dualpurpose–Cons:costandlackofflexibilitySoftware–Idealfortwoend-pointsindifferentorganisations–Pros:flexible,andlowrelativecost–Cons:lackofefficiency,morelabortrainingrequired,lowerproductivity;higherlaborcostsFirewall–Pros:costeffective,tri-purpose,hardenstheoperatingsystem–Cons:stillrelativelycostly4VPNProtocolsPPTP(Point-to-PointtunnelingProtocol)–DevelopedbyMicrosofttosecuredial-upconnections–Operatesinthedata-linklayerL2F(Layer2ForwardingProtocol)–DevelopedbyCisco–SimilarasPPTPL2TP(Layer2TunnelingProtocol)–IETFstandard–CombinesthefunctionalityofPPTPandL2FIPsec(InternetProtocolSecurity)–OpenstandardforVPNimplementation–Operatesonthenetworklayer5OtherModernVPNsMPLSVPN–Usedforlargeandsmallenterprises–Pseudowire,VPLS,VPRNGRETunnel–PacketencapsulationprotocoldevelopedbyCisco–Notencrypted–ImplementedwithIPsecL2TPIPsec–UsesL2TPprotocol–UsuallyimplementedalongwithIPsec–IPsecprovidesthesecurechannel,whileL2TPprovidesthetunnel6AdvantagesofVPNCheaperconnection–UsetheInternetconnectioninsteadofaprivateleaselineScalability–Flexibilityofgrowth–EfficiencywithbroadbandtechnologyAvailability–AvailableeverywherethereisanInternetconnection7DisadvantagesofVPNVPNsrequireanin-depthunderstandingofpublicnetworksecurityissuesandproperdeploymentprecautionsAvailabilityandperformancedependsonfactorslargelyoutsideoftheircontrolVPNsneedtoaccommodateprotocolsotherthanIPandexistinginternalnetworktechnology8IPsecProvidesLayer3security(RFC2401)–Transparenttoapplications(noneedforintegratedIPsecsupport)AsetofprotocolsandalgorithmsusedtosecureIPdataatthenetworklayerCombinesdifferentcomponents:–Securityassociations(SA)–Authenticationheaders(AH)–Encapsulatingsecuritypayload(ESP)–InternetKeyExchange(IKE)AsecuritycontextfortheVPNtunnelisestablishedviatheISAKMP9IPSecInternetWhatisIPSecIETFstandardthatenablesencryptedcommunicationbetweenpeers:–Consistsofopenstandardsforsecuringprivatecommunications–Networklayerencryptionensuringdataconfidentiality,integrity,andauthentication–Scalesfromsmalltoverylargenetworks10IPsecStandardsRFC4301"TheIPSecurityArchitecture"–DefinestheoriginalIPsecarchitectureandelementscommontobothAHandESPRFC4302–Definesauthenticationheaders(AH)RFC4303–DefinestheEncapsulatingSecurityPayload(ESP)RFC2408–ISAKMPRFC5996–IKEv2(Sept2010)RFC4835–CryptographicalgorithmimplementationforESPandAH11BenefitsofIPsecConfidentiality–ByencryptingdataIntegrity–RoutersateachendofatunnelcalculatesthechecksumorhashvalueofthedataAuthentication–Signaturesandcertificates–AllthesewhilestillmaintainingtheabilitytoroutethroughexistingIPnetworks"IPsecisdesignedtoprovideinteroperable,highquality,cryptographically-basedsecurityforIPv4andIPv6"-(RFC2401)12BenefitsofIPsecDataintegrityandsourceauthentication–Data"signed"bysenderand"signature"isverifiedbytherecipient–Modificationofdatacanbedetectedbysignature"verification"–Because"signature"isbasedonasharedsecret,itgivessourceauthenticationAnti-replayprotection–Optional;thesendermustprovideitbuttherecipientmayignoreKeymanagement–IKE–sessionnegotiationandestablishment–Sessionsarerekeyedordeletedautomatically–Secretkeysaresecurelyestablishedandauthenticated–Remotepeerisauthenticatedthroughvaryingoptions13DifferentLayersofEncryptionNetworkLayer-IPsecLinkLayerEncryptionApplicationLayer–SSL,PGP,SSH,HTTPS14IPsecModesTunnelMode–EntireIPpacketisencryptedandbecomesthedatacomponentofanew(andlarger)IPpacket.
–FrequentlyusedinanIPsecsite-to-siteVPNTransportMode–IPsecheaderisinsertedintotheIPpacket–Nonewpacketiscreated–Workswellinnetworkswhereincreasingapacket'ssizecouldcauseanissue–Frequentlyusedforremote-accessVPNs15Tunnelvs.
TransportModeIPsecPayloadTCPHeaderIPHeaderWithoutIPsecTransportModeIPsecTunnelModeIPsecPayloadTCPHeaderIPHeaderIPsecHeaderIPHeaderPayloadTCPHeaderIPHeaderIPsecHeaderNewIPHeader16TransportvsTunnelMode17TransportMode:EndsystemsaretheinitiatorandrecipientofprotectedtrafficTunnelMode:GatewaysactonbehalfofhoststoprotecttrafficRoutingUpdateTFTPFileTransferFileTransferIPsecArchitectureESPAHIKEIPsecSecurityPolicyEncapsulatingSecurityPayloadAuthenticationHeaderTheInternetKeyExchange18SecurityAssociations(SA)AcollectionofparametersrequiredtoestablishasecuresessionUniquelyidentifiedbythreeparametersconsistingof–SecurityParameterIndex(SPI)–IPdestinationaddress–Securityprotocol(AHorESP)identifierAnSAiseitheruni-orbidirectional–IKESAsarebidirectional–IPsecSAsareunidirectionalTwoSAsrequiredforabidirectionalcommunicationAsingleSAcanbeusedforAHorESP,butnotboth–mustcreatetwo(ormore)SAsforeachdirectionifusingbothAHandESP19SecurityParameterIndex(SPI)Aunique32-bitidentificationnumberthatispartoftheSecurityAssociation(SA)ItenablesthereceivingsystemtoselecttheSAunderwhichareceivedpacketwillbeprocessed.
Hasonlylocalsignificance,definedbythecreatoroftheSA.
CarriedintheESPorAHheaderWhenanESP/AHpacketisreceived,theSPIisusedtolookupallofthecryptoparameters20HowtoSetUpSAManually–Sometimesreferredtoas"manualkeying"–Youconfigureoneachnode:Participatingnodes(I.
e.
trafficselectors)AHand/orESP[tunnelortransport]CryptographicalgorithmandkeyAutomatically–UsingIKE(InternetKeyExchange)21ISAKMPInternetSecurityAssociationandKeyManagementProtocolUsedforestablishingSecurityAssociations(SA)andcryptographickeysOnlyprovidestheframeworkforauthenticationandkeyexchange,butkeyexchangeisindependentKeyexchangeprotocols–InternetKeyExchange(IKE)–KerberizedInternetNegotiationofKeys(KINK)22AuthenticationHeader(AH)Providessourceauthenticationanddataintegrity–ProtectionagainstsourcespoofingandreplayattacksAuthenticationisappliedtotheentirepacket,withthemutablefieldsintheIPheaderzeroedoutIfbothAHandESPareappliedtoapacket,AHfollowsESPOperatesontopofIPusingprotocol51InIPv4,AHprotectsthepayloadandallheaderfieldsexceptmutablefieldsandIPoptions(suchasIPsecoption)23AHHeaderFormatNextHeader(8bits):indicateswhichupperlayerprotocolisprotected(UDP,TCP,ESP)PayloadLength(8bits):sizeofAHin32-bitlongwords,minus2Reserved(16bits):forfutureuse;mustbesettoallzeroesfornowSPI(32bits):arbitrary32-bitnumberthatspecifiestothereceivingdevicewhichsecurityassociationisbeingused(securityprotocols,algorithms,keys,times,addresses,etc)SequenceNumber(32bits):startat1andmustneverrepeat.
ItisalwayssetbutreceivermaychoosetoignorethisfieldAuthenticationData:ICVisadigitalsignatureoverthepacketanditvariesinlengthdependingonthealgorithmused(SHA-1,MD5)012345678910111213141516171819202122232425262728293031NextHeaderPayloadLengthReservedSecurityParameterIndex(SPI)SequenceNumberAuthenticationData[IntegrityCheckValue(ICV)]24EncapsulatingSecurityPayload(ESP)UsesIPprotocol50ProvidesallthatisofferedbyAH,plusdataconfidentiality–usessymmetrickeyencryptionMustencryptand/orauthenticateineachpacket–EncryptionoccursbeforeauthenticationAuthenticationisappliedtodataintheIPsecheaderaswellasthedatacontainedaspayload25ESPHeaderFormatSPI:arbitrary32-bitnumberthatspecifiesSAtothereceivingdeviceSeq#:startat1andmustneverrepeat;receivermaychoosetoignoreIV:usedtoinitializeCBCmodeofanencryptionalgorithmPayloadData:encryptedIPheader,TCPorUDPheaderanddataPadding:usedforencryptionalgorithmswhichoperateinCBCmodePaddingLength:numberofbytesaddedtothedatastream(maybe0)NextHeader:thetypeofprotocolfromtheoriginalheaderwhichappearsintheencryptedpartofthepacketAuthenticationHeader:ICVisadigitalsignatureoverthepacketanditvariesinlengthdependingonthealgorithmused(SHA-1,MD5)012345678910111213141516171819202122232425262728293031NextHeaderPaddingLengthPayloadData(Variable)Padding(0-255bytes)InitializationVector(IV)SequenceNumberSecurityParameterIndex(SPI)AuthenticationData(ICV)ENCRYPTED26PacketFormatAlterationforAHTransportModeOriginalIPHeaderTCP/UDPDataOriginalIPHeaderAHHeaderTCP/UDPDataAuthenticationHeaderWithoutAHWithAHAuthenticatedexceptformutablefieldsinIPheader(ToS,TTL,HeaderChecksum,Offset,Flags)27PacketFormatAlterationforESPTransportModeOriginalIPHeaderTCP/UDPDataOriginalIPHeaderESPHeaderEncapsulatingSecurityPayloadBeforeapplyingESP:AfterapplyingESP:EncryptedESPAuthenticationAuthenticatedTCP/UDPDataESPTrailer28PacketFormatAlterationforAHTunnelModeOriginalIPHeaderTCP/UDPDataNewIPHeaderAHHeaderDataAuthenticationHeaderBeforeapplyingAH:AfterapplyingAH:AuthenticatedexceptformutablefieldsinnewIPheaderOriginalIPHeader(ToS,TTL,HeaderChecksum,Offset,Flags)29PacketFormatAlterationforESPTunnelModeOriginalIPHeaderTCP/UDPDataNewIPHeaderESPHeaderEncapsulatingSecurityPayloadBeforeapplyingESP:AfterapplyingESP:EncryptedESPAuthenticationAuthenticatedOriginalIPHeaderTCP/UDPDataESPTrailer30InternetKeyExchange(IKE)"AnIPseccomponentusedforperformingmutualauthenticationandestablishingandmaintainingSecurityAssociations.
"(RFC5996)TypicallyusedforestablishingIPsecsessionsAkeyexchangemechanismFivevariationsofanIKEnegotiation:–Twomodes(aggressiveandmainmodes)–Threeauthenticationmethods(pre-shared,publickeyencryption,andpublickeysignature)UsesUDPport50031IKEModesModeDescriptionMainmodeThreeexchangesofinformationbetweenIPsecpeers.
Initiatorsendsoneormoreproposalstotheotherpeer(responder)ResponderselectsaproposalAggressiveModeAchievessameresultasmainmodeusingonly3packetsFirstpacketsentbyinitiatorcontainingallinfotoestablishSASecondpacketbyresponderwithallsecurityparametersselectedThirdpacketfinalizesauthenticationoftheISAKMPsessionQuickModeNegotiatestheparametersfortheIPsecsession.
EntirenegotiationoccurswithintheprotectionofISAKMPsession32InternetKeyExchange(IKE)PhaseI–Establishasecurechannel(ISAKMPSA)–Usingeithermainmodeoraggressivemode–Authenticatecomputeridentityusingcertificatesorpre-sharedsecretPhaseII–Establishesasecurechannelbetweencomputersintendedforthetransmissionofdata(IPsecSA)–Usingquickmode33OverviewofIKETrafficwhichneedstobeprotectedIPsecPeerIPsecPeerIKEPhase1SecurecommunicationchannelIKEPhase2IPsecTunnelSecuredtrafficexchange123434ISAKMPHeaderFormat012345678910111213141516171819202122232425262728293031InitiatorCookieTotalLengthofMessageFlagsResponderCookieNextPayloadExchangeTypeMessageIDMajorVersionMinorVersion35ISAKMPMessageFormat012345678910111213141516171819202122232425262728293031NextPayload:1byte;identifierfornextpayloadinmessage.
IfitisthelastpayloadItwillbesetto0Reserved:1byte;setto0PayloadLength:2bytes;lengthofpayload(inbytes)includingtheheaderPayload:TheactualpayloaddataNextPayloadReservedPayloadLengthPayloadNextPayloadReservedPayloadLengthPayloadISAKMPHEADER36IKEPhase1(MainMode)MainmodenegotiatesanISAKMPSAwhichwillbeusedtocreateIPsecSAsThreesteps–SAnegotiation(encryptionalgorithm,hashalgorithm,authenticationmethod,whichDFgrouptouse)–DoaDiffie-Hellmanexchange–Provideauthenticationinformation–Authenticatethepeer37IKEPhase1(MainMode)ResponderInitiator12IKEMessage1(SAproposal)IKEMessage2(acceptedSA)IKEMessage3(DHpublicvalue,nonce)IKEMessage4(DHpublicvalue,nonce)IKEMessage5(Authenticationmaterial,ID)IKEMessage6(Authenticationmaterial,ID)43NegotiateIKEPolicyAuthenticatedDHExchangeComputeDHsharedsecretandderivekeyingmaterialProtectIKEPeerIdentityInternet(Encrypted)38IKEPhase1(AggressiveMode)Uses3(vs6)messagestoestablishIKESANodenialofserviceprotectionDoesnothaveidentityprotectionOptionalexchangeandnotwidelyimplemented39IKEPhase2(QuickMode)AlltrafficisencryptedusingtheISAKMPSecurityAssociationEachquickmodenegotiationresultsintwoIPsecSecurityAssociations(oneinbound,oneoutbound)Creates/refresheskeys40IKEPhase2(QuickMode)ResponderInitiator3ComputekeyingmaterialInternetMessage1(authentication/keyingmaterialandSAproposal)Message2(authentication/keyingmaterialandacceptedSA)Message3(hashforproofofintegrity/authentication)125Validatemessage1746Validatemessage3Validatemessage241IKEv2:ReplacementforCurrentIKESpecificationFeaturePreservation–MostfeaturesandcharacteristicsofbaselineIKEv1protocolarebeingpreservedinv2CompilationofFeaturesandExtensions–QuiteafewfeaturesthatwereaddedontopofthebaselineIKEprotocolfunctionalityinv1arebeingreconciledintothemainlinev2frameworkSomeNewFeatures42IKEv2:WhatIsNotChangingFeaturesinv1thathavebeendebatedbutareultimatelybeingpreservedinv2–Mostpayloadsreused–Useofnoncestoensureuniquenessofkeysv1extensionsandenhancementsbeingmergedintomainlinev2specification–Useofa'configurationpayload'similartoMODECFGforaddressassignment–'X-auth'typefunctionalityretainedthroughEAP–UseofNATDiscoveryandNATTraversaltechniques43IKEv2:WhatIsChangingSignificantChangesBeingtotheBaselineFunctionalityofIKE–EAPadoptedasthemethodtoprovidelegacyauthenticationintegrationwithIKE–Publicsignaturekeysandpre-sharedkeys,theonlymethodsofIKEauthentication–Useof'statelesscookie'toavoidcertaintypesofDOSattacksonIKE–Continuousphaseofnegotiation44HowDoesIKEv2WorkIKE_SA_INIT(TwoMessages)IKE_AUTH(TwoMessages)ProtectedDataIKE_SAAuthenticationParametersNegotiatedIKEAuthenticationOccursandOneCHILD_SACreatedCREATE_CHILD_SA(TwoMessages)SecondCHILD_SACreated45ConsiderationsForUsingIPsecSecurityServices–Dataoriginauthentication–Dataintegrity–Replayprotection–ConfidentialitySizeofnetworkHowtrustedareendhosts–canaprioricommunicationpoliciesbecreatedVendorsupportWhatothermechanismscanaccomplishsimilarattackriskmitigation46Non-VendorSpecificDeploymentIssuesHistoricalPerception–Configurationnightmare–NotinteroperablePerformancePerception–Needempiricaldata–WhereistherealperformancehitStandardsNeedCohesion47VendorSpecificDeploymentIssuesLackofinteroperabledefaults–AdefaultdoesNOTmandateaspecificsecuritypolicy–DefaultscanbemodifiedbyendusersConfigurationcomplexity–Toomanyknobs–Vendor-specificterminologyGoodNews:IPv6supportinmostcurrentimplementations48IPsecConcernsAreenoughpeopleawarethatIKEv2isnotbackwardscompatiblewithIKEv1–IKEv1isusedinmostIPsecimplementations–WillIKEv2implementationsfirsttryIKEv2andthenreverttoIKEv1IsIPsecimplementedforIPv6–SomeimplementationsshipIPv6capabledeviceswithoutIPseccapabilityandhostrequirementsischangedfromMUSTtoSHOULDimplementOSPFv3–Allvendors'IF'theyimplementIPsecusedAH–LateststandardtodescribehowtouseIPsecsaysMUSTuseESPw/NullencryptionandMAYuseAH49IPsecConcerns(cont)Whatistransportmodeinteroperabilitystatus–WillenduserauthenticationbeinteroperablePKIIssues–Whichcertificatesdoyoutrust–HowdoesIKEv1and/orIKEv2handleproposalswithcertificates–Shouldcommontrustedrootsbeshippedbydefault–Whoisfollowingandimplementingpki4ipsec-ikecert-profile(rfc4945)Havemobilityscenariosbeentested–MobilitystandardsrelyheavilyonIKEv2ESP–howdetermineifESP-NullvsEncrypted50IPsecBestPracticesUseIPsectoprovideintegrityinadditiontoencryption–UseESPoptionUsestrongencryptionalgorithms–AESinsteadofDESUseagoodhashingalgorithm–SHAinsteadofMD5ReducethelifetimeoftheSecurityAssociation(SA)byenablingPerfectForwardSecrecy(PFS)–Increasesprocessorburdensodothisonlyifdataishighlysensitive51ConfiguringIPsecStep1:ConfiguretheIKEPhase1Policy(ISAKMPPolicy)cryptoisakmppolicy[priority]Step2:SettheISAKMPIdentitycryptoisakmpidentity{ipaddress|hostname}Step3:ConfiguretheIPsectransfersetcryptoipsectransform-settransform-set-namemode[tunnel|transport]cryptoipsecsecurity-associationlifetimesecondsseconds52ConfiguringIPsecStep5:Creatingmapwithnamecryptomapcrypto-map-nameseq-numipsec-isakmpmatchaddressaccess-list-idsetpeer[ipaddress|hostname]settransform-settransform-set-namesetsecurity-associationlifetimesecondssecondssetpfs[group1|group2]Step6:ApplytheIPsecPolicytoanInterfacecryptomapcrypto-map-namelocal-addressinterface-id53IPsecLayoutR1R2EncryptedsessionPublicNetwork54RouterConfigurationcryptoisakmppolicy1authenticationpre-shareencryptionaeshashshagroup5cryptoisakmpkeyTraining123address172.
16.
11.
66!
cryptoipsectransform-setESP-AES-SHAesp-aesesp-sha-hmac!
cryptomapLAB-VPN10ipsec-isakmpmatchaddress101settransform-setESP-AES-SHAsetpeer172.
16.
11.
66Phase1SAEncryptionandauthenticationPhase2SA55RouterConfigurationintfa0/1cryptomapLAB-VPNExit!
access-list101permitip172.
16.
16.
00.
0.
0.
255172.
16.
20.
00.
0.
0.
255ApplytoanoutboundinterfaceDefineinterestingVPNtraffic56IPsecDebugCommandsshcryptoipsecsashcryptoisakmppeersshcryptoisakmpsashcryptomap57Capture:Telnet58Capture:Telnet+IPsec59PrettyGoodIPsecPolicyIKEPhase1(akaISAKMPSAorIKESAorMainMode)–3DES(AES-192ifbothendssupportit)–Lifetime(8hours=480min=28800sec)–SHA-2(256bitkeys)–DHGroup14(akaMODP#14)IKEPhase2(akaIPsecSAorQuickMode)–3DES(AES-192ifbothendssupportit)–Lifetime(1hour=60min=3600sec)–SHA-2(256bitkeys)–PFS2–DHGroup14(akaMODP#14)6061THANKYOUwww.
facebook.
com/APNICwww.
twitter.
com/apnicwww.
youtube.
com/apnicmultimediawww.
flickr.
com/apnicwww.
weibo.
com/APNICrir62