DOCSLIB.ORG

Advanced Features of Linux Strongswan the Opensource VPN Solution

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Advanced Features of Linux Strongswan the Opensource VPN Solution Advanced Features of Linux strongSwan the OpenSource VPN Solution Institute of Internet Technologies and Applications Hochschule für Technik Rapperswil, Schweiz The powerful advanced features of the Linux strongSwan VPN solution will be presented: IPsec policies based on wildcards, certificate hierarchies or group memberships defined by X.509 attribute certificates; certificate revocation based on the Online Certificate Status Protocol; Virtual IP address assignment; smartcard support; Dead Peer Detection. Also the new and user-friendly strongSwan User-Mode-Linux testing environment will be demonstrated. 1 IPsec-based Virtual Private Networks Figure 1 shows a typical VPN scenario where two subnets 10.1.0.0/16 and 10.2.0.0/16 possessing private network addresses are connected with each other over the Internet by means of a site-to-site VPN tunnel. The tunnel is established between the VPN gateways 11.22.33.44 and 55.66.77.88 which automatically encrypt and authenticate each packet that is being exchanged between the two networks. „R oad Warrior“ VPN Client 10.3.0.2 10.1.0.5 10.2.0.3 55.66.x.x Internet VPN Tunnel Head Subsidiary Quarters VPN Tunnel 10.1.0.0/16VPN Gateway VPN Gateway 10.2.0.0/16 11.22.33.44 55.66.77.88 Figure 1: Typical VPN scenario The second much more challenging scenario depicted in Figure 1 is remote access. So called „road warriors“, equipped with dynamical IP addresses assigned by their local Internet Service Providers (ISPs) are able to build up a VPN tunnel to the security gateway 11.22.33.44 from any point of the Internet using either fixed connections, public WLAN hot spots or mobile communication channels. Thus the remote access clients get full access to all resources in the 10.1.0.0/16 network as if they were located right at Head Quarters. Reprint of LinuxTag2005 Paper 1 We will come back to the special properties of the road warrior case later in this paper and continue by first giving a short overview on the IPsec standard which basically consists of two parts: ● The actual encryption and authentication of tunneled IP packets takes place in the kernel using the Encapsulating Security Payload (ESP) standard defined by RFC 2406. ESP is IP protocol 50 and doesn't have ports. ● The initial negotiation and the ensuing periodic re-keying of IPsec tunnels is done by a userland daemon running the Internet Key Exchange (IKE) protocol defined by RFCs 2407, 2408, and 2409. IKE is transported over UDP datagrams and must use the well-known source and destination port 500. 1.1 The IPsec Kernel Part - ESP The ESP encapsulation of IP packets is shown in figure 2. Referring to the site-to-site VPN scenario depicted in figure 1, a TCP packet exchanged between a host 10.1.0.5 in the 10.1.0.0/16 network and a host 10.2.0.7 in the 10.2.0.0/16 network will carry these two addresses as source and destination in the original IP header, whereas the outer IP header of the IPsec packet will contain the addresses 11.22.33.44 and 55.66.77.88 of the VPN gateways that do the actual tunneling. ESP encrypts the whole original IP packet including the internal header and secures the encrypted content against unauthorized modification by computing and appending a cryptographic checksum. Before applying ESP Original TCP Encapsulating Security IP v4 Data IP Header Header Payload (ESP): RFC 2406 After applying ESP Outer ESP Original TCP ESP ESP IP v4 Data IP Header Header IP Header Header Trailer Auth encrypted authenticated Figure 2: IPsec Encapsulating Security Payload (ESP) Depending on the Linux kernel version, strongSwan employs different mechanisms to implement the IPsec kernel part: ● Under a Linux 2.4 kernel, KLIPS from the FreeS/WAN project is used to implement the IPsec kernel functionality. KLIPS, distributed as part of strongSwan, can either be compiled statically into the kernel or loaded dynamically as a kernel module ipsec.o. For encryption, authentication and compression, built-in functions from the FreeS/WAN project and/or crypto modules provided by JuanJo Ciarlante are used. ● Under a Linux 2.6 kernel, the native KAME stack ported from the BSD project to Linux is used. Encryption, authentication and compression tasks use the standard modules offered by the kernel's crypto API. Reprint of LinuxTag2005 Paper 2 1.2 The IPsec Userland Part - IKE strongSwan's userland daemon pluto is responsible for setting up, re-keying and deleting IPsec tunnels using the standardized Internet Key Exchange (IKE) protocol. An IKE negotiation is divided into Phase 1 where the VPN peers do mutual authentication, followed by one or several Phase 2 exchanges where the encryption, authentication and compression parameters for the actual tunneling of IP packets between predefined subnets are set up. strongSwan implements IKE Main Mode for Phase 1 and IKE Quick Mode for Phase 2. The potentially vulnerable IKE Aggressive Mode Phase 1 variant is not supported by strongSwan out of security considerations. IKE Main Mode peer authentication can either be based on Pre-Shared Keys (PSK) or on RSA signatures as shown in figure 3. Initiator Responder IK E IS A K MP S A 1 Header Proposal IK E IS A K M P S A 2 Header Response IK E DH Key N 3 Header Exchange i IK E DH Key 4 N encrypted Header Exchange r IK E ID Cert Sig 5 Header i i i encrypted IK E 6 ID Cert Sig Header r r r Figure 3: Internet Key Exchange Protocol (IKE) IKE Main Mode consists of six messages exchanged between the VPN peers: 1. The initiator proposes a series of supported encryption and authentication transforms for securing the IKE negotiation. 2. The responder selects a set of transforms common to both parties. 3. The initiator sends a public Diffie-Hellman factor and a nonce. 4. The responder in turn also sends a public Diffie-Hellman factor and a nonce which is a random number. Using the Diffie-Hellman key exchange algorithm both end points can now compute a common shared secret that is used to encrypt all ensuing IKE messages. 5. The initiator sends its identity and a signature computed by encrypting a hash formed over all exchanged IKE messages with its RSA private key. Although an option in IKE, strongSwan always includes a trusted X.509 certificate that can be used by the peer to verify the signature. 6. Now it is the responder's turn to identify and authenticate itself. Each IKE Quick Mode will then add another three messages. Reprint of LinuxTag2005 Paper 3 2 From FreeS/WAN to strongSwan The FreeS/WAN project (www.freeswan.org) was founded in 1999 by John Gilmore with the ultimate goal of automatically encrypting a significant part of the Internet traffic using Opportunistic Encryption (OE) based on IPsec and IKE. The grand idea behind OE was to do host authentication using raw RSA public keys fetched via the ubiquitous Domain Name System (DNS). Because most existing VPN implementations did not and still do not support the use of raw RSA keys, the author decided to contribute a X.509 patch to the FreeS/WAN project in order to make it possible for Linux hosts to set up IPsec tunnels with any other VPN product using standardized X.509 certificates. The first X.509 patch was released in 2000 and all further versions delivered over the next four years were developed by the author as professor for security and communications at the Zürcher Hochschule Winterthur (ZHW) with major contributions from a whole group of diploma students. In 2002, due to the increasing demand for the X.509 patch, Ken Bantoft bundled it with several other FreeS/WAN add-ons like Mathieu Lafon's NAT traversal patch and JuanJo Ciarlante's alternative crypto algorithms and started his Super FreeS/WAN distribution that quickly became extremely popular. FreeS/WAN 1.3 X.509 Patch 0.1 2000 ZHW Ken Bantoft X.509 Patch 0.9.32 Super FreeS/WAN 1.99.8 2002 FreeS/WAN 1.99 X.509 Patch 0.9.42 Openswan 1.0.9 2003 Xelerance X.509 Patch 1.5.4 Openswan 2.3.1 2004 FreeS/WAN 2.04 X.509 Patch 1.6.3 strongSwan 2.4.2 2004 Linux 2.6 Kernel ITA-HS R FreeS/WAN 2.06 Figure 4: The FreeS/WAN Genealogy Towards the end of 2003 when it became evident that the FreeS/WAN project was going to be discontinued in spring 2004 with the final 2.06 release, Ken Bantoft, FreeS/WAN project leader Michael Richardson and Paul Wouters founded Xelerance Corporation with the goal of carrying on the IPsec development within their Openswan project (www.openswan.org). Whereas Openswan has been moving closer to the mainstream VPN path by adding IKE Aggressive Mode and Cisco's legacy XAUTH authentication, the author decided to fork a strongSwan distribution (www.strongswan.org) of his own in order to be able to quickly integrate and deploy new certificate-based features originating from the Zürcher Hochschule Winterthur. Reprint of LinuxTag2005 Paper 4 In March 2005 the author accepted an offer to join the Hochschule für Technik Rapperswil (HSR, www.hsr.ch) where as a professor for security and communications he is now heading the Institute for Internet Technologies and Applications (ITA). Being an important part of the ITA strategy, the maintenance and continuing evolution of the strongSwan distribution will be guaranteed in the years to come. 3 The „Road Warrior“ Remote Access Case One of strongSwan's powerful features inherited from FreeS/WAN is the support of road warrior connections as shown in figure 5.
Load more

Recommended publications
  • Flexgw Ipsec VPN Image User Guide
    FlexGW IPsec VPN Image User Guide Zhuyun Information Technology Co.,Ltd. www.cloudcare.cn Zhuyun Information Technology Co.,Ltd. Contents .......................................................................................................... .................................................................................................................. 1 Introduction 4 1.1 Software Compon.e..n..t.s................................................................................................................... 4 1.2 Login Description ................................................................................................................... 4 1.3 Function Description ....................................................................................................5 1.4 Typical Scenarios Des..c..r..i.p..t..i.o..n......................................................................................................5 1.5 Program Description .................................................................................6 1.6 Software Operation Command Summary ............................... 7 ............................................................................................................... 2 IPSec Site-to-Site VPN User Guide (VPC network scenario) 8 2.1 Start IPSec VPN.s..e..r..v..i.c..e.................................................................................................................8 2.2 Add new tunnel .................................................................................................................
    [Show full text]
  • Efficient, Dos-Resistant, Secure Key Exchange
    Efficient, DoS-Resistant, Secure Key Exchange for Internet Protocols∗ William Aiello Steven M. Bellovin Matt Blaze AT&T Labs Research AT&T Labs Research AT&T Labs Research [email protected] [email protected] [email protected] Ran Canetti John Ioannidis Angelos D. Keromytis IBM T.J. Watson Research Center AT&T Labs Research Columbia University [email protected] [email protected] [email protected] Omer Reingold AT&T Labs Research [email protected] Categories and Subject Descriptors While it might be possible to “patch” the IKE protocol to fix C.2.0 [Security and Protection]: Key Agreement Protocols some of these problems, it may be perferable to construct a new protocol that more narrorwly addresses the requirements “from the ground up.” We set out to engineer a new key exchange protocol General Terms specifically for Internet security applications. We call our new pro- Security, Reliability, Standardization tocol “JFK,” which stands for “Just Fast Keying.” Keywords 1.1 Design Goals We seek a protocol with the following characteristics: Cryptography, Denial of Service Attacks Security: No one other than the participants may have access to ABSTRACT the generated key. We describe JFK, a new key exchange protocol, primarily designed PFS: It must approach Perfect Forward Secrecy. for use in the IP Security Architecture. It is simple, efficient, and secure; we sketch a proof of the latter property. JFK also has a Privacy: It must preserve the privacy of the initiator and/or re- number of novel engineering parameters that permit a variety of sponder, insofar as possible.
    [Show full text]
  • Enabling TPM Based System Security Features
    Enabling TPM based system security features Andreas Fuchs <[email protected]> Who am I ? ● 13 year on/off TPMs ● Fraunhofer SIT: Trustworthy Platforms ● TCG-member: TPM Software Stack WG ● Maintainer – tpm2-tss: The libraries – tpm2-tss-engine: The openssl engine – tpm2-totp: Computer-to-user attestation (mjg’s tpm-totp reimplemented for 2.0) 2 The hardware stack ● Trusted Platform Module (TPM) 2.0 – Smartcard-like capabilities but soldered in – Remote Attestation capabilities – As separate chip (LPC, SPI, I²C) – In Southbridge / Firmware – Via TEEs/TrustZone, etc – Thanks to Windows-Logos in every PC ● CPU – OS, TSS 2.0, where the fun is... 3 The TPM Software Stack 2.0 ● Kernel exposes /dev/tpm0 with byte buffers ● tpm2-tss is like the mesa of TCG specs ● TCG specifications: – TPM spec for functionality – TSS spec for software API ● tpm2-tss implements the glue ● Then comes core module / application integration – Think GDK, but OpenSSL – Think godot, but pkcs11 – Think wayland, but cryptsetup 4 The TSS APIs System API (sys) Enhanced SYS (esys) Feature API (FAPI) • 1:1 to TPM2 cmds • Automate crypto for • Spec in draft form HMAC / encrypted • TBimplemented • Cmd / Rsp sessions • No custom typedefs U serialization • Dynamic TCTI • JSON interfaces s • No file I/O loading • Provides Policy e • No crypto • Memory allocations language r • No heap / malloc • No file I/O • Provides keystore S p TPM Command Transmission Interface (tss2-tcti) p a Abstract command / response mechanism, • No crypto, heap, file I/O a Decouple APIs
    [Show full text]
  • Master Thesis
    Master's Programme in Computer Network Engineering, 60 credits MASTER Connect street light control devices in a secure network THESIS Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Network security, 15 credits Halmstad 2015-02-16 “Connect street light control devices in a secure network” Master’s Thesis in Computer Network engineering 2014 Authors: Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Supervisor: Alexey Vinel Examiner: Tony Larsson Preface This thesis is submitted in partial fulfilment of the requirements for a Master’s Degree in Computer Network Engineering at the Department of Information Science - Computer and Electrical Engineering, at University of Halmstad, Sweden. The research - implementation described herein was conducted under the supervision of Professor Alexey Vinel and in cooperation with Greinon engineering. This was a challenging trip with both ups and downs but accompanied by an extend team of experts, always willing to coach, sponsor, help and motivate us. For this we would like to thank them. We would like to thank our parents and family for their financial and motivational support, although distance between us was more than 1500 kilometres. Last but not least we would like to thank our fellow researchers and friends on our department for useful discussions, comments, suggestions, thoughts and also creative and fun moments we spend together. i Abstract Wireless communications is a constantly progressing technology in network engineering society, creating an environment full of opportunities that are targeting in financial growth, quality of life and humans prosperity. Wireless security is the science that has as a goal to provide safe data communication between authorized users and prevent unauthorized users from gaining access, deny access, damage or counterfeit data in a wireless environment.
    [Show full text]
  • Network Access Control and Cloud Security
    Network Access Control and Cloud Security Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] Audio/Video recordings of this lecture are available at: http://www.cse.wustl.edu/~jain/cse571-17/ Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-1 Overview 1. Network Access Control (NAC) 2. RADIUS 3. Extensible Authentication Protocol (EAP) 4. EAP over LAN (EAPOL) 5. 802.1X 6. Cloud Security These slides are based partly on Lawrie Brown’s slides supplied with William Stallings’s book “Cryptography and Network Security: Principles and Practice,” 7th Ed, 2017. Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-2 Network Access Control (NAC) AAA: Authentication: Is the user legit? Supplicant Authenticator Authentication Server Authorization: What is he allowed to do? Accounting: Keep track of usage Components: Supplicant: User Authenticator: Network edge device Authentication Server: Remote Access Server (RAS) or Policy Server Backend policy and access control Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-3 Network Access Enforcement Methods IEEE 802.1X used in Ethernet, WiFi Firewall DHCP Management VPN VLANs Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse571-17/ ©2017 Raj Jain 16-4 RADIUS Remote Authentication Dial-In User Service Central point for Authorization, Accounting, and Auditing data ⇒ AAA server Network Access servers get authentication info from RADIUS servers Allows RADIUS Proxy Servers ⇒ ISP roaming alliances Uses UDP: In case of server failure, the request must be re-sent to backup ⇒ Application level retransmission required TCP takes too long to indicate failure Proxy RADIUS RADIUS Network Remote Access User Customer Access ISP Net Server Network Server Ref: http://en.wikipedia.org/wiki/RADIUS Washington University in St.
    [Show full text]
  • Lecture 12: Security Systems Using Public Keys 11.1 PGP 11.2 SSL/TLS 11.3 IPSEC Stallings: Ch 16,17
    T-79.4501 Cryptography and Data Security Lecture 12: Security systems using public keys 11.1 PGP 11.2 SSL/TLS 11.3 IPSEC Stallings: Ch 16,17 1 Pretty Good Privacy • Email encryption program • Bottom–up approach to the distribution of trust • Each user acts as his/her own CA and signs the public keys of other users • User can accept authenticity of a public key based on recommendation by a third trusted user • RSA public key encryption used for distribution of session keys *) • Digital signatures produced by RSA or DSA signature algorithms • Hash functions are MD5 and SHA-1 • Symmetric encryption performed using IDEA in CFB mode (self- synchronising stream cipher) • Public keys held in ”Key-ring” • Revocation of public keys is a problem *) A data encryption protocol, where the data is encrypted using symmetric encryption, and the symmetric encryption key is encrypted using public key encryption, is called as ”hybrid encryption” 2 1 Secure Sockets Layer /Transport Layer Security • SSL (by Netscape) adds security to the TCP level of the Internet Protocol stack • Reliable end-to-end service. • TLS developed by IETF is basically equivalent to SSL v 3.1 Structure: SSL SSL Change SSL Handshake Cipher Spec Alert HTTP Protocol Protocol Protocol SSL Record Protocol TCP IP • Hypertext Transfer Protocol (Web client/server interaction) can operate on top of SSL (https://...) 3 SSL Record Protocol Application data fragment compressed fragment MAC added encrypted SSL record header appended 4 2 SSL Record Protocol Crypto • The MAC is similar to HMAC (indeed, an early version of HMAC) with the difference that OPAD and IPAD fields are concatenated to the key data (not xored as in HMAC).
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Nanosec™ ] Mocana’S Comprehensive Ipsec and Ikev1/V2 Solution with Integrated Certificate Management Functionality
    Security of Things Connectivity [ NanoSec™ ] Mocana’s comprehensive IPsec and IKEv1/v2 solution with integrated certificate management functionality. Features & Benefits • Small footprint, high performance • Full NIST USGv6 compliant implementation of IETF IPsec version 3 • FIPS 140-2 Level 1 validated (optional) • Guaranteed “GPL-Free” code protects your • Complete IPSec & IKEv1/v2 solution with intellectual property certificate management • Zero-threaded, asynchronous architecture • Dramatically speeds integration & testing of IPsec and certificate management • Expert development support from Mocana engineers •NIST-Approved “Suite B” cryptography included IPsec/IKE is a standard designed by IETF to provide interoperable, high quality, cryptographically- based security for IP communication. It’s useful for providing authentication (to ensure peers are communicating with the intended trusted parties), data confidentiality (to ensure data cannot be read in transit) and message integrity (to ensure traffic has not been altered in transit). These security services are provided at the IP layer, offering protection to all the protocols carried over PI . IPsec provides a great deal of flexibility and granular control over the security services offered. The most popular application of IPsec is the VPN (Virtual Private Network) which creates a secure encrypted “tunnel” over the unsecured Internet. Once a VPN is established, the two ends can run virtually any data, voice and video application securely. IPsec is terrific for reducing the threat of packet sniffers or man-in-the-middle attacks. Unfortunately, most IPsec packages are designed for PC’s, not embedded devices. That means that they can be somewhat unwieldy in memory-constrained device environments...and the performance of typical commercial or open-source IPsec offerings can be pretty disappointing, as well.
    [Show full text]
  • Linux Ipsec Tutorial
    Linux IPsec Tutorial Sowmini Varadhan (Oracle) & Paul Wouters (Redhat) Netdev0x12, July 2018, Montreal, Canada Agenda • Background: brief introduction to IPsec and IKE terminology • IPsec datapath walk-through: trace the life of a UDP packet for the transmit and receive path as it passes through the Linux kernel’s network stack (Sowmini Varadhan) • IPsec control plane walk-through: everything you wanted to know about the IKE control plane (Paul Wouters) Netdev0x12, July 2018, Montreal, Canada First, a review of IPsec/IKE terminology/definitions Netdev0x12, July 2018, Montreal, Canada What is IPsec? • IP Security • Suite of protocols for encryption (adding a “ESP” header) and Authentication (adding a “AUTH” header) • Encryption parameters (e.g., key, algorithm) are determined from two databases: – Security Policy database (SPD) – Security Association database (SADB) Netdev0x12, July 2018, Montreal, Canada SPD and SADB • SPD: Security Policy Database – What must be done: e.g., “for packets in 13.0.0.0/24, perform IPsec ESP processing”, “discard packets in 192.168.0.0/16” – Multiple transforms may be specified, e.g., “for packets from 12.0.0.1→12.0.0.2, apply ESP, then apply compression” – May need to create/lookup a Security Association to perform the action defined the SPD entry • SADB: Security Association Database – How to apply the security transform(s): e.g., “for packets from 13.0.0.1 → 13.0.0.2, apply AES-GCM-256 with the key 0x1234.. and a 128 bit IV” – IKE (Internet Key Exchange) protocol for negotiating and establishing SADB parameters
    [Show full text]
  • Implementation of Ipv6 in Internet Key Exhange Version 2
    Implementation of IPv6 in Internet Key Exhange version 2 Marko Salkić, Stjepan Groš, Vlado Glavinić Department of Electronics, Microelectronics, Computer and Intelligent Systems Faculty of Electrical Engineering and Computing Address: Unska 3, 10000 Zagreb, Croatia Telephone: +385 1 6129-935 E-mail: [email protected] Summary ± IKEv2 is a protocol for key exchange in Internet concluded in section five, followed by a list of references security architecture. We have implemented first, stripped- in section six. down version of IKEv2 that supported only IPv4 addresses. The implementation had some provisions that have been introduced in order to make later implementation of IPv6 II. IKEV2 PROTOCOL easier. Currently, we are extending IKEv2 implementation with missing functionality in order to make it fully IP security (IPsec) is a suite of security protocols and functional. In this paper we describe implementation details open standards developed by the Internet Engineering of IPv6 introduction into IKEv2 protocol implementation. Task Force (IETF) for secure transmission over unprotected networks, such as Internet. IPsec is required I. INTRODUCTION for IPv6 and optional for IPv4, but has not yet been widely deployed. Using cryptographic security services, IPsec IPv4 address architecture [1] is currently dominating provides confidentiality, data integrity, authenticity and on the Internet. This version has been in use for over 20 availability. Setting the parameters of an IPsec security years and during this period of time many deficiencies association (SA) manually does not scale well [4], so were discovered and identified. This led to a new version, another protocol ± Internet Key Exchange (IKE) ± is used IPv6 architecture [2], that has been in active development to automate and enhance negotiation of parameters and for over a decade.
    [Show full text]
  • Subliminal Channels in High-Speed Signatures
    Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at institute of telecommunications The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Subliminal Channels in High-Speed Signatures Master’s Thesis for obtaining the academic degree Diplom-Ingenieur as part of the study Electrical Engineering and Information Technology carried out by Alexander Hartl student number: 01125115 Institute of Telecommunications at TU Wien Supervision: Univ. Prof. Dipl.-Ing. Dr.-Ing. Tanja Zseby Dipl.-Ing. Robert Annessi, B.Sc Acknowledgments I want to express my gratitude for everyone who assisted or encouraged me in various ways during my studies. In particular, I would like to thank Prof. Tanja Zseby and Dipl.-Ing. Robert Annessi for giving me the opportunity to write this thesis, for supporting me actively while I was working on it and for many valuable comments and suggestions. I owe special thanks to my family, especially my parents Edith and Rudolf, for their endless support during all these years. Thank you, Sabrina, for encouraging me and for so many cheerful hours in my life. Abstract One of the fundamental building blocks for achieving security in data networks is the use of digital signatures. A digital signature is a bit string which allows the receiver of a message to ensure that the message indeed originated from the apparent sender and has not been altered along the path.
    [Show full text]