Standards

1. Standards Kerberos V4

2. Goals of Kerberos • Kerberos is a network authentication protocol created by MIT which uses symmetric key cryptography to authenticate users to network services — eliminating the need to send passwords over the network. When users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted. • Advantages: • Most conventional network systems use password-based authentication schemes. Such schemes require a user to authenticate to a given network server by supplying their user name and password. Unfortunately, the transmission of authentication information for many services is unencrypted. For such a scheme to be secure, the network has to be inaccessible to outsiders, and all computers and users on the network must be trusted and trustworthy. • Even if this is the case, once a network is connected to the Internet, it can no longer be assumed that the network is secure. An attacker who gains access can use a simple packet analyzer, also known as a packet sniffer, to intercept usernames and passwords sent in this manner, compromising user accounts and the integrity of the entire security infrastructure. • The primary design goal of Kerberos is to eliminate the transmission of unencrypted passwords across the network. If used properly, Kerberos effectively eliminates the threat packet sniffers would otherwise pose on a network.

3. Disadvantages Although Kerberos removes a common and severe security threat, it may be difficult to implement for a variety of reasons: • Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious, as there is no automated mechanism to perform this task. For more information, refer to question number 2.23 in the Kerberos FAQ online at the following URL: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. • For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client side communicate. Again, this may require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic. • Kerberos assumes that you are a trusted user using an untrusted host on an untrusted network. Its primary goal is to prevent plain text passwords from being sent across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication — called the key distribution center (KDC) — the entire Kerberos authentication system is at risk of being compromised. • Kerberos is an all or nothing solution. If you decide to use Kerberos on your network, you must remember that any passwords transferred to a service which does not use Kerberos for authentication are at risk of being captured by packet sniffers. Thus, your network gains no benefit from the use of Kerberos. To secure a network with Kerberos, one must either use kerberized versions of all client/server applications which send unencrypted passwords or not use any such client/server applications at all.

4. Terminology • ciphertext • Encrypted data. • client • An entity on the network (a user, a host, or an application) that can get a ticket from Kerberos. • credential cache or ticket file • A file which contains the keys for encrypting communications between a user and various network services. Kerberos 5 supports a framework for using other cache types, such as shared memory, but files are more thoroughly supported. • crypt hash • A one way hash used to authenticate users. While more secure than plain text, it is fairly easy to decrypt for an experienced cracker. • GSS-API • The Generic Security Service Application Program Interface [RFC-2743] is a set of functions which provide security services which clients can use to authenticate to servers and which servers can use to authenticate to clients without specific knowledge of the underlying mechanism. If a network service (such as IMAP) uses GSS-API, it can authenticate using Kerberos. • key • Data used when encrypting or decrypting other data. Encrypted data cannot be decrypted without the proper key or extremely good guessing. • Key Distribution Center (KDC) • A service that issues Kerberos tickets, usually run on the same host as the Ticket Granting Server • key table or keytab • A file that includes an unencrypted list of principals and their keys. Servers retrieve the keys they need from keytab files instead of using kinit. The default keytab file is /etc/krb5.keytab. The KDC administration server, /usr/kerberos/sbin/kadmind, is the only service that uses any other file (it uses /var/kerberos/krb5kdc/kadm5.keytab).

5. Terminology (cont.) • kinit • The kinit command allows a principal who has already logged in to obtain and cache the initial Ticket Granting Ticket (TGT). For more on using the kinit command, see its man page. • principal • The principal is the unique name of a user or service that can authenticates using Kerberos. A principal's name is in the form root[/instance]@REALM. For a typical user, the root is the same as their login ID. The instance is optional. If the principal has an instance, it is separated from the root with a forward slash ("/"). An empty string ("") is considered a valid instance (which differs from the default NULL instance), but using it can be confusing. All principals in a realm have their own key, which for users is derived from a password or is randomly set for services. • realm • A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients. • service • A program accessed over the network. • ticket • A temporary set of electronic credentials that verify the identity of a client for a particular service. • Ticket Granting Service (TGS) • A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC • Ticket Granting Ticket (TGT) • A special ticket that allows the client to obtain additional tickets without applying for them from the KDC. • unencrypted password • A plain text, human-readable password.

6. What is Kerberos? • Kerberos is an authentication service developed at MIT. Its purpose is to allow users and services to authenticate themselves to each other. • There are many ways to establish one's identity to a service. The most familiar is the user password. One "logs in" to a server by typing in a user name and password, which ideally only the user (and the server) know. The server is thus convinced that the person attempting to access it really is that user. • The password must transit that network in the clear--that is, unencrypted. That means that anyone listening in on the network can intercept the password, and use it to impersonate the legitimate user. • The key innovation underlying Kerberos is the notion that the password can be viewed as a special case of a shared secret--something that the user and the service hold in common, and which (again ideally) only they know. Establishing identity shouldn't require the user to actually reveal that secret • In Kerberos, that secret is used as an encryption key. In the simplest case, the user takes something freshly created, like a timestamp (it need not be secret), and encrypts it with the shared secret key. This is then sent on to the service, which decrypts it with the shared key, and recovers the timestamp. If the user used the wrong key, the timestamp won't decrypt properly, and the service can reject the user's authentication attempt. Ref: http://www.isi.edu/~brian/security/kerberos.html

7. Basics of Kerberos • Kerberos's fundamental approach is to create a service whose sole purpose is to authenticate. This is that it frees the services from having to maintain their own user account records. • The key to this approach is that both user and service implicitly trust the Kerberos authentication server (AS); the AS thus serves as an introducer for them. • In order for this to work, both the user and the service must have a shared secret key registered with the AS; such keys are typically called long-term keys, since they last for weeks or months. • Steps in authenticating a user to an end service. • (1) User sends a request to the AS, asking it to authenticate him to the service. • (2) AS generates a new, random secret key that will be shared only by the user and the service. It sends the user a two-part message. One part contains the random key along with the service's name, encrypted with the user's long-term key (credentials); the other part contains that same random key along with the user's name, encrypted with the service's long-term key (ticket). • (3) User generates a fresh message, such as a timestamp, and encrypts it with the session key. This message is called the authenticator. He sends the authenticator, along with the ticket, to the service. The service decrypts the ticket with its long-term key, recovers the session key, which is in turn used to decrypt the authenticator. The service trusts the AS, so it knows that only the legitimate user could have created such an authenticator.

8. The Ticket Granting Server • One of the inconveniences of It can be inconvenient if multiple services are used. • Kerberos resolves this problem by introducing a new service, called the ticket granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. (They are often referred to collectively as the KDC--the Key Distribution Center, from Needham and Schroeder [1].) The purpose of the TGS is to add an extra layer of indirection so that the user only needs to enter in a password once; the ticket and session key obtained from that password is used for all further tickets. • So, before accessing any regular service, the user requests a ticket from the AS to talk to the TGS. This ticket is called the ticket granting ticket, or TGT; it is also sometimes called the initial ticket. The session key for the TGT is encrypted using the user's long-term key, so the password is needed to decrypt it from the AS's response to the user. • After receiving the TGT, any time that the user wishes to contact a service, he requests a ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with the user's secret key, but with the session key that came with the TGT, so the user's password is not needed to obtain the new session key (the one that will be used with the end service). • The advantage this provides is that while passwords usually remain valid for months at a time, the TGT is good only for a fairly short period, typically eight or ten hours. Afterwards, the TGT is not usable by anyone, including the user or any attacker. This TGT, as well as any tickets that you obtain using it, are stored in the credentials cache. [1] R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21 (12), pp. 993-99. Last modified 30 March 2006.

9. Cross-Realm Authentication • As the network grows, the number of requests grows with it, and the AS/TGS becomes a bottleneck in the authentication process. For this reason, it often makes sense to divide the world into distinct realms. These divisions are often made on organizational boundaries, although they need not be. Each realm has its own AS and TGS. • To allow for cross-realm authentication--that is, to allow users in one realm to access services in another--it is necessary first for the user's realm to register a remote TGS (RTGS) in the service's realm. Such an association typically (but not always) goes both ways, so that each realm has an RTGS in the other realm. This now adds a new layer of indirection to the authentication procedure: First the user contacts the AS to access the TGS. Then the TGS is contacted to access the RTGS. Finally, the RTGS is contacted to access the end service. • Actually, it can be worse than that. In some cases, where there are many realms, it is inefficient to register each realm in every other realm. Instead, there is a network of realms, so that in order to contact a service in another realm, it is sometimes necessary to contact the RTGS in one or more intermediate realms. These realms are called the transited realms, and their names are recorded in the ticket. This is so the end service knows all of the intermediate realms that were transited, and can decide whether or not to accept the authentication. (It might not, for instance, if it believes one of the intermediate realms is not trustworthy.) • This feature is new to Kerberos in Version 5. In Version 4, only peer-to-peer cross-realm authentication was permitted. In principle, the Version 5 approach allows for better scaling if an efficient hierarchy of realms is set up; in practice, realms exhibit significant locality, and they mostly use peer-to-peer cross-realm authentication anyway. However, the advent of public-key cryptography for the initial authentication step (for which the certificate chain is recorded in the ticket as transited "realms") may again justify the inclusion of this mechanism.

10. Obtaining a Session key and Ticket Granting Ticket (TGT) Invents key SA Finds Alice’s master KA TGT=KKDC{“Alice”,SA} AS_REQ Alice, Password Alice Workstation KDC AS_REP KA: Alice’s master key SA: Session key for Alice TGT: Session key, user’s name, expiration time; encrypted with KDC’s master key AS: Authentication server TGS: Ticket Granting Server KA{SA,TGT} KDC AS TGS

11. [AP_REQ] Alice’s Workstation Bob Alice Asks to Talk to a Remote Node Alice wants to talk to Bob TGT=KKDC{“Alice”, SA} Authenticator=SA{timestamp} Invents key KAB Decrypts TGT to get SA Decrypts authenticator Verifies timestamp Finds Bob’s master key KB Ticket to Bob=KB{“Alice”,KAB} rlogin Bob [TGS_REQ] Alice Workstation TGS [TGS_REP] SA{“Bob”, KAB, ticket to Bob} Ticket to Bob = KB{“Alice”, KAB} Authenticator=KAB{timestamp} Decrypts ticket to get KAB Decrypts authenticator Verifies timestamp [AP_REP] KAB{timestamp+1}

12. Interrealm Authentication Realm B Realm A Bob Alice KDC B KDC A TGS_REQ Alice KDC A credentials TGS_REQ KDC B credentials Bob AP_REQ

13. Formats - Example • Tickets: KDC issues a ticket to Alice for Bob Alice’s name Alice’s instance Alice’s realm Alice’s network layer address Session key for Alice < --- > Bob Ticket lifetime, units of 5 minutes KDC’s timestamp when ticket made Bob’s name Bob’s instance Pad of 0’s to make ticket length multiples of eight octets

14. Kerberos V5 • Delegation of Rights: Ability to give someone else access to things you are authorized to access. • Usually limited in time or limited in scope • Kerberos V5 allows delegation by Alice asking TGT with a network layer address (or multiple addresses) different from hers. • First, Alice gets a normal session key and a TGT with her network layer. • When later Alice decides to delegate to Bob, she requests a new TGT from the KDC---with a new network layer address

15. Hierarchy of realms A C B G D E H I F J

16. Kerberos Architecture • Kerberos architecture consists of three key components: • client software • authentication server software • application server software

17. Standards SSL/TLS

18. Goals of SSL • Authenticating the client and server to each other: the SSL protocol supports the use of standard key cryptographic techniques (public key encryption) to authenticate the communicating parties to each other. Though the most frequent application consists in authenticating the service client on the basis of a certificate, SSL may also use the same methods to authenticate the client. • Ensuring data integrity: during a session, data cannot be either intentionally or unintentionally tampered with. • Securing data privacy: data in transport between the client and the server must be protected from interception and be readable only by the intended recipient. This prerequisite is necessary for both the data associated with the protocol itself (securing traffic during negotiations) and the application data that is sent during the session itself. SSL is in fact not a single protocol but rather a set of protocols that can additionally be further divided in two layers: • the protocol to ensure data security and integrity: this layer is composed of the SSL Record Protocol, • the protocols that are designed to establish an SSL connection: three protocols  are used in this layer: the SSL Handshake Protocol, the SSL ChangeCipher SpecPprotocol and the SSL Alert Protocol. • TLS (Transport level security protocol) is a revised version of SSL v3 introduced by IETF.

19. SSL Protocol Stack

20. SSL Protocol: Summary • The SSL Record protocol: It is used to transfer any data within a session - both messages and other SSL protocols (for example the handshake protocol), as well as for any application data. • The Alert Protocol: It is used by parties to convey session messages associated with data exchange and functioning of the protocol. Each message in the alert protocol consists of two bytes. The first byte always takes a value, “warning” (1) or “fatal” (2) , that determines the severity of the message sent. Sending a message having  a „fatal” status by either party will result in an immediate termination of the SSL session. The next byte of the message contains one of the defined error codes, which may occur during an SSL communication session. • The ChangeCipher Spec protocol: This protocol is the simplest SSL protocol. It consists of a single message that carries the value of 1. The sole purpose of this message is to cause the pending session state to be established as a fixed state, which results, for example, in defining the used set of protocols. This type of message must be sent by the client to the server and vice versa. After exchange of messages, the session state is considered agreed. This message and any other SSL messages are transferred using the SSL record protocol. • The handshake protocol: It constitutes the most complex part of the SSL protocol. It is used to initiate a session between the server and the client. Within the message of this protocol, various components such as algorithms and keys used for data encryption are negotiated. Due to  this protocol, it is possible to authenticate the parties to each other and negotiate appropriate parameters of the session between them.

21. Creating a packet under SSL http://www.windowsecurity.com/articles/Secure_Socket_Layer.html

22. Handshake in SSL

23. Basic SSL Protocol • Msg 1: Alice says she would like to talk and provides a list of cryptographic algorithms she supports, along with a randon number RAlice (later used to form a session key) • Msg 2: Bob sends Alice his certificate, a random number RBob (also used to form the session key), and one of the ciphers listed in Msg1 that Bob supports. • Msg 3: Alice chooses a random number S, computes K=f(S, RAlice,Rbob), and sends S encrypted with Bob’s public key • Bob also computes K=f(S, RAlice,Rbob) • Both Alice and Bob use a key derived from K; different keys are used in each direction; in each direction there are three keys for: encryption, integrity, and IV. • Msg 4: Bob proves that it knows the session key

24. Encrypted Records • Integrity: HMAC: based on MD5 or SHA-1 • Encryption: Any encryption algorithm using block ciphers in CBC mode except RC4. HMAC Computed on this Integrity key Seq# Record HDR Record Data Record HDR Record Data HMAC Pad Encrpyt Encryption key Record HDR Encrypted Integrity-protected record

25. Standards Public Key Infrastructure (PKI)

26. Terminology • Issuer: Who issues a certificate (Certificate authority or CA) • Subject---to whom a certificate is issued • Verifier ---one who verifies if a certificate is valid • Reluing party or service provider • Trust anchor---CA trusted by a relying party

27. PKI Trust models • Monopoly model (single CA for the entire world; very unrealistic) • Monopoly + Registration authorities (RAs) • Delegated CAs: A tree of CAs where a parent CA issues certificates to child CAs • Oligarchy: Used in browsers: Many trusted CAs • Anarchy model: Used by PGP: Any one can sign a certificate • Name constraints: Trust a CA for certain name domains • Bottom-up with name constraints: Parent and child certify ecah other; cross-certificates are also possible in the hierarchy of forests

28. Revocation • If a key has been compromised or if someone gets fired from an organization, it is important to revoke their certificate. • Similar to what happens when a credit card is stolen or lost

29. Revocation Mechanisms • CRLS: certificate Revocation Lists • Delta CRLs: lists changes from last complete CRL • First valid certificate • On-line revocation server (OLRS or OCRL) • Good lists vs. Bad lists

30. X.509 and PKIX • PKIX I a profile of X.509---it specifies which options should be supported.

31. X.509 - Certificate format Version (v1=0, v2=1, v3=2) Serial number Signature Algorithm ID Issuer Name Validity period(Start and expiry date/time) Subject Name Subject public key info(Algorithm ID and public key value) Issuer Unique ID (optional) Subject Unique ID (optional) Extensions (optional)Type - Critical/Non critical - Field value SignatureAlgorithm ID and signature value

32. PKI Tutorials • http://www.ncvhs.hhs.gov/050113p3.pdf • http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf • http://www.cypherpunks.to/~peter/part2.pdf

33. Standards Pretty Good Privacy (PGP)

34. How PGP works • PGP uses both public-key cryptography and symmetric key cryptography, and includes a system which binds the public keys to user identities. • The first version of this system is generally known as a web of trust as opposed to developed later X.509 system with top-down approach based on certificate authority. Later versions of PGP have included something more akin to a public key infrastructure (PKI) that includes certificate authority. • PGP uses asymmetric key encryption algorithms. In these, the recipient must have previously generated a linked key pair, a public key, and a private key. The sender uses the recipient's public key to encrypt a shared key (aka a secret key or conventional key) for a symmetric cipher algorithm. That key is used, finally, to encrypt the plaintext of a message. Many PGP users' public keys are available to all from the many PGP key servers around the world which act as mirror sites for each other. • The recipient of a PGP-protected message decrypts it using the session key for a symmetric algorithm. That session key was, of course, included in the message in encrypted form and was itself decrypted using the recipient's private key. Use of two ciphers in this way is sensible because of the very considerable difference in operating speed between asymmetric key and symmetric key ciphers (the differences are often 1000+ times). • A similar strategy is (by default) used to detect whether a message has been altered since it was completed, or (also by default) whether it was actually sent by the person/entity claimed to be the sender. • To do both at once, the sender uses PGP to 'sign' the message with either the RSA or DSA signature algorithms. To do so, PGP computes a hash (also called a message digest) from the plaintext, and then creates the digital signature from that hash using the sender's private key. The message recipient computes a message digest over the recovered plaintext, and then uses the sender's public key and the signed message digest value with the signature algorithm. If the signature matches the received plaintext's message digest, it must be presumed (to a very high degree of confidence) that the message received has not been tampered with, either deliberately or accidentally, since it was properly signed. • http://en.wikipedia.org/wiki/OpenPGP

35. How PGP works (Cont.) • It is critical that the public key one uses to send messages to some person or entity actually does 'belong' to the intended recipient. • Users must also verify by some means that the public key in a certificate actually does belong to the person/entity claiming it. From its first release, PGP has used a web of trust. A given public key (or more specifically, information binding a person to a key) may be digitally signed by a third party to attest the association between the person and the key. There are several levels of confidence that can be expressed in this signature. • In the (more recent) OpenPGP specification, trust signatures can be used to support creation of certificate authorities. A trust signature indicates both that the key belongs to its claimed owner and that the owner of the key is trustworthy to sign other keys at one level below their own. • A level 0 signature is comparable to a web of trust signature, since only the validity of the key is certified. • A level 1 signature is similar to the trust one has in a certificate authority because a key signed to level 1 is able to issue an unlimited number of level 0 signatures. • A level 2 signature is highly analogous to the trust assumption users must rely on whenever they use the default certificate authority list in Internet Explorer; it allows the owner of the key to make other keys certificate authorities. • PGP has also included a way to 'revoke' identity certificates which may have become invalid. More recent PGP versions have also supported certificate expiration dates. • The problem of correctly identifying a public key as belonging to some other user is not unique to PGP. All public key and private key cryptosystems have the same problem.

36. Downloading PGP etc. • PGP 6.5.8 – Tutorial http://www.pitt.edu/~poole/PGP.htm#waiting • E-mail privacy and PGP – Tutorial http://www.emailprivacy.info/privacy_pgp

37. Secure Shell (SSH)

38. Introduction • Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp. • Ssh protects against: • IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside. • IP source routing, where a host can pretend that an IP packet comes from another, trusted host. • DNS spoofing, where an attacker forges name server records • Interception of cleartext passwords and other data by intermediate hosts. • Manipulation of data by people in control of intermediate hosts • SSH does not protect against anything that compromises your host's security in some other way. Once an attacker has gained root access to a machine, he can then subvert ssh, too.

39. How SSH works? • Summary: All communications are encrypted using IDEA or one of several other ciphers (three-key triple-DES, DES, RC4-128, TSS, Blowfish). Encryption keys are exchanged using RSA, and data used in the key exchange is destroyed every hour (keys are not saved anywhere). Every host has an RSA key which is used to authenticate the host when RSA host authentication is used. Encryption is used to protect against IP-spoofing; public key authentication is used to protect against DNS and routing spoofing. RSA keys are also used to authenticate hosts. • http://www.rz.uni-karlsruhe.de/~ig25/ssh-faq/

40. Details cash:/home/mukka/.ssh2>ssh-keygen Generating 2048-bit dsa key pair 2 oOo.oOo.oOo. Key generated. 2048-bit dsa, mukka@cash.cs.odu.edu, Wed Sep 27 2006 10:14:00 -0500 Passphrase : Again : Private key saved to /home/mukka/.ssh2/id_dsa_2048_a Public key saved to /home/mukka/.ssh2/id_dsa_2048_a.pub cash:/home/mukka>ssh2 dilbert mukka's password: Authentication successful. Last login: Wed Sep 27 2006 10:09:40 -0500 from dhcp-87.cs.odu. Sun Microsystems Inc. SunOS 5.9 Generic May 2002 You have new mail. Sun Microsystems Inc. SunOS 5.9 Generic May 2002 You have new mail. cash:/home/mukka>

41. Procedure • Ssh2 connects and logs in on the specified host. The user must prove her identity to the remote machine using some authentication method. • Public-key authentication is based on the use of digital signatures. Each user creates a public / private key pair for authentication purposes. The server knows the user’s public key, and only the user has the private key. • When the user tries to authenticate herself, the server checks for filenames of matching public keys and sends a challenge to the user end. The user is authenticated by signing the challenge using the private key. • If other authentication methods fail, ssh2 will prompt for a password. Since all communication is encrypted, the pass-word will not be available for eavesdroppers. • When the user's identity has been accepted by the server, the server either executes the given command, or logs in on the machine and gives the user a normal shell. All communication with the remote command or shell will be automatically encrypted.

42. Difference between SSH and SSL • Main objective: SSL was designed to secure web sessions; SSH was designed to replace telnet and FTP; both can do more. • SSL is a drop-in with a number of uses. It front-ends HTTP to give HTTPS. It can also do this for POP3, SMTP, IMAP, and just about any other well-behaved TCP application. It is easy for most programmers who are creating network applications from scratch to just grab an SSL implementation and bundle it with their app to provide encryption when communicating across the network via TCP. SSH is designed to do a lot of different things, most of which revolve around setting up a secure tunnel between hosts. Some implementations of SSH rely on SSL libraries - this is because SSH and SSL use many of the same encryption algorithms (i.e. TripleDES).

43. Difference between SSH and SSL (Cont.) • SSL by itself gives you nothing - just a handshake and encryption. You need an application to drive SSL to get real work done. SSH by itself does a whole lot of useful stuff that allows users to perform real work. Two aspects of SSH are the console login (telnet replacement) and secure file transfers (ftp replacement), but you also get an ability to tunnel (secure) additional applications, enabling a user to run HTTP, FTP, POP3, and just about anything else THROUGH an SSH tunnel. • Without interesting traffic from an application, SSL does nothing. Without interesting traffic from an application, SSH brings up an encrypted tunnel between two hosts which allows you to get real work done through an interactive login shell, file transfers, etc. • HTTPS does not extend SSL, it uses SSL to do HTTP securely. SSH does much more than SSL, and you can tunnel HTTPS through it! Just because both SSL and SSH can do TripleDES doesn't mean one is based on the other. • http://www.rpatrick.com/tech/ssh-ssl/

44. More differences • SSL server authentication is optional: the protocol supports fully anonymous operation, in which neither side is authenticated. Such connections are inherently vulnerable to man-in-the-middle attacks. • In SSH, server authentication is mandatory, which protects against such attacks. Of course, it is always possible for a client to skip the step of verifying that the public key supplied by the server actually belongs to the entity the client intended to contact (e.g. using the /etc/ssh_known_hosts file). However, SSH at least demands going through the motions. • In SSL both client and server authentication are done with X.509 public-key certificates. This makes SSL a bit more cumbersome to use than SSH in practice, since it requires a functioning public-key infrastructure (PKI) to be in place, and certificates are more complicated things to generate and manage than SSH keys. However, a PKI system provides scalable key management for your trouble, which SSH currently lacks. • SSL does not provide the range of client authentication options that SSH does; public-key is the only option. • SSL does not have the extra features provided by the other SSH component: the SSH Connection Protocol (SSH-CONN). SSH-CONN uses the underlying SSH-TRANS connection to provide muliple logical data channels to the application, as well as support for remote program execution, terminal management, tunnelled TCP connections, flow control, etc. • http://www.snailbook.com/faq/ssl.auto.html

45. Standards IPSec

46. An Illustrated Guide to IPsec • Practical IPSEC - AUG2002 Tutorial

47. Introduction • IPsec---standard for real-time communication security • Security association (SA)---cryptographically protected connection---unidirectional---each end keeps track of the cryptographic information (including a sequence number) associated with that SA in a database. • Each SA is associated with a security parameter index (similar to virtual circuit ID in networks). It is determined by the destination. • IPsec policy database: This indicates what actions (encryption/integrity check/etc.) should be taken for what type of packets/destinations etc.

48. Introduction (Cont.) • Two types of IPsec headers---AH and ESP • AH---Authentication Header (integrity protection only); • ESP---Encapsulating Security Payload (encryption and/or integrity) • Two modes of protection---Tunnel and transport • Transport mode---add IPsec information between IP header and the rest of the packet • Tunnel mode---keep the original IP packet as it is and add an additional IP header and IPsec information outside

49. Transport mode • It is the default mode for IPSec • It is used for end-to-end communications (for example, for communications between a client and a server). • Here, IPSec encrypts only the IP payload. • It provides the protection of an IP payload through an AH or ESP header. (Typical IP payloads are TCP segments (containing a TCP header and TCP segment data), a UDP message (containing a UDP header and UDP message data), and an ICMP message (containing an ICMP header and ICMP message data)). • http://technet2.microsoft.com/WindowsServer/en/library/c3a956bf-704b-4980-9655-762985e380f61033.mspx?mfr=true

50. Tunnel Mode • Common use---firewall to firewall, or end node to firewall • The firewall at source changes the source and destination addresses in the new IP header. The destination firewall forwards the original IP packet onwards. • Transport mode may be superfluous with tunnel mode