Content uploaded by Ankita Lamba
Author content
All content in this area was uploaded by Ankita Lamba on Dec 23, 2016
Content may be subject to copyright.
SECURITY ANALYSIS OF ATLANTICWAVE SDX
A Practicum Report
Presented to
The Academic Faculty
by
Ankita Lamba
In Partial Fulfillment
of the Requirements for the Degree
MASTER OF SCIENCE in the
GEORGIA INSTITUTE OF TECHNOLOGY
Georgia Institute of Technology
DECEMBER 2016
COPYRIGHT © 2016 BY ANKITA LAMBA
1
SECURITY ANALYSIS OF ATLANTICWAVE SDX
Approved by:
Dr. Russell Clark, Advisor
College of Computing
Georgia Institute of Technology
Dr. Mustaque Ahamad
College of Computing
Georgia Institute of Technology
Date Approved: December 12, 2016
2
TABLE OF CONTENTS
3
LIST OF FIGURES
Figure
Figure – AtlanticWave SDX Interface Breakdown
Figure – Data Flow in OpenID
Figure – Data Flow in CAS
Figure – Data Flow in Shibboleth
Figure – High-level Data Flow Architecture of Shibboleth for AtlanticWave SDX within Georgia
Institute of Technology
Figure – Sample of Attributes Returned by IdP (Georgia Institute of Technology)
Figure – Detailed Data Flow Diagram of Shibboleth between AtlanticWave SDX and IdP (Georgia
Institute of Technology)
5
SUMMARY
Software Defined Networks (SDNs) are gaining a lot of traction and popularity in the
networking world. There are multiple reasons for this: the SDN paradigm makes it easier to
implement new abstractions in networking that promise not only the simplification of network
management, but also facilitate network evolution. Software-Defined Internet Exchange Points
implement SDN technology to ease control of traffic flow and exchange, and carry out application
specific peering and server load balancing. The AtlanticWave SDX project undertaken by
researchers at Georgia Institute of Technology and Florida International University is one such
effort towards implementation of an international SDX that focuses on policy specification and
security while attempting to meet the demands of large data transfers among scientists throughout
the world, such as the Large Synoptic Survey Telescope being built in Chile. This work is
concerned with analyzing the security of the AtlanticWave SDX, proposing mitigations and an
overall security policy framework for such architectures. A survey and evaluation of various
federated identity management systems is also performed and an appropriate solution is proposed
and implemented for the AtlanticWave SDX.
6
CHAPTER 1. INTRODUCTION
Software Defined Networks or SDNs are gaining a lot of traction and popularity
in the networking world. There are multiple reasons for this: the SDN paradigm makes it
easier to implement new abstractions in networking that promise not only the
simplification of network management, but also facilitate network evolution. SDNs break
the vertical integration of traditional network models by separating the control and data
planes. They move the control from optimized hardware of routers to software running on
commodity hardware, leveraging on the OpenFlow protocol to enable communication.
Internet Exchange Points (IXPs) which are also becoming progressively rampant
in network topology are already implementing the SDN technology due to the ease of
controlling traffic flow and exchange, application specific peering and server load
balancing. This is referred to as the Software-Defined Internet Exchange Point (SDX).
There are a variety of applications of these emerging technologies. The AtlanticWave
SDX project undertaken by researchers at Georgia Institute of Technology and Florida
International University is one such effort towards implementation of an international
SDX that focuses on policy specification and security while attempting to meet the
demands of large data transfers among scientists throughout the world, such as the Large
Synoptic Survey Telescope being built in Chile.
A lot of work in the space is being done especially in the academic setting.
Although, on the one hand leveraging on the benefits that such exchange points offer,
seem the obvious way to go, it is important to consider the effects it is likely to have on
existing players in the market such as Internet Service Providers (ISP). It is necessary to
7
gauge the ISPs' institutional environment and framework such as by-laws and policy
implications and the effect that migrating to a technical framework such as the
AtlanticWave SDX, for instance, might have.
Apart from policy concerns as the above, some of the unique benefits offered by
SDNs are also what give rise to other security concerns due to a centralized control logic,
non-proprietary software such as OpenFlow [9], and a programmable and dynamic design
to name a few [13, 17, 22]. As such, it is extremely important to address these concerns
and come up with novel approaches to tackle them. This would ensure that security is
built into the design of SDN architectures and platforms instead of as an afterthought.
The rest of this paper is organized as follows: a background, which talks about the
related protocols and technologies and the threats associated with them; a Threat Model
of the AtlanticWave SDX; followed by security issues at various interfaces of the current
AtlanticWave SDX architecture as well as mitigations to address the issues. Survey and
evaluation of Single Sign-On Identity and Access Management Solutions such as
OpenID, Central Authentication Service and Shibboleth follows next and includes their
respective threat models and pros and cons. The three solutions are compared and details
of implementing Shibboleth in the AtlanticWave SDX are outlined, concluding with
opportunities for future work.
8
CHAPTER 2. BACKGROUND
To analyze the current attack surface for a SDX, it is logical to begin with the most
widely used internet routing protocol today: Border Gateway Protocol (BGP). We are
already aware of the known security issues that this protocol comes with [16, 20, 21]. To
name some of them, BGP does not:
oProtect integrity and source authentication of messages;
oValidate an Autonomous System’s (AS) authority to announce reachability
information;
oEnsure authenticity of the path attributes announced by an AS.
The above lead to a variety of attack vectors such as:
oDisclosure: eavesdropping, traffic analysis
oDeception: modification, deletion, man in the middle
oDisruption: replay, denial of service
oUsurpation: seizing router services / functions
Several mitigations to address the above have been proposed in the last decade, such
as Secure BGP, RPKI [6], Interdomain Routing Validation service, Secure Origin BGP.
These mitigations are yet to be fully adopted though, as they add additional complexity,
infrastructure and cost to the network, thereby affecting convergence. Not to mention, the
legal and policy issues surrounding the ISPs as well.
9
The other building block to the internet today are the IXPs. This is a physical
infrastructure at which ISPs and Content Delivery Networks (CDN) come together to
exchange traffic between the ASes. This is generally a "settlement-free" peering
arrangement between the involved parties. We can very well imagine the magnitude of
damage that would be caused if an IXP were compromised by malicious actors [12, 14,
15]. Widespread service outage and usurpation would be likely, based on the
sophistication of the attack. Surprisingly, most of the IXP infrastructures today have little
or no physical security, to prevent this scenario. Could this be security by obscurity [34]?
Traditional IXPs leverage on BGP and are based on destination IP prefixes, thus
inheriting all the vulnerabilities of BGP. On the other hand, a SDX would leverage on the
capabilities of SDN, with direct control on packet processing rules, matched on multiple
header fields. As such, application-specific peering would be possible. It also presents the
opportunity for us to explore avenues for better security implementation using the
features that SDN offers.
In [1] Joaquin Chung, et. al. present three types of SDX architectures currently in
existence:
1. Layer-2 SDXs which exchange multi-domain Ethernet circuits in NRENs: The
AtlanticWave SDX will be the first of its kind in this category, and will be partially
functional by the end of 2016. Its primary use case is to transfer astronomical images of
the order of terabytes per night from American telescopes in Chile to the United States
for analysis by astrophysicists.
10
2. Layer-3 SDXs which exchange BGP updates at IXPs: There are several Layer-3 SDXs
that currently exist: SDN-IP proposed by Lin et. al. [5], Google's Cardigan [3], and the
SDX framework by Gupta et al. [2]
3. SDN SDXs that interconnect SDN islands: FELIX by Carrozo et. al. [4] and peer-to-peer
SDN SDX are examples of this type.
It is noteworthy that none of the above SDX architectures discuss the security framework
or concerns related with them.
11
CHAPTER 3. THREAT MODEL
The Threat model for the AtlanticWave SDX is broken down into application
overview, decomposition, flow diagram and vulnerabilities, based on Microsoft’s
STRIDE model [23].
3.1 Application Overview
oRoles:
oSystem Administrators
oEnd users: scientists, researchers
oKey Scenarios:
oAuthenticated user adds/tests/removes rules
oAuthenticated user searches for rules based on filters
oAuthenticated user views existing topology of the network
oTechnologies:
oWeb framework: Apache wrapper around Python Flask
oServer: RHEL 6 Virtual machine
oSwitches: SDN / OpenFlow protocol
oSDN Controller: Ryu (Python)
oSecurity Mechanisms:
oUsers are authenticated via the Shibboleth Single Sign-On with Georgia
Institute of Technology as the Identity Provider
3.2 Application Decomposition
oEntry Points:
12
oPort 80 for web requests
oPort 5000 for internal requests
oLogin page
oExit Points:
oResults page after submitting a new rule request
oResults page for viewing existing rules
oViewing current network topology
oSuccessful flow rule installed in the data plane
oTrust Boundaries:
oShibboleth Single Sign-On for Identity and Access Management
3.3 Application Flow Diagram
Figure – AtlanticWave SDX Architecture Diagram
13
CHAPTER 4. SECURITY ISSUES AT ATLANTICWAVE SDX
INTERFACES
Figure – AtlanticWave SDX Interface Breakdown
4.1 Interface 1: Information Disclosure, Denial of Service
Apart from obvious threats like cross-site scripting and a variety of injection
attacks that are likely to affect this interface, we would focus our efforts on the SDN
specific threats. Consider a legitimate user who can insert a policy or rule using the web
interface into the SDX which in turn violates existing rules by other legitimate users. This
may be a deliberate or inadvertent attempt to cause denial of service for another user of
the system. This problem becomes further magnified when maintaining SLAs for
different organizations and the users within them is of importance to the success of the
system.
14
Threat I.1: Attacker obtains user credentials by monitoring the network
A. Clear text credentials sent over the network AND
B. Attacker uses network sniffing tools
a. Attacker obtains credential data
Threat I.2: Attacker gains access to user information by injecting malicious script into
web page (Cross-site Scripting)
A. Input validation is not performed AND
B. User input is not encoded
a. Attacker fools the browser into trusting her script and executing it
b. Attacker steals user information such as cookies, session tokens or rewrites HTML page
content
Threat I.3: Attacker gains access to/modifies user information by relaying malicious code
A. External interpreters are used to make system calls AND
B. Input validation is not performed OR
C. Supplied parameters are not treated as data instead of executable content OR
D. Web Server is run as root access
a. Attacker injects meta characters, malicious commands, or command modifiers into the
web app which is then passed to the external system for execution AND
b. Attacker gains access to unauthorized content for misuse, modification or destruction
Mitigation:
15
oEnsure the use of SSL/TLS tunnel on the authentication page to prevent sniffing
of valid credentials. Adding tokens like “secure” and “httponly” to all Session ID
cookies would provide an additional layer of security as this would force the
user’s browser to send these sensitive cookies over an SSL tunnel only. Another
approach is to create a “hashed ticket” that is created at the time the user
authenticates for the first time. It uniquely identifies the user by considering
information such as the user’s account name, IP address, date and time of login
and a cryptographic signature. All session tokens must be forcefully expired after
a certain period or inactivity to minimize the window of opportunity for an
attacker guess token values. All session related information must be deleted from
the backend server once the user logs out. This is necessary to prevent the misuse
of the back button on the browser and ensure that the user session is closed.
oLimit the information disclosed by Apache during reconnaissance by editing
certain directives in httpd.conf:
oServerTokens Prod - prevents version numbers from being sent in
the HTTP header;
oServerSignature Off - prevents server version numbers from being
sent in the footer of server generated pages;
oMod_security - a module that enables web administrators to
modify the Apache server name to something else to misguide the attacker.
oUse generic error messages when an unexpected event occurs to withhold the
amount of sensitive data exposed to an attacker. Default or verbose error
messages during failed API calls, for example, may disclose more than necessary
16
to undermine the security of the web application. Instead, it is advised to maintain
the debug logs on the server-side to ensure that they are not publicly accessible.
oLimit directory indexing. The content revealed by directory listing could expose
sensitive information that is not intended for the public, such as backup files,
temporary files, hidden files, script contents, configuration file contents and even
enumerate user account information.
oLimit path traversals as they may lead an attacker to be able to access data
residing outside of the web document root directory. An attacker can craft URLs
to reveal or execute arbitrary files anywhere on the server. This is achieved by
using ‘../’ and alternate encodings to bypass security filters. This kind of an attack
may be prevented by validating user input, normalizing all path references by
using the mod_security directive and ensuring minimum read permissions for files
outside of the web document root.
oPerform input validation on user submitted fields, not only on the type of input
but also the size. It is also recommended to verify encodings and enforce byte
ranges to prevent buffer overflow vulnerabilities and format string attacks.
oRestrict users to connect only from one IP address to restrict multiple sessions
from different locations for the same user.
oConfigure Web Application Firewall (WAF) to detect/block transmission of
sensitive information.
Threat D.1: Attacker causes denial of service on the web application or against a user of
the web application
A. Load balancing is not performed AND
17
B. Unauthenticated users can perform expensive operations OR
C. Content received by unauthenticated users is not cached, instead queried by backend
a. Attacker consumes all some required resource
D. Error handling scheme is not in place
a. Attacker can insert a rule that conflicts or overrides an existing rule of a legitimate user
b. Attacker harvests legitimate user accounts and locks them out by trying invalid
credentials
c. Attacker requests a new password for a user
d. Attacker takes the web application offline completely
Mitigation:
oEmploy traditional measures such as isolation of critical resources, server fail-
over mechanisms, threshold-based load balancing and redundancy;
oDo not allow unauthenticated users to perform expensive operations,
consequently leading to high consumption of resources;
oCache the content received by unauthenticated users instead of querying from the
backend for every request made;
oFor Denial of Service targeting user accounts, mechanisms to detect if automated
means to authenticate to various user accounts are being used may be beneficial.
In this way, the source IP conducting this activity can be identified and prevented
from doing further harm. This mechanism would likely be applicable in a broader
sense to detect other automated processes that could generate a huge number of
requests, thereby causing potential degradation of service to legitimate users of
the application.
18
4.2 Interface 2: Spoofing, Tampering with Data, Repudiation, Information
Disclosure, Denial of Service
At this level, an apparent security threat is the poisoning of the northbound and
southbound interfaces of the SDX. Here, the southbound interface is the OpenFlow
protocol specification. Its main function is to enable communication between the SDN
controller and the network nodes (both physical and virtual switches and routers) so that
the router can discover network topology, define network flows and implement requests
relayed to it via northbound APIs. The northbound interface describes the area of
protocol-supported communication between the controller and applications or higher
layer control programs.
Additionally, there is a more interesting security problem of establishing trust
between the local controllers and network devices. The threat model comprises of one or
more Byzantine players (controllers) in the architecture that may collude with each other
and push malicious updates to network devices. As such, a mechanism to verify the
updates before accepting or propagating them is necessary at this level to prevent
snooping and other types of compromise mentioned earlier. Additionally, there is the
‘malicious administrator’ problem at this level wherein a network administrator may try
to cause damage to routing, forwarding, availability, etc. [10]
Threat S.1: Fake SDX controller inserts unauthorized rules
A. Mutual authentication between the participating entities is not performed
Threat T.1: Attacker poisons the northbound or southbound interface by sniffing traffic
19
A. Communication channels are not encrypted OR
B. Proper access control is not implemented OR
C. SDX controller does not have central view of the network
a. Attacker gives instructions to the SDX controller and has complete control over the
network
Threat T.2: Attacker compromises the entire network by compromising one or more of the
local controllers
A. No authentication or authorization is performed OR
B. No trust establishing mechanisms like digital signatures are used
a. One or more malicious controllers collude with each other to propagate malicious rules to
network devices, thereby affecting routing, forwarding, availability, etc.
Mitigation:
oEstablish PKI and digital signing mechanisms amongst local controllers before
accepting updates;
oDemonstrate trust establishment by having a threshold of the controllers agree to
an update before it is accepted. This could be achieved by a voting protocol where
k out of n controllers accept the update before it is pushed network-wide.
Threat R.1: Fake controller submits malicious rules to other network devices, but the real
controllers deny doing this
Mitigation:
oMaintain audit logs to monitor, analyze and report suspicious activities;
20
oEstablish mutual authentication between controllers to establish their authenticity
before accepting any updates by using digital certificates, for example.
Threat I.4: Eavesdropping from a fake local controller
A. Communication channel are not encrypted OR
B. Mutual authentication between the participating entities is not performed
Threat D.2: User inserts a policy that violates existing rules/policies of another
legitimate user(s)
A. Mutual authentication between the two parties is not performed AND
B. New policy is not validated against existing rules/policies
a. User successfully inserts a rule into the SDX controller that violates other users’ rules
Mitigation:
oUse SSL/TLS certificates (https) in the modules that do some secured
transactions;
oPrevent code injection attacks;
oDisplay last visited time and the IP address from where the user visited when re-
authenticating to the site;
oEnsure proper access control mechanisms are in place;
oDon’t use persistent cookies for storing authentication tokens (session ids);
oEnsure that SDX controller has a central view of the network;
oIn-band channel between SDX and local controllers must be accessible within the
local network only;
21
oValidate new rule submission against existing rules before accepting it.
4.3 Interface 3: Elevation of Privilege
At this interface, there are vulnerabilities in the OpenFlow protocol itself, that come
into effect.
Threat E.1: Attacker causes privilege escalation by exploiting vulnerabilities in hardware
and protocols used
A. Known vulnerabilities in hardware and communication protocol AND
B. Patch released by vendor is not applied
a. Attacker successfully exploits the vulnerability thereby gaining access to the system
Mitigation:
oKeep up-to-date with security patches released by vendors of respective
technologies used in the architecture;
oMitigate spoofing threats as outlined earlier to prevent attacker from gaining
access to valid user credentials.
22
CHAPTER 5. IDENTITY AND ACCESS MANAGEMENT:
SURVEY AND EVALUATION
Identity and Access Management is one of the foundations of a security policy
framework and revolves around the management of electronic identities. A complete IAM
solution encompasses the following categories [24]:
A. Authentication
a. Single Sign On (SSO)
b. Session Management
c. Password Services
d. Strong Authentication
e. Multi-factor Authentication
B. Authorization
a. Role-based
b. Rule-based
c. Attribute-based
d. Remote
C. User Management
a. Delegation
b. User and Role Management
c. Provisioning
d. Password Management
e. Self-service
D. Central User Repository (or Directory Services)
23
a. Directory
b. Data Synchronization
c. Meta-directory
d. Virtual Directory
Deployed alone, an identity management solution would lack the granularity
needed to prevent unauthorized access and modification of information as well as
information leakage. This is particularly true of systems that hold highly sensitive data
and involve privileged users that can manipulate the entire application. In combination
with access management, a holistic IAM solution would encompass the “AAA” triad or
Authentication, Authorization, and Auditing, of system-centric security. Overall, a well
implemented IAM solution must be able to answer the “who, what, where, and how” of
identity.
Lately we have seen a growing number of online services that allow users to login
with existing credentials that they may already have with Google, Facebook, etc., for
example. Instead of having the user go through the inconvenience of creating a new
identity to be able to use a service, such a system leverages on a Federated IAM system
to authenticate users. Several standard initiatives have been put in place for federated
identity management systems:
5.1 OpenID
This authentication protocol is based on OAuth 2.0 specifications and relies on
REST/JSON messages to implement its functionality. It has been deployed by Google,
Microsoft and Yahoo! to name a few. The OpenID working group argues that the protocol
24
is very easy for developers to implement as it leverages on the built-in SSL/TLS
capabilities of clients and servers and used JSON web tokens as data structures when
signatures are required [27]. The OpenID architecture comprise of three main entities:
1. The user looking to identify himself and consuming resources from the RP;
2. The Relying Party (RP) looking to verify the identity of the user; and
3. The OpenID Provider (OP) that registers the user’s OpenID URL and can verify
it.
The authentication takes place as per the following sequence of steps:
1. The user requesting a resource provides their OpenID URL to the RP;
2. The RP discovers the OP and initiates and association;
3. The OP generates keys and an association handle and returns them to the RP;
4. The RP redirects the user to the OP with an authentication request;
5. User present an authentication request to the OP;
6. The OP validates the user’s request, authenticates her ad redirects her back to the RP with
a signed assertion;
7. The user presents the signed assertion from the previous step to the RP;
8. The RP validates the assertion presented by the user against the one it received from the
OP and if successful, creates a session for the user.
25
Figure – Data Flow in OpenID
OpenID implementations have been identified to be affected by the following types of
attacks:
Table – STRIDE Threat Model for OpenID
Spoofing
oAn attacker may craft a phishing page to trick the user into entering
her OpenID credentials.
oIf the OP (OpenID provider) itself is successfully compromised, it
would result in the attacker obtaining the user’s OpenID credentials
itself.
Tampering oA variety of session related attacks are possible in the scenario that
the user has several authenticated sessions, like:
○ Session swapping
○ Cross-site request forgery (CSRF)
○ Cross-site scripting (XSS)
Repudiation oReplay attacks are possible if the RPs do not check for nonce.
Information
Disclosure
oSince OpenID uses Diffie-Hellman for connection negotiation, it is
prone to a variety of interception attacks.
oUser’s privacy can be compromised since the OP would know the
user’s online behavior and track it. This is of much more concern if
the OP is malicious.
26
oPrivate information may also be disclosed via the means of
tampering mechanisms mentioned earlier.
Denial of
Service
oThe OpenID identifier is essentially a URL entered by the user. An
attacker could craft an identifier that could not only cause buffer
overflows, injections or directory traversal attacks against the
relying party (RP) but may also trigger download of data from an
arbitrary online location.
Elevation of
Privilege
oTechniques described under spoofing would all result in an attacker
gaining illegitimate access to a user’s account.
Advantages:
oEasy to implement.
Disadvantages:
oCurrently supports social logins only;
oInvolves placing a lot of trust in the OP. Compromise of credentials at the level of
the OP would result in a waterfall effect for all the RPs;
oNo global logout.
5.2 Central Authentication Service (CAS)
A single sign-on protocol for the web that validates a client’s authenticity against a
database, the CAS architecture comprises of two physical components: clients and
servers that can communicate with each other via different types of protocols. CAS
enables authentication services on the web via Kerberos or LDAP [28]. The CAS
architecture comprise of three main entities:
1. The user looking to identify himself and consuming resources from the SP;
2. The Service Provider (SP) looking to verify the identity of the user; and
27
3. The CAS server that registers the user’s CAS credentials and can verify it.
The basic CAS mechanism is outlined in the sequence of steps below:
1. User attempts to access a CAS-protected page on the SP site;
2. SP’s CAS client redirects to CAS server’s login page where the user enters her
credentials;
3. CAS validates the credentials;
4. CAS verifies the if the SP site is registered;
5. User is redirected to the SP site along with the generated service ticket in the URL
request;
6. A new secure connection is initiated by the SP’s CAS client, including the service
ticket. The service ticket is validated and an authenticated user ID is returned to
the SP;
7. SP renders the requested protected resource to the user.
Figure – Data Flow in CAS
28
The following security issues are of concern in a CAS implementation:
Table – STRIDE Threat Model for CAS
Spoofing
oIf communication channels are not encrypted with SSL/TLS, there
is likelihood of leakage of security credentials and the ticket-
granting token used for the authentication process.
Tampering oIt is possible to inject arbitrary parameters into the URL used in
back-channel validation of the CAS protocol due to improper URL
encoding.
Repudiation oIn case proxy authentication is enabled, the onus of validating the
proxy chain of ticket delegation lies with the services accepting
these proxy tickets. If the services do not perform the validation
task, it poses a security risk.
Information
Disclosure
oThere are opportunities for information leakage in an architecture
where the CAS server is deployed on multiple nodes because of
cache and synchronization issues. It is recommended to perform
client certificate verification and encryption of database disk storage
to prevent related attacks.
Denial of
Service
oCAS does not contain any denial of service vulnerabilities that
cannot be mitigated by having common controls such as web
application firewalls and horizontal scaling in place.
Elevation of
Privilege
oThe impersonation techniques that are possible from spoofing and
tampering constitute elevation of privilege.
Advantages:
oMechanisms available to provide forced and passive authentication for
each new service that a user tries to log into, hence providing an extra layer of
security;
oSupports multi-factor authentication;
oProvides login throttling to prevent denial of service and brute-force kind
of attacks;
29
oRequires no extra software on client side.
Disadvantages:
oUsername is the only attribute returned;
oWorks for all accounts;
oNo single sign-out.
5.3 Shibboleth
Developed by Internet2, the Shibboleth system enables multiple independent
organizations to come together and exchange web-based resources by abstracting the
finer details of authentication and authorization techniques altogether. Hence, it enables
cross-domain single sign-on without having content providers maintain usernames and
passwords. It is built upon the Security Assertion Markup language (SAML) standard and
consists of Identity Providers (IdPs) that supply user information and Service Providers
(SPs) that consume this information in return for providing content to the end users [19,
25, 26, 29, 30, 31]. The main components of the architecture are:
1. An Identity Provider (IdP);
2. An optional Where Are You From (WAYF); and
3. The Service Provider (SP).
The basic Shibboleth mechanism is outlined in the sequence of steps below:
1. User attempts to access an enterprise application hosted by the SP;
2. The SP generates a SAML request and refers to an intermediary, the WAYF, to determine
the user’s preferred IdP;
30
3. The WAYF would communicate with the user to determine the information requested in
the previous step;
4. Based on the decision in step 3, the user’s browser is redirected to the IdP along with the
SAML request. At this point the IdP authenticates the user after parsing the SAML
request and generates an encoded SAML response;
5. The user’s browser is redirected to the SP along with the SAML response;
6. The SP verifies the SAML response and if successful, creates a session for the user;
7. SP renders the requested protected resource to the user.
Figure – Data Flow in Shibboleth
A distinctive feature of Shibboleth is how it manages attributes. It uses SAML - a
SOAP-based attribute query protocol, eduPerson - a standardized directory schema and
attribute release policies - that enable users and admins to control the flow of attributes
between IdPs and SPs. This is a powerful mechanism that protects the privacy of users
while providing authorization capabilities at the same time. There consist about 40
31
attributes overall, out of which the six highly recommended ones are tabulated in Table 3.
The attribute release policy determines which of these 40 attributes can be released to an
SP. The information about the IdPs and SPs are maintained in digitally signed files called
metadata files. The following table gives a sample of available attributes and the kind of
information they hold.
Table – Attribute Examples for Shibboleth
Attribute Name Example
givenName Ankita
sn Lamba
cn Ankita Lamba
eduPersonScopedAffiliation student@gatech.edu
eduPersonPrincipalName alamba3@gatech.edu
eduPersonTargetedID 9zAI1psLqw92t9zvtkFlwfmScK4
SANS identifies the following types of attacks that the Shibboleth architecture is
vulnerable to:
Table – STRIDE Threat Model for Shibboleth
Spoofing
oSpoofing is generally countered by SSL certificates but it is possible
for an attacker to steal credentials by spoofing the website since a
lot of trust is placed on the DNS and Certificate Authority, which
may often be misplaced.
oOnce an attacker is successful with the previous attack, she can
reuse the stolen credentials as she wishes. Hence, it is advisable for
Shibboleth to be used with Kerberos or X.509 client certificates or
alternatively with multi-factor authentication to provide an
additional layer of security to the authentication mechanism. Having
multi-factor authentication in place also mitigates the risk if the
attacker steals credentials stored on the client.
oIn a broader context, an attacker could very well spoof the IdP, SP
32
or federation itself.
Tampering oMost of the known tampering attacks that are possible are already
mitigated in the latest release of Shibboleth (IdP version 2.3.2 and
SP version 2.4.3).
Repudiation oThere exists a known bug which can be exploited to inject
misleading log entries adding unnecessary overhead for the
administrator. This threat can be mitigated by proper logging and
auditing.
Information
Disclosure
oUsually, only the communication channel is encrypted but an
attacker can still read data from SAML messages since they are
exchanged unencrypted. Additionally, an attacker may also be able
to discover the key being used for encryption. To mitigate such
attacks, SAML assertions must be signed and encrypted so that only
the intended parties may read them.
oIn case of web applications that implement local authentication with
an optional SAML pre-authentication layer on top, it is required of
SAML to provide more identifiers than are needed, to meet the
application’s requirements. Now, if this web application SP turns
out to be untrustworthy, the unnecessarily shared information can
end becoming compromised.
Denial of
Service
oShibboleth does not contain any denial of service vulnerabilities that
cannot be mitigated by having common controls such as web
application firewalls and horizontal scaling in place. It is also
recommended to have a distributed authentication mechanism for
redundancy.
Elevation of
Privilege
oThe impersonation techniques that are possible from spoofing and
tampering constitute elevation of privilege.
Advantages:
oMeets industry standards for identity management;
oImplements strong privacy control to ensure protection of user’s personal
information even when services use access control;
oProvides attribute-based authorization for all applications: both group-based and
role-based;
33
oDesigned for inter-domain enterprise logins;
oInternational acceptance leading to scalability and widespread collaboration.
Disadvantages:
oQuite complex to implement especially in the case of proxy servers, requiring
high-level of expertise in XML;
oNot fully compliant with SAML 1.1;
oDifficult to use from a user agent that is not a web browser;
oNo global logout.
The diagram below shows the current Shibboleth architecture for the AtlanticWave
SDX. The web application is open only within Georgia Tech, on ports 80,443 and 5000.
Figure – High-level Data Flow Architecture of Shibboleth for AtlanticWave SDX
within Georgia Institute of Technology
34
As we expose the service to other universities, we would require to be registered
with the InCommon Federation [32] that supports a common framework for trusted
shared management of access to online resources. Through this service, IdPs can give
their users a single sign-on option and at the same time protect users’ privacy and access
to their protected resources.
Table – Comparison of Popular Federated IAM System
Token Format
Authorization
Authentication
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Suited for
#CVEs (last 3 years) *
OpenID JSON No Yes Yes Yes Yes Yes Yes Yes Consumer
apps
15
Shibbolet
h
SAM
L
Yes Yes Yes No Yes Yes No Yes Enterprise
: cross-
domain
9
CAS TGT Yes Yes Yes Yes Yes Yes No Yes Enterprise
: intra-
domain
1
(*Source: National Vulnerability Database)
5.4 Interview with Subject Matter Expert
To gain an understanding of the three IAM implementations considered in this
work from an industry expert, we met with Mr. Bert Bee-Lindgren (B) who works in the
IAM team at Office of Information Technology at Georgia Institute of Technology.
Q. What are the main features that set CAS, OpenID and Shibboleth apart?
35
B: CAS is used mainly within an organization and unlike OpenID and Shibboleth, is not
quite popular for cross-domain scenarios. Its functionality is also quite limited compared
to Shibboleth. In terms of security, CAS requires the organization to open its Firewall to
the outside world whereas in Shibboleth this doesn’t need to be done as cross-domain
implementations require the organization to be registered with the InCommon Federation,
which coordinates the certificates amongst participating entities to have them authenticate
via Shibboleth.
Q. How does the implementation complexity vary for each?
B: CAS is probably the easiest to implement, followed by OpenID and lastly Shibboleth.
OpenID uses JSON web tokens compared to the more involved XML knowledge
required for Shibboleth.
Q. What are the costs associated with the three options?
B: The code for CAS, OpenID and Shibboleth is in the open source domain so there are
no inherent costs associated with either of them. It is to be considered though that
although CAS is the easiest to deploy and does not require much expertise amongst the
three, OpenID is somewhat more involved and may require consultants to implement
correctly. Shibboleth on the other hand, though not as simple as CAS or OpenID has a
wide support from the academic community.
Q. Do you see typical use cases for the three types of IAM solutions?
B: CAS is useful for simple use cases such as intra-domain single sign-on applications
whereas OpenID and Shibboleth are both applicable in cross-domain single sign-on
36
applications. Additionally, OpenID seems to be a better option if the application is public
facing whereas Shibboleth is applicable in academic settings as it is widely supported and
accepted in the research and academic community.
Q. How widely are the three technologies implemented in Georgia Tech?
B: In Georgia Tech, CAS is the most widely deployed and supported in about 1500
applications. Shibboleth is supported to collaborate with other academic entities but not
used in internal applications at Georgia Tech, hence the support and expertise for it is
limited. Even though CAS offers a subset of features compared to Shibboleth, the reason
behind it being more popular is its ease of implementation. OpenID is not yet used or
supported by Georgia Tech.
Q. What kind of trends in IAM do you see going forward?
B: OpenID is gaining more traction, so its adoption within the research and academic
community is the way forward. We must consider ways to incorporate OpenID without
its social aspects to minimize compromise. Academic institutes must support OAuth
identity providers to achieve this goal.
37
CHAPTER 6. IMPLEMENTATION DETAILS OF SHIBBOLETH IN
ATLANTICWAVE SDX
Since the AtlanticWave SDX API is implemented using Python Flask, the initial
approach to implementing Shibboleth was to add SAML 2.0 support to the web
application. This would be the first logical step towards enabling the application to act as
a SP that would in turn communicate with the Georgia Institute of Technology’s
Shibboleth IdP. We based our endeavor on the documentation here but ran into issues
with the libxmlsec1 package.
We then switched to an alternative approach as documented on Shibboleth’s wiki
page [25]. This process starts with install the Shibboleth SP with the RPM provided on
respective mirror sites for various Linux distributions. The AtlanticWave SDX API was
running on a CentOS 7 virtual machine but the corresponding repository link on the
magnet link was missing. Hence, we could not proceed with the installation. We decided
to reimage the virtual machine to RHEL 6 instead and proceed with the installation from
there. Fortunately, we could follow through the steps provided in the documentation from
there on. This approach involves an Apache wrapper around our existing Flask server.
After installation, Shibboleth configuration files are placed at /etc/shibboleth/ and the
necessary Apache configuration is in /etc/httpd/conf.d/shib.conf. We modify the
attributes.xml file within /etc/shibboleth to point to the appropriate SP (AtlanticWave
SDX) and IdP (Georgia Institute of Technology) and return the required attributes. Some
attribute samples are shown in the screenshot from the Shibboleth IdP API for Georgia
Institute of Technology below.
38
Figure – Sample of Attributes Returned by IdP (Georgia Institute of Technology)
After successfully configuring the Shibboleth authentication service, the next step
was to create and maintain a user session upon successful login, like so:
39
The code snippet above does not involve sharing of the file system or memory
cache. It also offers extra functionality to get useful statistics from the attributes returned
post authentication such as whom the user was logged in by, the time of login, duration of
login, etc. Many useful attributes can be extracted by parsing the attributes.xml file based
on the requirements of the application.
40
Figure – Detailed Data Flow Diagram of Shibboleth between AtlanticWave SDX
and IdP (Georgia Institute of Technology)
6.1 Login Walkthrough
1. User goes to SDX for the first time. No web session/cookies exist;
2. User sees landing page that includes a “Login with your GT Account” button;
3. User clicks “Login with your GT Account” button and is redirected to the Shibboleth-
protected directory within Apache, and the login.cgi script;
4. User’s browser requests /secure/login.cgi;
41
5 & 5.5. Request is intercepted by the Shibboleth SP module that is protecting /secure/.
SP module sees that there is no session and redirects browser to idp.gatech.edu with a
SAMLRequest for SP aw.cloud.rnoc.gatech.edu;
6 & 6.5. idp.gatech.edu redirects browser to CAS with service=idp.gatech.edu. User
either enters username and password or is single signed-on via a preexisting CAS
session;
7, 7.5 & 7.75. CAS redirects browser to idp.gatech.edu with a CAS ticket which
idp.gatech.edu validates and learns the user’s identity/username;
8 & 8.5. idp.gatech.edu redirects browser back to the Shibboleth SP module with a signed
SAMLResponse with the user’s identity
(eduPersonPrincipalName=<username>@gatech.edu);
9. The Shibboleth SP module validates the SAMLResponse, sets a REMOTE_USER CGI
environment variable and executes login.cgi;
10. login.cgi chooses a large, random number and creates a session-initialization file with
the REMOTE_USER and other environment variables;
11 & 12. login.cgi returns a redirect to the Flask Server’s /build_session url with the
session-initialization filename;
13, 14, 15 & 16. Flask’s /build_session endpoint reads the session-initialization file and
builds a session for that user. The browser is then redirected to the main app functionality
with a cookie or other session mechanism.
42
When it comes to access control though, the information returned by the attributes
may not be as fine-grained as required for the application to perform access control since
they are based on affiliations or groups within the organization. Hence, this functionality
may have to be achieved on the application side. One way to achieve this is by
integrating Shibboleth with Grouper (Internet2) [34]. With this technology, participating
institutions can release group information to Shibboleth SPs in a secure way when a user
is accessing a site. This is applicable for the AtlanticWave SDX since although Georgia
Institute of Technology is our IdP, it does not have a relationship with the web application
or other participating institutes. Hence, the requests related with the application could be
funneled through a proxy, for example, permitting grouping of users at the proxy level.
Another upcoming alternative is COmanage (Internet2) [35] which is already in
use by the LIGO project. It provides federated identity management services for virtual
organizations and has the grouping functionality that we previously mentioned, built-in.
It does seem though that COmanage integration is too involved a process for a single
application such as the AtlanticWave SDX, and instead would be more useful in a use
case that involved integration of multiple applications with time.
43
CHAPTER 7. FUTURE WORK
As the AtlanticWave SDX matures in the coming months, there is scope for several
works within the security domain of this application, such as:
oConsider other IAM solutions such as OpenID to test and compare the
implementation difficulties and performance of each option;
oSince none of the current IAM solutions that were studied implement a single
logout functionality, it is an area of active interest;
oAs the application expands to other universities and institutes, the IAM solution
needs to be scalable. One of the recommended steps would be to register with
InCommon Federation to achieve cross-domain authentication;
oExplore eduGAIN by InCommon Federation for authentication of entities from
the South American continent as Shibboleth is not adopted there;
oExplore pros and cons of other Internet2 technologies such as Grouper and
COmanage to evaluate their applicability for access control in the AtlanticWave
SDX context;
oImplement other security measures and mitigations proposed in the work.
44
APPENDIX A. OVERALL SECURITY POLICY OUTLINE
A.1 Users and Application
A.1.1 User account management
Ensure that proper approvals are in place before a user can register for an account
on the system. The approvals must come from the admins of AtlanticWave SDX at the
level of each participating entity (like universities, research institutes, etc.). The
procedure for obtaining an approval like obtaining and completed forms and related sign
offs must be known and communicated to the concerned stakeholders.
A.1.2 Privilege management
It is necessary to identify the types of accounts that can be created and the
privilege associated with each of them based on the requirements of the role within the
AtlanticWave SDX. The principles of least privilege and separation of duties shall be
followed and access granted on a need-to-know basis. A threshold shall be established as
per which temporary and inactive accounts shall be deleted from the system. Account
managers / system administrator shall be notified about the modifications that take place
with respect to accounts such as creation, disabling, termination, etc. and changes to their
associated privilege. These activities shall be logged and audited.
A.1.3 User password management
The AtlanticWave SDX shall enforce a password complexity and reset policy
based on industry standards.
A.1.4 Information access restriction
This control shall be implemented by means of policies such as discretionary
access control, mandatory access control, role-based access control or a combination of
45
these. Such policies shall be enforced by mechanisms like access control lists, access
control matrices, and cryptography. Information shall be restricted on need-to-know basis
for various roles such as admins, domain scientists, data agents, research assistants, etc.
within the AtlanticWave SDX participants to prevent leakage of rules/data to
unauthorized users.
A.1.5 System use notification
Potential users shall be notified about the system’s usage guidelines,
confidentiality levels and if it is subject to monitoring, recording, auditing. It shall also
seek the user’s explicit consent to the same.
A.1.6 Unsuccessful login attempts
The authentication system enforces a limit on the maximum number of
unsuccessful tries to login to an account, upon which the account is locked/suspended,
temporarily. The account may be automatically released after a certain amount of time.
A.1.7 Previous logon notifications
Upon successful login, the user shall be notified about the time of her last login as
well as the number of failed login attempts since then.
A.1.8 Session control mechanisms
The system shall limit the number of concurrent sessions from a user account at
any point of time. It shall also enforce session timeouts after a certain time of inactivity
as well as session terminations incase the user is logged on remotely instead of the
organizational network.
A.1.9 Remote access
46
There shall be a policy to govern remote access to the system, such as when a user
accesses the system from external or insecure public networks that are not controlled by
the organization.
A.1.10 Permitted actions without authentication
The system shall present only a subset of the application details and features to an
unauthenticated or unidentified user.
A.2 Audit and Accountability
The system administrators shall determine the events that require auditing and
abstraction levels for the audit logs along with allocating sufficient storage space for the
predetermined period of retention. It is also essential for mechanisms to monitor, analyze
and report suspicious activities based on the audit logs to be in place. The entire audit
mechanism shall be isolated to prevent conflict of interests as well as unauthorized
access, modification and deletion of the audit trail. These mechanisms are necessary to
monitor and detect security events such as information leakage of rules/data and policy
overlaps for legitimate users of AtlanticWave SDX.
A.3 System Maintenance
There shall be a mechanism in place to ensure periodic system maintenance such as
installation of latest security patches released by vendors of the technologies deployed in
AtlanticWave SDX such as Python Flask, RHEL 6 virtual system and Shibboleth.
Maintenance personnel, the authorizations that they require, and the agreed response time
based on the severity of the patch shall be included in this procedure. There shall be an
appropriate notification procedure to identify the maintenance personnel, date and time of
the maintenance, its description as well as the impact and outage window, if any. In case
47
the maintenance is performed remotely, an extra layer of controls shall be regarded, such
as encryption of the communication channels, authentication, auditing of remote sessions
and remote session termination confirmation.
A.4 Security Engineering
A.4.1 Isolation
As a best practice, the security function shall be isolated from the rest of the
system by way of partitions, domains, etc. to ensure the integrity of the software and
hardware involved in implementing security for the system. The system shall also
implement isolation of user and management interfaces for example, a public web page
as opposed to the backend database.
A.4.2 Boundary protection
Perimeter security shall be put in place at interfaces that connect to external
networks by means of firewalls, proxies, intrusion detection and prevention systems. The
system shall also be able to resist and protect to a degree against denial of service attacks
by performing packet filtering, managing bandwidth and employing redundancy.
A.4.3 Cryptography
Integrity and confidentiality of the data at both rest and in motion shall be ensured
by way means of widely accepted cryptographic schemes. This includes obtaining PKI
certificates from a trusted authority and secure key distribution and management.
A.4.3 Secure Development
48
Secure coding practices shall be followed while developing the system
functionalities, such as performing input validation, restricting the usage of mobile code
technologies such as Java, JavaScript, ActiveX, Flash, VBScript and the like and testing.
A.5 Vulnerability Management
There shall be a plan in place to conduct periodic vulnerability assessments on the
system using appropriate scanning tools and techniques such as fuzzing. The personnel
responsible for conducting this task shall be identified. The results of this activity shall be
disseminated as appropriate and the findings shall be mitigated in a timely manner, based
on the severity of the risk.
A.6 Incident Management
An incident response policy and procedure shall be in place that identifies
procedures for security incident monitoring, handling, reporting, testing and assisting
users [Appendix II].
A.7 Contingency Planning
There shall be a contingency plan in place incase situations of disruption and
failure are encountered. This shall include appropriate training for involved personnel,
test drills, provisions for backup and processing as well as system recovery.
A.8 Identification and Authentication
Appropriate mechanisms to enforce user authentication shall be in place. These
include but are not limited to passwords, tokens, biometrics or a combination of two or
more of these in case of multifactor authentication. The authentication mechanism shall
apply to both local and remote system access. Similarly, devices used to connect and
49
access the system from shall be authenticated over the local and/or wireless network
using known protocols or organizational solutions.
The management of authenticators themselves naturally follows. These include but
are not limited to tokens, PKI certificates, passwords, and biometrics. In case of
password-based authentication:
i) the password shall not be displayed on the screen while the user types it;
ii) restrictions shall be placed on its reuse and lifetime;
iii) unauthorized disclosure and/or modification of the password shall be prevented
during transit and storage.
In case of PKI-based authentication:
i) certificate validation shall be undertaken by establishing connection with a trusted
authority;
ii) private key handling shall be undertaken by the system as appropriate.
50
APPENDIX B. SAMPLE OF INCIDENT SEVERITY CATEGORIES
AND RATINGS
Severity and Category Definitions Severity
Severe business impact to system with one or more of the following:
oSystem’s ability to deliver its mission objectives is affected
oSevere and extended disruptions (DDoS)
oCompromise of the confidentiality of system’s sensitive
information
oUnauthorized access to critical components of the system
oCreation / compromise of user accounts with system
administrator/domain access
oSpreading of malicious activity rapidly to other domains
(>10% infection rate over an hour)
3 -
CRITICAL
Limited business impact contained within a specific domain /
functionality, with one or more of the following:
oService level is expected to deteriorate
oSome security risk to the system
oUnauthorized access to non-critical components of the
system
oDegraded operations and service levels but still processing
or providing some service
oAble to maintain (functional) acceptable levels of customer
service, but business is beginning to become impacted
oMalicious activity is spreading in a restricted way across the
domains (<10% infection over an hour)
2 - MEDIUM
Limited impact with one or more of the following: 1 – LOW
51
oA threat has been discovered by system administrator
oUser reports an issue on the system
Reconnaissance or intelligence collected stating an attack may occur
in the future:
oRoutine operations
oSecurity administrator monitoring all event sources for alerts
and early signs of threats
0 - RECON
52
APPENDIX C. SAMPLE OF RESPONSE TIMES BASED ON
SEVERITY
Severity Response Time
3 - CRITICAL 45 minutes
2 - MEDIUM 2 hours
0/1 – LOW 4 hours
53
REFERENCES
[1] J. Chung, H. Owen, and R. Clark, “SDX Architectures: A Qualitative Analysis,” in
Proceedings of the 2016 IEEE conference, 2016, pp. 1-8.
[2] A. Gupta, L. Vanbever, M. Shahbaz, S. P. Donovan, B. Schlinker, N. Feamster, J.
Rexford, S. Shenker, R. Clark, and E. Katz-Bassett, “Sdx: A software defined
internet exchange,” in Proceedings of the 2014 ACM conference on SIGCOMM.
ACM, 2014, pp. 551–562.
[3] J. Stringer, D. Pemberton, Q. Fu, C. Lorier, R. Nelson, J. Bailey, C. N. Correa, C.
Esteve Rothenberg et al., “Cardigan: SDN Distributed Routing Fabric Going Live At
An Internet Exchange,” in Computers and Communication (ISCC), 2014 IEEE
Symposium on. IEEE, 2014, pp. 1–7.
[4] G. Carrozzo et. al., “Implementation of the FELIX SDN Experimental Facility”, in
2015 Fourth European Workshop on Software Defined Networks (EWSDN), 2015,
pp 1-6.
[5] P. Lin, J. Hart, U. Krishnaswamy, T. Murakami, M. Kobayashi, A. Al-Shabibi, K.
Wang, and J. Bi, “Seamless Interworking of SDN and IP”, in SIGCOMM '13
Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, 2013, pp
475-476.
[6] J. Bailey, D. Pemberton, A. Linton, C. Pelsser, and R. Bush, “Enforcing RPKI-based
Routing Policy on the Data Plane at an Internet Exchange,” in Proceedings of the
Third Workshop on Hot topics in Software Defined Networking. ACM, 2014, pp.
211–212.
[7] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide, B. Lantz, B.
O’Connor, P. Radoslavov, W. Snow, and G. Parulkar, “Onos: Towards An Open,
Distributed SDN OS,” in Proceedings of the Third Workshop on Hot Topics in
Software Defined Networking, ser. HotSDN ’14. New York, NY, USA: ACM, 2014,
pp. 1–6.
[8] J. Mambretti, J. Chen, and F. Yeh, “Software-defined Network Exchanges (SDXs):
Architecture, Services, Capabilities, and Foundation Technologies,” in Teletraffic
Congress (ITC), 2014 26th International. IEEE, 2014, pp. 1–6.
54
[9] K. Benton, L. J. Camp, and C. Small, “Openflow Vulnerability Assessment,” in
HotSDN '13 Proceedings of the second ACM SIGCOMM Workshop on Hot topics
in Software Defined Networking, 2013, pp. 151-152.
[10] S. Matsumoto, S. Hitz, A. Perrig, “Fleet: Defending SDNs from Malicious
Administrators”, in HotSDN '14 Proceedings of the third Workshop on Hot topics in
Software Defined Networking, 2014, pp. 103-108.
[11] V. Welch, T. Barton, K. Keahey, and F. Siebenlist, “Attributes, Anonymity, and
Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration”, in 4th
Annual PKI R&D Workshop, 2005.
[12] M. Chiesa, D. Demmler, M. Canini, M. Schapira, and T. Schneider, “Towards
Securing Internet eXchange Points Against Curious onlooKers”, in Applied
Networking Research Workshop (ANRW’16), 2016, pp 1-3.
[13] C. Yoon, and S. Lee, “Attacking SDN Infrastructure: Are We Ready for the Next-
Gen Networking?”, in BlackHat USA 2016, 2016, pp 1-28.
[14] President’s National Security Telecommunications Advisory Committee,
“Vulnerabilities Task Force Report: Internet Peering Security”, 2003, pp 1-12.
[15] Internet Society, “Promoting the use of Internet Exchange Points”, 2012, pp 1-26.
[16] T. Farley, P. McDaniel, K. Butler, and J. Rexford, “A Survey of BGP Security Issues
and Solutions”, in Proceedings of the IEEE, Vol. 98, 2010, pp 100-122.
[17] P. Kampanakis, H. Perros, and T. Beyene, “SDN-based Solutions for Moving Target
Defense Network Protection”, in 2014 IEEE 15th International Symposium on a
World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2014, pp 1-6.
[18] J.D. Meier, A. Mackman, M. Dunner, S. Vasireddy, R. Escamilla and A. Murukan,
“Improving Web Application Security: Threats and Countermeasures”, Ch. 3, June
2003
[19] P. Kamal, S. Mustafiz, F. Rahman, and R. Taher, “Evaluating the efficiency and
Effectiveness of a Federated SSO Environment Using Shibboleth”, in Journal of
Information Security, 2015, pp 166-178.
55
[20] http://www.networkcomputing.com/networking/bgp-security-no-quick-
fix/1303232068
[21] http://www.opensecurityarchitecture.org/cms/19-foundations/foundations/1-open-
security-architecture
[22] L. Wang, and D. Wu, “Moving Target Defense Against Network Reconnaissance
with Software Defined Networking”, in International Conference in Information
Security, 2016, pp 203-217.
[23] https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
[24] https://governmenttechnology.blog.gov.uk/2014/06/24/identity-and-access-
management/
[25] http://www.internet2.edu/products-services/trust-identity/shibboleth/
[26] http://shibboleth.net/about/basic.html
[27] https://sites.google.com/site/openidreview/issues
[28] https://apereo.github.io/cas/4.2.x/planning/Architecture.html
[29] http://wiki.ivoa.net/internal/IVOA/IvoaGridAndWebServices/shibboleth-review-
v0.1.html
[30] https://kb.iu.edu/d/bdaf
[31] http://trscavo.blogspot.com/2004/10/shibboleth.html
[32] https://www.incommon.org/federation/basics.html
[33] https://web.nvd.nist.gov/
[34] http://www.internet2.edu/products-services/trust-identity/grouper/
56
[35] http://www.internet2.edu/products-services/trust-identity/comanage/
[36] http://www.nytimes.com/2015/11/08/sunday-review/the-cyberthreat-under-the-
street.html?_r=0
57