Revision History

August 18, 2011—Added references; completed (draft) protocol write-ups.
End-to-End (IP) Protocols
TLS
Description
TLS secures client-server network communications, preventing eavesdropping, relay attacks, and
tampering.
The protocol comprises two layers:


TLS Handshake Protocol—Prevents tampering by authenticating peers’ identities (using
asymmetric or public key cryptography, such as RSA or ECDSA), negotiating the shard secret, and
detecting any attempt by attackers to modify the negotiation communication.
TLS Record Protocol—Ensures that data is kept private (data is encrypted via symmetric ciphers
such as AES-CBC) and reliable (secure hash functions such as SHA-1 are used for keyed MAC
computations for message integrity checks).
TLS 1.2 is an IETF standards track protocol: RFC 5246.
Typical Applications
TLS is widely used in applications such as eCommerce, Web browsing, email, eFax, instant messaging
(IM), and voice over IP (VoIP) signalling. Typically, TLS encapsulates application-specific protocols such as
HTTP, FTP, SMTP, SIP, and XMPP.
Pros



TLS supports mutual authentication, which is important for machine-to-machine
communications.
Auto-negotiation makes it easy to provision applications using TLS.
Applications can reduce packet overhead by combining packets.
Cons


Although TLS is protocol independent from a network perspective, developers must integrate
TLS into their applications.
TLS must be used with reliable transport protocols, such as Transmission Control Protocol (TCP).
Security Protocols for UCA Project
Saved: February 8, 2016
1

As with any encrypted transmission, there is price to pay in additional packet overhead, but it’s
light for TLS.
Packet Overhead
TBD
History/Origin
Early efforts to add security to existing network applications included the Secure Network Programming
(SNP) application programming interface. SNP was superseded by Secure Sockets Layer (SSL), which was
not considered fully secure until version 3.0 was released in 1996.
TLS 1.0 was first defined in 1999 as an upgrade to SSL 3.0. The two protocols were very similar, but did
not interoperate. Subsequent updates created TLS 1.1 (added protection against cipher block chaining
(CBC) attacks, added support for IANA registration of parameters) and 1.2 (replaced MD5-SHA-1 with
SHA-256, enhanced and expanded support for additional hash and signature algorithms and encryption
ciphers).
References




http://en.wikipedia.org/wiki/Transport_Layer_Security
http://tools.ietf.org/html/rfc5246
http://stackoverflow.com/questions/1615882/how-much-network-overhead-does-tls-addcompared-to-a-non-encrypted-connection
http://netsekure.org/2010/03/tls-overhead/
DTLS
Description
The Datagram Transport Layer Security (DTLS) protocol is designed to prevent eavesdropping,
tampering, or message forgery by offering integrated key management, parameter negotiation, and
secure data transfer.
DTLS provides an important security mechanism for application layer protocols that use UDP transport,
such as Session Initiation Protocol (SIP) and voice and video traffic.
Typical Applications
Applications that can use DTLS are nearly limitless, and include devices such as:





Smart Grid equipment
OEM datacomm equipment
Networked SCADA equipment
Internet-ready consumer electronics
Smartphones and tablets (for VPN connectivity)
Security Protocols for UCA Project
Saved: February 8, 2016
2
Pros




DTLS is an accepted standard (RFC 4347), thereby affording easy interoperability.
DTLS can handle very large handshake messages by allowing each handshake message to be
fragmented over several UDP datagrams.
DTLS can be implemented in user space without changing the kernel.
DTLS works over a lossy packet network.
Cons


DTLS can experience heavy handover latency.
Lacks congestion control.
Packet Overhead
TBD
History/Origin
DTLS was developed to provide all the benefits of the Transport Layer Security (TLS) protocol, which
must use a reliable transport channel such as TCP, to datagrams—packets that are sent via an unreliable
transport mechanism, such as User Datagram Protocol (UDP), in which the packets may be lost or
reordered.
References











http://en.wikipedia.org/wiki/DTLS
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07
http://tools.ietf.org/html/rfc4347
http://en.wikipedia.org/wiki/User_Datagram_Protocol
http://www.vocal.com/network/dtls.html
http://mytelepresence.blogspot.com/2010/08/cts-system-dtls-call-analysis.html
http://blog.davidwolinsky.com/2009/11/my-impressions-of-dtls-and-openssl.html
http://www.hindawi.com/journals/wcn/2009/716480/
http://forums.msexchange.org/m_1800457023/mpage_1/key_/tm.htm#1800457023
http://crypto.stanford.edu/~nagendra/papers/dtls.pdf
http://crypto.stanford.edu/~nagendra/papers/dtls.pdf
IPsec
Description
IP Security (IPsec) is a suite of protocols that support the secure exchange of packets at the IP layer IPv4
or IPv6) in a point-to-point configuration-such as between two hosts (host-to-host), between a pair of
security gateways (network-to-network), between a security gateway and a host (network-to-host)-or
for multicasting architectures.
Security Protocols for UCA Project
Saved: February 8, 2016
3
IPsec comprises:

AH—Authentication Header protocol that adds a header (calculated based on the values in the
datagram) that provides authentication of either all or part of the contents of a datagram, as
well as protection against replay attacks.
(Note that AH does not go through Network Address Translation (NAT) configurations.)
If desired, ESP can be used for authentication instead of AH.

ESP—Encapsulating Security Payloads protocol that provides privacy (confidentiality) by
encrypting IP datagrams via an algorithm that combines the datagram data with a key to
transform it into an encrypted form. (The data is decrypted using the same algorithm at the
destination.)
ESP can also be used for authentication (instead of AH).
IPsec implementations can use ESP for confidentiality only, for authentication only, or for both
confidentiality and authentication.

IKE—Internet Key Exchange enables devices to exchange information, such as cryptographic
keys, that is required to establish secure communication. Without IKE, manual keys would be
necessary.
Typical Applications




Host-to-host communications
VPN tunnels between private IP addresses
Securing roaming devices (such as smartphones and wireless-connected laptops) via
Multihoming Protocol (MOBIKE).
Securing multicasting—communications from one node to many
Pros




IPsec works at the IP layer and is not affected by whether application traffic is transported via
TCP or UDP protocols, and therefore can be used to secure both real-time traffic and traditional
data applications.
IPsec is easily scalable.
Because IPsec works at the IP layer, it is impervious to performance hits due to user and
application activity in the lower level data carrying protocols and transport technology.
Legacy applications do not need modification to IPsec.
Cons

In a typical VPN implementation, vulnerabilities that exist at the IP layer in the remote network
could be passed to the corporate network across the IPsec tunnel. (This situation arises from the
Security Protocols for UCA Project
Saved: February 8, 2016
4




fact that when a computer is attached to an IPsec-based network, any of the local network’s
attached devices might also be able to gain access across the WAN to the corporate network.)
Corporate firewall policies may block IPsec tunneling for VPN applications.
IPsec implementation can defeat the purpose of a firewall because IPsec encrypts the
preconfigured rules upon which firewalls are based. However, the problem can be avoided by
using the Firewall along with the IPsec gateway.
Outside of the US, some internet service providers (ISPs) consider IPsec-encrypted traffic to be a
business-class transmission, and therefore charge higher rates or even block IPsec traffic for
non-business accounts. These additional charges would be a significant burden to the typical
teleworker who uses IPsec VPNs to access their employer’s or clients’ networks. (This is not an
issue in the US due to Internet neutrality.)
Transmitting many small packets can have a negative impact on network performance due to
encryption overhead that is independent of packet size.
Packet Overhead
header type
header size
auth ICV size
AH
ESP
ESP-AES
ESP
w/authentication
ESP-AES
w/authentication
ESP_NULL
IP (tunnel)
12
8
8
8
12
12
8
8
20
encryption
max
encryption
trailer
8
16
8
9
17
9
24
25
41
37
16
17
53
2
22
20
12
TOTAL
History/Origin
IPsec protocols were first published in 1995. In 1998, mutual authentication and the key exchange
protocol were defined. IKEv2 was added in 2005.
All IPsec-compliant implementations support both IPv4 and IPv6.
Although IPsec has been in use for a long time (for anything security-related), it is increasingly
incorporated into devices and systems that must be internet-enabled and still remain secure.
References



http://en.wikipedia.org/wiki/Ipsec
http://www.networksorcery.com/enp/protocol/ah.htm
http://tools.ietf.org/html/rfc4302
Security Protocols for UCA Project
Saved: February 8, 2016
5







http://tools.ietf.org/html/rfc2401
http://www.tcpipguide.com/free/t_IPSecAuthenticationHeaderAH.htm
http://www.tcpipguide.com/free/t_IPSecEncapsulatingSecurityPayloadESP.htm
http://en.wikipedia.org/wiki/Internet_Key_Exchange
http://www.tcpipguide.com/free/t_IPSecKeyExchangeIKE.htm
http://www.networkworld.com/newsletters/2004/1108wan2.html
http://nislab.bu.edu/sc546/sc441Spring2003/ip_sec/A&D.htm
SSHv2
(Note: SSHv1 is not secure and should never be used.)
Description
One of the more ubiquitous communications protocols, Secure Shell (SSH) enables a user and a remote
computer to authenticate each other via public key cryptography. In doing so, SSH enables secure
communication between two computers.
SSH has three primary components:



Transport Layer Protocol—Provides server authentication, confidentiality, integrity, and
optionally, compression. Typically TCP/IP is used, but other reliable data streams are permitted.
User Authentication Protocol—Authenticates a client to a server; runs over the transport layer
protocol.
Connection Protocol—Multiplexes the encrypted tunnel into logical channels; runs over the user
authentication protocol.
Typical Applications
SSH implementations differ markedly in the features that they offer, but generally enable secure logins
as well as command execution over unsecured networks and between untrusted hosts. Some
implementations can be used for port forwarding over secure channels, automated remote monitoring
and sever management, and Secure FTP file operations.
Pros



Supports file transfer.
Supports shell commands.
SSH protects against many types of attacks:
o IP spoofing
o IP source routing
o DNS spoofing
o Interception of cleartext passwords and other data by intermediate hosts
Cons

High packet overhead is incurred because every key stroke is encrypted.
Security Protocols for UCA Project
Saved: February 8, 2016
6


SSH does not protect against things that compromise a host’s security through some other
means, such as gaining root access to a machine. And when such access is gained, SSH can be
subverted, too.
Likewise, if someone gains access to a home directory (for example, if it’s exported via NFS),
security is non-existent.
Packet Overhead
SSH overhead, like many protocols, can be expressed as a worst case but not a single definitive number.
In the case of SSH, this imprecision is due to the padding that is added to each packet, which varies
depending on the chosen cipher’s block size.
The worst case scenario is an additional 356 bytes per packet, comprising the following:





4 bytes—SSH packet length
1 byte—random padding length
1 to 255 bytes—padding
20 bytes—MAC (may vary depending on the MAC algorithm)
66 bytes—IP encapsulation
History/Origin
The first version of SSH (SSH-1) was designed in 1995, and was intended to replace earlier protocols
whose authentication was weak or did not guarantee confidentially, such as rlogin, TELNET, and rsh.
Early SSH implementations were largely open and free, but proprietary software soon followed.
A revised version of the protocol, SSH-2, was adopted as a standard by the IETF in 2006. It has better
security than SSH-1 (such as Diffie-Hellman key exchange and strong integrity checking) and additional
features (such as capacity for multiple shell sessions in a single SSH connection).
References




http://en.wikipedia.org/wiki/Secure_Shell
http://www.employees.org/~satch/ssh/faq/ssh-faq.html
http://www.google.com/url?sa=t&source=web&cd=9&ved=0CGIQFjAI&url=https%3A%2F%2Fws
.edu.isoc.org%2Ftrac%2Fwirelessu%2Frawattachment%2Fwiki%2FPortMoresbyCurriculum%2FBandwidthReqs.pdf&ei=4P1KToztJWBsgLKwt2jCA&usg=AFQjCNFrkQRh1StSPDqPBfv8i7p8Ta1HuA
http://www.networksorcery.com/enp/protocol/ssh.htm
Security Protocols for UCA Project
Saved: February 8, 2016
7
Authentication
RADIUS
Description
Remote Authentication Dial-In User Service (RADIUS) is a multi user client-server security protocol used
in computer networks to provide Authentication, Authorization, and Accounting (AAA):



Remote user authentication—Authenticate users or device before granting them network
access
Authorization—Authorize authenticated users or devices to use/access the network’s services
Accounting—Account for (track) the services usage, typically to enable accurate billing, network
monitoring, or for statistical analysis
The RADIUS software runs in the application layer (over UDP), and can read several kinds of password
databases and use several kinds of authentication schemes. The protocol is described in RFCs 2138,
2865, and 2866.
RADIUS is a simple request-response protocol. A RADIUS client sends a RADIUS request, which includes
attributes such as username, password, access type, and so on. The RADIUS server then processes the
request, and replies with a RADIUS response: access denied, access granted with the indicated rights or
restrictions, or additional authentication required.
Typical Applications



RADIUS is frequently used to control network access (Internet or internal, wired or wireless) and
integrated email services. RADIUS-controlled networks can include many component types, such
as modems, DSL, access points, VPNs, and Web servers.
Remote access servers, network switches with port-based authentication, and network access
servers (NASs) have RADIUS client components that communicate with RADIUS servers.
(Original applicability, but rarely use today) RADIUS can be used to enabled roaming between
Internet Service Providers (ISPs), such as is required by companies that provide a single global
set of credentials that are used to access many public networks, or by cooperating organizations
that issue their own credentials to their own user base, and that allow authenticated access by
visitors from the cooperating organizations.
Pros


RADIUS-based systems can use a great variety of authentication schemes, including PAP, CHAP,
and EAP.
Passwords are secured by means of a shared secret used with MD5, eliminating the risk of
transmitting passwords in cleartext between NAS and RADIUS passwords.
Security Protocols for UCA Project
Saved: February 8, 2016
8

RADIUS employs a distributed security model, separating user authentication and authorization
functions from the communications process and creating one central repository for user
authentication data, which provides several important benefits:
o Greater security—It’s much easier to secure a single central database than data that is
housed on a variety of different devices.
o Scalability—By keeping all user information in a single location (the RADIUS server), it is
easy to add any number of clients (users or devices) to a network. As long as the client is
a RADIUS client, it can communicate with the one RADIUS server, regardless of the
client’s location.
o Open protocols—Because RADIUS is non-proprietary, it can be modified to operate with
any security system, and is therefore a viable option for securing any system.
Cons






When used in large-scale systems, RADIUS can experience degraded performance and lost data
because it lacks congestion control mechanisms. (The IETF AAA working group may address
RADIUS’ scaling and congestion control issues.)
The MD5 hash built into RADIUS is considered insecure, which can be mitigated by establishing a
secure tunnel between RADIUS servers to ensure that users’ credentials cannot be stolen while
proxied across the Internet.
Although RADIUS protects a user’s security credentials, other user-specific attributes are not
protected.
RADIUS uses UDP—an unreliable transport mechanism.
RADIUS attribute messages are limited to 255 bytes.
Concurrent user authentications from client to server is limited to 255.
Packet Overhead
N/A
History/Origin
Developed in 1991, RADIUS was originally used to control dial-in access to the National Science
Foundation Network (NSFnet). In 1997, RADIUS was published as a pair of RFCs (2058 and 2059). Since
then, commercial and open-source RADIUS servers have been developed with varying features.
Due to security concerns, the need for additional authentication schemes, and the desire for a secure
transport mechanism (such as SCTP or TCP) RADIUS is being replaced by Diameter.
While older RADIUS servers consulted a locally stored flat file database to verify a user’s information,
more recent implementations typically verify user credentials against external sources, such as SQL,
Kerberos, LDAP, or Active Directory servers.
References

http://en.wikipedia.org/wiki/RADIUS
Security Protocols for UCA Project
Saved: February 8, 2016
9



http://tools.ietf.org/html/rfc2865
http://m2m.com/thread/1296
http://www.kmj.com/radius.html
LDAP
Description
Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing directory services—
read/write access to an organized set of records, typically in a hierarchical structure—over a private
network or the Internet.
LDAP clients connect to an LDAP server and query the server for the desired information or request that
information be added. The server can answer the query, refer the query to another LDAP server, or add
new information to the directory. In general, clients can make requests anytime, regardless of whether
responses have yet been received for previous requests.
Typical Applications
LDAP directories are designed for frequent access and infrequent data updates, which makes them ideal
for storing a broad range of data for Human Resources, external customer contact information, IT
infrastructure services information (such as NIS maps and email aliases), and security artifacts (such as
public certificates and security keys). LDAP is often used to store certificate serial numbers.
Pros







LDAP is significantly simpler and easier to integrate than the X.500 standard on which it is based.
Many development frameworks support LDAP communications.
Users can have complex group membership settings (access control instances, or ACIs), and
permissions to any object/attribute can be customized. And the server controls the access, it’s
more secure than securing the data on the client side.
LDAP can support any kind of information, not just the usual telephone book sort of data
(names, phone numbers, and email addresses).
LDAP is both cross-platform and standards-based, so applications can be completely unaware of
the type of server that is hosting the LDAP directory.
LDAP can use TLS for confidentiality.
Read operations are very fast.
Cons




Because all data resides in a centralized repository, it is vital to have a good backup protocol in
place for that data.
To use LDAP, you need LDAP-enabled applications or to use LDAP gateways.
LDAP supports access control, but does not have as many security features as X.500 (a more fullfeatured directory services protocol).
Write operations are very slow.
Security Protocols for UCA Project
Saved: February 8, 2016
10
Packet Overhead
N/A
History/Origin
During the 1980s, X.500 was developed as a suite of protocols with extensive input from
telecommunication companies (who had many decades of experience producing and managing
telephone directories). Access to the X.500 services was most often via Directory Access Protocol (DAP),
but it was a very complex and heavyweight protocol that used the OSI stack. Therefore, LDAP was
developed to be a lightweight protocol that would use the TCP/IP stack.
LDAP version 1 was originally created in 1993. In LDAP Version 2 (LDAPv2), communications were
typically secured by using an SSL tunnel; however this usage has been deprecated with the release of
Version 3 (RFC 4510), which was first published in 1997 and added support for extensibility.
References






http://en.wikipedia.org/wiki/Ldap
https://www3.ietf.org/proceedings/58/I-D/draft-ietf-ldapbis-protocol-18.txt
http://www.centos.org/docs/2/rhl-rg-en-7.2/ch-ldap.html
http://stackoverflow.com/questions/2183818/pros-and-cons-of-using-ldap-for-external-users
http://www.ldapman.org/articles/intro_to_ldap.html
http://www.networksorcery.com/enp/protocol/ldap.htm
Kerberos
Description
Kerberos is a network authentication protocol that employs secret key cryptography to provide strong
authentication for client-server (or server-to-server) applications. It includes mechanisms to:



Authenticate user identity
Securely package the user’s name (in a data structure called a ticket)
Securely deliver user credentials (via the encrypted ticket)
It was created as a solution to network security problems such as password sniffers, applications that
(foolishly) rely on the client to restrict its activities to authorized operations, and firewall-protected
systems (which do nothing to protect against damage by insiders).
In the Kerberos model, a client and server mutually prove their identities across an insecure network,
and then encrypt all their communications to ensure privacy and data integrity.
Typical Applications
Typical applications for the Kerberos authentication protocol include:

Web browsers
Security Protocols for UCA Project
Saved: February 8, 2016
11







Telnet applications
POP email clients
Queries via LDAP
Remote server or workstation management
Print services
Client-server authentication
Certificate requests to Certificate Servers for users and devices
Pros





There are many free and commercial implementations available, making it easy to integrate into
your systems.
Compared to NT LAN Manager (NTLM—a suite of Microsoft security protocols that provide
authentication, integrity, and confidentiality to users in a Windows network), Kerberos offers
more security, is more flexible, and is more efficient.
Centralized access control means that you can easily revoke user access.
Kerberos supports Single Sign On (SSO) for all Kerberos-enabled services.
Users do not need shell accounts on the remotely managed machines.
Cons






In the last decade, there have been several to a handful of security advisories every year
(http://web.mit.edu/kerberos/advisories/).
Kerberos does not authorize access.
Kerberos does not address host security; that is, it assumes that it is running on trusted hosts
within an untrusted network. Therefore, if host security is comprised, so is Kerberos
authentication.
If an attacker gains a user’s Kerberos password, the attacker can impersonate that user because
the password (encryption) key is considered proof of identity.
Not all versions of Kerberos 5 support pre-authentication, which is one method of preventing an
offline dictionary attack (in which an attacker requests a Kerberos ticket for a user and tries
different passwords until one is found that successfully decrypts the ticket before it expires).
System clocks need to be synchronized so that client and server can accurately determine when
an authenticator has expired (is too old to be valid).
Packet Overhead
N/A
History/Origin
Kerberos was originally developed by MIT and publicly released as Version 4. The Kerberos 5 protocol is
now on a standards track with the IETF, and is intended to overcome the limitations and security
problems of version 4.
Security Protocols for UCA Project
Saved: February 8, 2016
12
In the United States, Kerberos is classified as an auxiliary military technology, and therefore banned for
export (in part because it uses DES with 56-bit keys). However, a Swedish implementation of Kerberos 4
is available outside the US.
References







http://en.wikipedia.org/wiki/Kerberos_(protocol)
http://web.mit.edu/kerberos/
http://kb.iu.edu/data/acjj.html
http://technet.microsoft.com/en-us/library/cc780469(WS.10).aspx
http://kb.iu.edu/data/acjj.html
http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#weakness
http://virt-manager.org/page/RemoteKerberos#Pros.2FCons__of_Kerberos
EAP
Description
Extensible Authentication Protocol (EAP) acts as a framework and transport mechanism for AAA
(Authentication, Authorization, and Accounting) protocols. EAP by itself does not perform AAA tasks or
specify how authentication takes place. Instead, it encapsulates third-party messages within its own
start and end messages, enabling client-server communication using any protocol—existing standardsbased, proprietary, and future mechanisms. The chosen EAP type, such as EAP-TLS or EAP-TTLS, dictates
the algorithm used for authentication.
802.1x is the standard for passing EAP messages packaged in Ethernet frames over any LAN (wired or
wireless) using any communication protocol, such as TCP/IP, UDP, or PPP. 802.1x provides port-based
network access control and is gaining popularity as a wireless security protocol. Although 802.1x is not
exclusively for wireless security, it is the basis for the Wi-Fi Alliance's WPA2-Enterprise specification.
802.1x prevents unauthorized access to Wi-Fi networks by controlling the access rights of ports made
available to devices outside the network. A device that needs to connect to the network does so through
a controlled port that manages the authentication process. If authentication succeeds, general access to
the network via the port is permitted.
Typical Applications
EAP is used for wireless authentication, and is the basis for WPA2, WiMAX, and 4G.
Pros



EAP can support multiple authentication mechanisms without pre-negotiating a particular one.
Network Access Server (NAS) devices, such as a switch or access point, do not need to
understand every authentication method, and can instead act as a pass-through agent for a
backend authentication server.
The separation of the authentication from the backend authentication server simplifies
Credentials management and policy decision making.
Security Protocols for UCA Project
Saved: February 8, 2016
13

EAP supports public key authentication.
Cons



Point-to-Point Protocol (PPP) implementations must be modified to use EAP, and such PPP
implementations diverge from the typical PPP authentication model of negotiating a specific
authentication mechanism during Link Control Protocol (LCP) transport establishment.
The separation of the authentication from the backend authentication server complicates
security analysis and key distribution.
Depending on the chosen EAP mode, If EAP is used in wireless LAN networks and Internet
communications, it is possible for attackers with access to links over which EAP packets are
transmitted to carry out a variety of attacks:
o Discover user identities by snooping authentication traffic,
o Modify or spoof EAP packets,
o Launch Denial of Service (DoS) attacks,
o Mount a man-in-the-middle (MITM) attack,
o And more.
Packet Overhead
N/A
History/Origin
EAP was developed for use with PPP and was later adapted for use in wired IEEE 802 networks. It is
currently under consideration for use in wireless LAN networks and Internet communications.
References



http://tools.ietf.org/html/rfc3748
http://fi.wikipedia.org/wiki/Tiedosto:EAP_message_flow.png
http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol
PANA
Description
Protocol for Carrying Authentication for Network Access (PANA) is a UDP-based network-layer transport
protocol that enables network access authentication between clients (supplicants) and Network Access
Servers (NASs). PANA does not define a new authentication protocol, but uses EAP’s lower layer that
runs between an EAP peer and EAP authenticator.
A PANA session (which helps the client and server establish an EAP session) includes the following
phases:
Security Protocols for UCA Project
Saved: February 8, 2016
14




Authentication and authorization—Either the client or server can initiate the PANA session. This
phases ends when the server sends the authentication and authorization results to the client via
the EAP payload.
Access—After successful authentication and authorization, the client can access the network
and send and receive IP traffic.
Re-authentication—During the access phase, the server can (and the client should) initiate reauthentication before the PANA session lifetime expires.
Termination—The client or server can send an explicit disconnect message any time. (If either
disconnects without an explicit message, the other end should perform clean up upon a failed
liveness test or expiration of the session lifetime.
Typical Applications
PANA can be used for the following purposes:



Mobile IPv6 bootstrapping
Roaming wireless network access control (such as PDA/smartphone use while in transit)
Dynamic service provider selection
Pros



PANA is independent of the link layer mechanism.
PANA is suitable for roaming users.
PANA can be used with any authentication method that can be carried as an EAP method that is
made available to PANA.
Cons

If the underlying link itself is insecure (that is, packets that are transmitted between client and
server are not protected by any physical or cryptographic means), an IPsec SA must be
established to enable access control.
Packet Overhead
N/A
History/Origin
TBD
References





http://en.wikipedia.org/wiki/Protocol_for_carrying_Authentication_for_Network_Access
http://tools.ietf.org/html/rfc5191
http://www.springerlink.com/content/1125148rv5h4179j/
http://www.cs.ucl.ac.uk/staff/ucacdxq/publications/querciaRISK05.pdf
http://datatracker.ietf.org/wg/pana/charter/ and http://panasec.org/docs/PANA-FAQ.txt
Security Protocols for UCA Project
Saved: February 8, 2016
15
Non-IP-Based Protocols
DNP Secure Authentication
Description
Distributed Network Protocol (DNP) is a set of protocols that specify how data acquisition and control
equipment can communicate in a secure fashion.
DNP3 (the current version) operates primarily at layer 2, and provides multiplexing, data fragmentation,
error checking, link control, prioritization, and addressing services for user data.
DNP3 provides features beyond conventional communications protocols:






Output options
Secure configuration/file transfers
Addressing for more than 65,000 devices per link
Time synchronization and time-stamped events
Broadcast messages
Data link and application layer confirmation
Typical Applications
DNP is primarily used by utilities such as water and electric companies. In particular, SCADA (Supervisory
Control and Data Acquisition) systems use DNP for: communications between Master Stations (Control
Centers) and Remote Terminal Units (RTUs) or Intelligent Electronic Devices (IEDs).
As time goes on, DNP is becoming more widespread in adjacent industries such as water/waste water,
transportation, and the oil and gas industry.
Pros



Bandwidth efficiency (achieved through event oriented data reporting)
Very efficient for a layered protocol (DNP3 is based on three layers of the OSI model:
application, data link, and physical)
Good compatibility through floating point number variants and no Endianness problems
Cons



Growing increasingly complex as it attempts to maintain compatibility among many device types
Timing constraint issues are not infrequent
Packet Overhead
TBD
Security Protocols for UCA Project
Saved: February 8, 2016
16
History/Origin
When DNP was originally developed (in the 1990s), it was designed to be reliable, but it was not
designed to be secure because equipment was not generally accessible outside the facility in which it
was housed. However, modern equipment is almost universally accessible through private and public
networks and the Internet.
The current version of DNP, DNP3, includes secure authentication features and is compliant with IEC
62351-5.
References







http://en.wikipedia.org/wiki/Distributed_Network_Protocol
http://www.dnp.org/default.aspx
http://www.transmission-line.net/2011/06/distributed-network-protocol-dnp.html
http://www.automation.com/resources-tools/articles-white-papers/hmi-and-scada-softwaretechnologies/optimized-internet-protocol-network-for-scada-systems
http://www.dnp.org/AboutUs/DNP3%20Primer%20Rev%20A.pdf
http://www.dnp.org/Pages/AboutDefault.aspx
http://www.dnp.org/Pages/AboutFeatures.aspx
AGA 12
Description
AGA 12 Cryptographic Protection of SCADA Communications is a suite of open standards developed by
the American Gas Association (AGA) Cryptography Working group (identified by the same name as the
standard, AGA 12) that is charged with protecting data transmitted by SCADA systems.
The AGA represents local utilities that deliver natural gas to homes in the United States. These utilities
rely on SCADA networks to control operations, and as such are concerned with securing the
communications link between field devices and the control servers or control center.
AGA 12 Working Group documents address the following:




General Recommendations—background, security policy fundamentals, and a test plan for all
areas of cryptographic protection of SCADA systems
Retrofit Applications—protecting legacy, generally low-speed, serial equipment
Protection of Networked systems—high-speed communications systems, including the Internet
Embedded Protection of SCADA Components—how to protect SCADA systems by incorporating
cryptography into components during manufacturing
Typical Applications
AGA 12 can be used by any SCADA components that have been manufactured to be AGA 12 compliant.
Security Protocols for UCA Project
Saved: February 8, 2016
17
Pros
Any OEM can manufacture AGA 12-compliant devices, which are then guaranteed to be interoperable
with other OEM devices, providing a significant market advantage.
Cons
A significant issue of AGA 12 is the lack of key management.
Packet Overhead
TBD
History/Origin
It currently defines an add-on encryption module that can be integrated into a Remote Terminal Unit
(RTU) or Programmable Logic Controller (PLC). Key management is still to be addressed.
The AGA 12 practices were developed by a broad consortium of more than a dozen private companies,
the AGA, government organizations, and other private research foundations.
References




http://intelligrid.ipower.com/IntelliGrid_Architecture/New_Technologies/Tech_AGA12_Cryptographic_Protection_of_SCADA_Communications_Gene.htm
http://igs.nigc.ir/igs/OTHER/AGA-12-SCADA.PDF
http://www.aga.org/About/Pages/default.aspx
https://www.aga.org/our-issues/security/Documents/0603REPORT12.PDF
IEEE P1711
Description
IEEE P1711 Trial Use Standard for a Cryptographic Protocol for Cyber Security of Substation Serial Links
(a companion standard to IEEE P1689) defines the Serial SCADA Protection Protocol (SSPP) for securing
serial communications that connect SCADA systems to master stations. The protocol is designed to
assure the integrity of SCADA messages—that is that the messages are not forged, modified, spliced,
reordered, or replayed.
SSPP is defined at the following layers:



Session—Protocol management with message types that indicate the session negotiation and
control phase or a data message
Transport—Security controls such as encryption and integrity checking
Link—Transmission of parameters (such as modem commands) in the clear
Typical Applications
Expected applications for IEEE P1711 are any and all OEM SCADA devices.
Security Protocols for UCA Project
Saved: February 8, 2016
18
Pros
Any OEM can manufacture IEEE P1711-compliant devices, which are then guaranteed to be
interoperable with other OEM devices, providing a significant market advantage.
Cons
P1711 does not:



Prevent Denial of Service (DoS) attacks
Provide reliable delivery
Specify key management mechanisms or requirements
Packet Overhead
TBD
History/Origin
The companion standard to IEEE P1711, IEEE P1689, is largely a subset of the AGA 12 Part 1 documents.
However, IEEE P1689 is intended to add key management, which was omitted from AGA 12. IEEE P1711
is in development, and the latest draft was issued on 28 February 2007.
References





http://www.isa.org/InTechTemplate.cfm?Section=Standards1&template=/ContentManagement
/ContentDisplay.cfm&ContentID=71651
http://www2.selinc.com/techpprs/6286_TutorialSecurity_GL_20070912.pdf
http://www.digitalbond.com/scadapedia/standards/ieee-p711/
http://grouper.ieee.org/groups/sub/wgc6/documents/drafts/P1711%20Draft%203%202008-0816.pdf
http://www.digitalbond.com/scadapedia/standards/ieee-p1689/
IEC 62351-6
Description
IEC 62351 is a suite of security protocol standards developed by the International Electrotechnical
Commission Working Group 15 of the Technical Committee (TC57) that is charged with developing and
maintaining International Standards for power systems control equipment and systems including EMS
(Energy Management Systems), SCADA (Supervisory Control And Data Acquisition), distribution
automation, teleprotection, and associated information exchange for real-time and non-real-time
information, used in the planning, operation and maintenance of power systems.
The 62351 suite defines how to handle the security for a variety of TC 57 protocols, and includes:


Using digital signatures for data transfer authentication
Ensuring only authenticated access
Security Protocols for UCA Project
Saved: February 8, 2016
19



Preventing eavesdropping
Preventing playback and spoofing
Intrusion detection
The 62351 suite comprises 7 sections; 62351-6 specifically defines security for IEC 61850 profiles.
Typical Applications
TBD
Pros
TBD
Cons
TBD
Packet Overhead
TBD
History/Origin
TBD
References






http://en.wikipedia.org/wiki/IEC_62351
http://en.wikipedia.org/wiki/International_Electrotechnical_Commission
http://tc57.iec.ch/index-tc57.html
http://webstore.iec.ch/webstore/webstore.nsf/mysearchajax?Openform&key=62351&sorting=
&start=1
http://www.enernex.com/Reports/DNPSecurity-Gilchrist.pdf
http://xanthus-consulting.com/Publications/documents/IEC%20_TC57_WG15_White_Paper.pdf
WPA2
Description
WPA2 specifies security mechanisms for wireless networks. It is the Wi-Fi Alliance approved
interoperable implementation of the full 802.11i standard. As such, WPA2 implements all mandatory
elements of IEEE 802.11i, including encryption via CCM mode Protocol (CCMP)—an AES-based
encryption mode with stronger security than WEP’s Temporal Key Integrity Protocol (TKIP).
IEEE 802.11i (and by extension, WPA2) provides a Robust Security Network (RSN) with two protocols
beyond those defined by its predecessor, 802.11-1999:


4-Way Handshake
Group Key Handshake
Security Protocols for UCA Project
Saved: February 8, 2016
20
These two new protocols establish and change the necessary cryptographic keys.
Typical Applications
WPA2 can be used any time devices must connect wirelessly.
Pros



Support for many EAP types, which enables WPA2-certified products to interoperate.
Significantly stronger encryption than preceding wireless standards (WEP and WPA).
Strong authentication (user and computer)
Cons


Equipment manufactured before WPA2 was adopted (June 2004) is unlikely to be compatible.
WPA2 is incompatible with WEP networks and equipment.
Packet Overhead
TBD
History/Origin
Wi-Fi Protected Access II (WPA2) is both a protocol and security certification developed by the Wi-Fi
Alliance to secure wireless computer networks. WPA2 (and earlier, its predecessor WPA) were
developed to address serious weaknesses in Wired Equivalent Privacy (WEP). WPA implements the
majority of the 802.11i standard, but does not fully comply. WPA2 is fully compliant, implementing all
mandatory 802.11i elements.
References




http://en.wikipedia.org/wiki/WPA2#WPA2
http://en.wikipedia.org/wiki/IEEE_802.11i-2004
http://technet.microsoft.com/en-us/library/cc875845.aspx
http://webpages.uah.edu/~iveyd/
Security Protocols for UCA Project
Saved: February 8, 2016
21