This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
! An abstract service that seeks to ensure a specific security property
! A security service can be realised with the help of cryptographicalgorithms and protocols as well as with conventional means:
s One can keep an electronic document on a floppy disk confidential bystoring it on the disk in an encrypted format as well as locking awaythe disk in a safe
s Usually a combination of cryptographic and other means is mosteffective
! Cryptographic Algorithm:
! A mathematical transformation of input data (e.g. data, key) to output data
! Cryptographic algorithms are used in cryptographic protocols
! Cryptographic Protocol:
! A series of steps and message exchanges between multiple entities inorder to achieve a specific security objective
! An error detection code over a message enables the receiver to check if amessage was altered during transmission
s Examples: Parity, Bit-Interleaved Parity, Cyclic Redundancy Code (CRC)
! This leads to the wish of having a similar value called modification check value (MDC) that allows to check, if a message has been modified duringtransmission
s Attention: CRC is not suited for detection of malicious modifications!
! Realization of Modification Check Values:! Cryptographic Hash Functions:
s These are either combined with asymmetric cryptography to obtain asigned modification detection code (MDC) or already include a sharedsecret mixed with the message (e.g., MD5, SHA-1, RIPEMD-160)
! Message Authentication Codes:
s Common message authentication codes (MAC) are constructed from asymmetric block cipher (e.g. DES-CBC-MAC)
A cryptographic protocol is defined as a series of steps and messageexchanges between multiple entities in order to achieve a specificsecurity objective
Applications of cryptographic protocols:
! Key exchange
! Authentication
s Data origin authentication: the security service, that enables a receiverto verify by whom a message was created and that it has not beenmodified
s Entity authentication: the security service, that enables communicationpartners to verify the identity of their peer entities
Integrating Security into Networks: What to do where?
! Analogous to the methodology of security analysis, there are two dimensions guiding the integration of security services intocommunications architectures:
Dimension 1:
Which security serviceshould be realized inwhich node?
Endsystem
(Initiator)
Endsystem
(Responder)
Network
? ? ? ??
Layer 5Layer 5
Layer 4Layer 4
Layer 3Layer 3
Layer 2Layer 2
Layer 1Layer 1
Layer 5Layer 5
Layer 4Layer 4
Layer 3Layer 3
Layer 2Layer 2
Layer 1Layer 1
Layer 3Layer 3
Layer 2Layer 2
Layer 1Layer 1
Layer 3Layer 3
Layer 2Layer 2
Layer 1Layer 1
Application Layer
Transport Layer
Data Link Layer
Physical Layer
Network Layer
Data Link Layer
Physical Layer
Network Layer
?
?
?
?
?
Dimension 2:
Which security serviceshould be realized inwhich layer?
Relationships Between Layers & Requirements Levels
! The relations between protocol layers and the protocol element securityrequirements levels are not one-to-one:
! Security mechanisms for fulfilling both the end system and the subnetworklevel requirements can be either realized in the transport and / or thenetwork layer
! Link level requirements can be met by integrating security mechanisms orusing “special functions” of the either the link layer and / or the physical layer
General Considerations for Architectural Placement (1)
! Traffic mixing:
! As a result of multiplexing, there is greater tendencies at lower levels tohave data items from different source/destination-users and / orapplications mixed in one data stream
!
A security service realized at one layer / level will treat the traffic of thatlayer / level in an equal manner, resulting in inadequate control oversecurity mechanisms for users and applications
! If a security policy demands for a more differentiated treatment, it shouldbe better realized at a higher level
! Route knowledge:
! At lower levels, there tends to be more knowledge about the securitycharacteristics of different routes and links
! In environments, where such characteristics vary significantly, placingsecurity at lower levels can have effectiveness and efficiency benefits
! Appropriate security services can be selected on a subnetwork or linkbasis eliminating cost for security, where protection is unnecessary
! Even if security implemented on this level might be implemented in thesame protocol layer like for the end system level, these should not bemixed up:
s With security implemented on the subnetwork level, usually the sameprotection is realized for all end systems of that subnetwork
! It is very common, that a subnetwork close to an end system is consideredequally trusted, as there are on the same premises and administered bythe same authorities
! In most situations there are far less subnetwork gateways to be securedthan there are end systems
! Link level:
! If there are relatively few untrusted links, it might be sufficient and as welleasier and cheaper to protect the network on the link level
! Furthermore the link level allows to make use of specific protectiontechniques, like spread spectrum or frequency hopping techniques
! Traffic flow confidentiality usually demands for link level protection
! Integration of security services into communications architectures isguided by two main questions:
! Which security service into which node?
! Which security service into which layer?
! These design choices can also be guided by looking at a pragmaticmodel of networked computing which distinguishes four different levelson which security services may be realized:
! Application / end system / subnetwork / link level
! As there are various reasons for and against each option, there is nosingle solution to this design problem
! In this tutorial we, therefore, look at some examples of securityservices integration into network architectures in order to betterunderstand the implications of the design choices made:
! Link Layer Security Protocols / IPSec / Transport Layer Security Protocols
[Gar96] Simson Garfinkel and Gene Spafford. Practical Internet & Unix Security.O'Reilly, 1996.
[KPS95] C. Kaufman, R. Perlman und M. Speciner. Network Security - Private Communication in a Public World. Prentice Hall. 1995.
[Men97a] A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone. Handbook of Applied Cryptography. CRC Press Series on Discrete Mathematics and Its Applications,
Hardcover, 816 pages, CRC Press, 1997.[Sch96] B. Schneier. Applied Cryptography Second Edition: Protocols, Algorithms and
Source Code in C. John Wiley & Sons, 1996.
[Sta98a] W. Stallings. Cryptography and Network Security: Principles and Practice.
! According to the classical understanding of the OSI model, the linklayer provides an assured data transmission service between two peer entities that are directly inter-connected by a communications medium
! Its main tasks are:
! Error detection and correction
! Medium access control (MAC, not to be mixed up with messageauthentication code) for shared media, e.g. Ethernet, etc.
!
Not all of today’s networking technology fits nicely into that model:! Dial-up connections to an Internet service provider
! Virtual Private Network (VPN) solutions
! In this tutorial, we content ourselves with the following definition:
! The purpose of a link layer security protocol is to ensure specific securityproperties of link layer PDUs, that is the PDUs of the protocol layercarrying the PDUs of the network layer (e.g. IP)
! The Institute of Electrical and Electronics Engineers (IEEE) 802 LAN/MAN Standards Committee develops local area networkstandards and metropolitan area network standards
! The most widely used standards are:
! Ethernet family (802.3, generally referred to as CSMA/CD),! Token Ring (802.5),
! Wireless LAN (802.11)
! The IEEE committee is currently working on a standard that:
! aims to “restrict access to the services offered by a LAN to those users and devices that are permitted to make use of those services”
! may be used with different IEEE 802.x technologies
! defines port based network access control to provide a means of“authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics”
! PPP was originally designed to be run between “directly” connectedentities, that is entities which share a layer-2 connection
! Example: a PC and a dialup-router of an Internet service providerconnected over the telephone network using modems
! The basic idea of PPTP is to extend the protocol’s reach over theentire Internet by defining transport of PPP PDUs in IP packets
! Thus, the payload of PPTP PDUs are PPP packets (without layer-2specific fields like HDLC flags, bit insertion, control characters, CRC errorcheck values, etc.)
! PPP packets are encapsulated in GRE packets (generic routingencapsulation) that themselves are encapsulated in IP packets:
! A security association (SA) is a simplex “connection” that providessecurity services to the traffic carried by it
! Security services are provided to one SA by the use of either AH or ESP,but not both
! For bi-directional communication two security associations are needed
! An SA is uniquely identified by a triple consisting of a security parameter index (SPI), an IP destination address, and a security protocol identifier(AH / ESP)
! An SA can be set up between the following peers:
s Host↔ Host
s Host↔ Gateway (or vice versa)
s Gateway↔ Gateway
! There are two conceptual databases associated with SAs:
s The security policy database (SPD) specifies, what security servicesare to be provided to which IP packets and in what fashion
! The record layer first fragments user data into records of a maximumlength of 214 octets, more than one message of the same content type canbe assembled into one record
! After fragmentation the record data is compressed, the default algorithm
for this is null (~ no compression), and it may not increase the recordlength by more than 210 octets
! A message authentication code is appended to the record data:
s MAC = H(MAC_write_secret + pad_2 +H(MAC_write_secret + pad_1 + seqnum + length + data))
s Note, that seqnum is not transmitted, as it is known implicitly and theunderlying TCP offers an assured service
! The record data and the MAC are encrypted using the encryptionalgorithm defined in the current cipherspec (may imply prior padding)
! Receiving side:
! The record is decrypted, integrity-checked, decompressed, de-fragmentedand delivered to the application or SSL higher layer protocol
! SSH was originally designed to provide a secure replacement for theUnix r-tools (rlogin, rsh, rcp, and rdist), thus it represents anapplication or session-layer protocol
! However, as SSH also includes a generic transport layer security
protocol and offers tunneling capabilities, it is discussed here as atransport layer security protocol
! SSH Architecture:
! SSH follows a client-server approach
! Every SSH server has at least one host key
! SSH version 2 offers two different trust models:
s Every client has a local database that associates each host name withthe corresponding public host key
s The hostname to public key association is certified by a CA and everyclient knows the public key of the CA
! The protocol allows full negotiation of encryption, integrity, key exchange,compression, and public key algorithms and formats
! The SSH authentication protocol serves to verify the client’s identityand it is intended to be run over the SSH transport protocol
! The protocol per default supports the following authentication methods:
! Public key: the user generates and sends a signature with a per user public
key to the serverClient → Server: E(-K User , (session_id, 50, Name User , Service, “publickey”,
True, PublicKeyAlgorithmName, +K User ))
! Password: transmission of a per user password in the encrypted SSHsession (the password is presented in clear to the server but transmittedwith SSH transport protocol encryption)
! Host-based: analogous to public key but with with per host public key
! None: used to query the server for supported methods and if noauthentication is required (server directly responds with success message)
! If the client’s authentication message is successfully checked, the
server responds with a ssh_msg_userauth_success message
! Both SSL and SSH are suited to secure Internet communications in(above) the transport layer:
! Both security protocols operate upon and require a reliable transportservice, e.g. TCP
! Up to now, no major security protocol has been proposed to protectdatagram-oriented transport protocols like UDP
! Even though SSH operates in / above the transport layer the serverauthentication is host-based and not application-based
! Transport layer security protocols offer true end-to-end protection for userdata exchanged between application processes
! Furthermore, they may interwork with packet filtering of today’s firewalls(see below for more details on this)
! But, protocol header fields of lower layer protocols can not be protectedthis way, so they offer no countermeasures to threats to the networkinfrastructure itself
Firewall Terminology & Building Blocks for Firewalls (2)
! Proxy:
! A program that deals with external servers on behalf of internal clients
! Proxies relay approved client requests to real servers and also relay theservers answers back to the clients
! If a proxy interprets and understands the commands of an applicationprotocol it is called an application level proxy, if it just passes the PDUsbetween the client and the server it is called a circuit level proxy
! Network Address Translation (NAT):
! A procedure by which a router changes data in packets to modify thenetwork addresses
! This allows to conceal the internal network addresses (even though NATis not actually a security technique)
! Perimeter Network:
! A subnetwork added between an external and an internal network, in orderto provide an additional layer of security
! A synonym for perimeter network is de-militarized zone (DMZ)
[RFC2401] R. Atkinson, S. Kent. Security Architecture for the Internet Protocol.
RFC 2401, Internet Engineering Taskforce (IETF), 1998.
[RFC2402] R. Atkinson, S. Kent. IP Authentication Header (AH). RFC 2402, IETF, 1998.
[RFC2403] C. Madson, R. Glenn. The Use of HMAC-MD5-96 within ESP and AH.
RFC 2403, IETF, 1998.
[RFC2404] C. Madson, R. Glenn. The Use of HMAC-SHA-1-96 within ESP and AH.
RFC 2404, IETF, 1998.
[RFC2405] C. Madson, N. Doraswami. The ESP DES-CBC Cipher Algorithm With Explicit IV. RFC 2405, IETF, 1998.
[RFC2406] R. Atkinson, S. Kent. IP Encapsulating Security Payload (ESP).RFC 2406, IETF, 1998.
[RFC2407] D. Piper. The Internet IP Security Domain of Interpretation for ISAKMP.
RFC 2407, IETF, 1998.
[RFC2408] D. Maughan, M. Schertler, M. Schneider, J. Turner.Internet Security Association and Key Management Protocol (ISAKMP).
RFC 2408, IETF, 1998.
[RFC2409] D. Harkins, D. Carrel. The Internet Key Exchange (IKE).
RFC 2409, IETF, 1998.[RFC2857] A. Keromytis, N. Provos. The Use of HMAC-RIPEMD-160-96 within ESP and
AH. RFC 2857, IETF, 2000.
Additional References (3)
[FKK96a] A. O. Freier, P. Karlton, P. C. Kocher. The SSL Protocol Version 3.0. NetscapeCommunications Corporation, 1996.
[RFC2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. RFC 2246, 1999.
[YKS01a] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Protocol Architecture. Internet Draft (work in progress), draft-ietf-secsh-architecture-
09.txt, 2001.
[YKS01b] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Transport Layer Protocol. Internet Draft (work in progress), draft-ietf-secsh-transport-09.txt, 2001.
[YKS01c] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Authentication
Protocol. Internet Draft (work in progress), draft-ietf-secsh-userauth-11.txt, 2001.
[YKS01d] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Connection Protocol. Internet Draft (work in progress), draft-ietf-secsh-connect-11.txt, 2001.
[Zwi00a] E. Zwicky, S. Cooper, B. Chapman. Building Internet Firewalls. Second Edition,
O’Reilly, 2000.
[Sem96a] C. Semeria. Internet Firewalls and Security. 3Com Technical Paper, 1996.
[Wack95a] J. P. Wack, L.J. Carnahan. Keeping Your Site Comfortably Secure: An