these slides contains information security contents related to the authentication application, Authentication and Access Control and ACLs

1. Information Security
Authentication Applications, Authorization and Access Controls, ACLs

2. 1. KERBEROS
• Kerberos provides a centralized authentication server whose function
is to authenticate users to servers and servers to users. Kerberos
relies exclusively on conventional encryption, making no use of
public-key encryption.
•

3. 1. KERBEROS
• The following are the requirements for Kerberos:
Secure: A network eavesdropper should not be able to obtain the necessary
information to impersonate a user. More generally, Kerberos should be
strong enough that a potential opponent does not find it to be the weak link.
Reliable: For all services that rely on Kerberos for access control, lack of
availability of the Kerberos service means lack of availability of the supported
services. Hence, Kerberos should be highly reliable and should employ a
distributed server architecture, with one system able to back up another.

4. Transparent: Ideally, the user should not be aware that authentication
is taking place, beyond the requirement to enter a password.
Scalable: The system should be capable of supporting large numbers of
clients and servers. This suggests a modular, distributed architecture.
To support these requirements, the overall scheme of Kerberos is that
of a trusted third-party authentication service that uses a protocol
based on that proposed by Needham and Schroeder [NEED78] It is
trusted in the sense that clients and servers trust Kerberos to mediate
their mutual authentication. Assuming the Kerberos protocol is well
designed, then the authentication service is secure if the Kerberos
server itself is secure.

5. A Simple
Authentication
Dialogue

8. A Simple
Authentication
Dialogue

9. Authorization and Access Control
• Access control mechanisms are a necessary and crucial design
element to any application's security. In general, a web application
should protect front-end and back-end data and system resources by
implementing access control restrictions on what users can do, which
resources they have access to, and what functions they are allowed to
perform on the data. Ideally, an access control scheme should protect
against the unauthorized viewing, modification, or copying of data.
Additionally, access control mechanisms can also help limit malicious
code execution, or unauthorized actions through an attacker
exploiting infrastructure dependencies (DNS server, ACE server, etc.).

10. Authorization and Access Control
• Authorization and Access Control are terms often mistakenly
interchanged. Authorization is the act of checking to see if a user has
the proper permission to access a particular file or perform a
particular action, assuming that user has successfully authenticated
himself. Authorization is very much credential focused and dependent
on specific rules and access control lists preset by the web application
administrator(s) or data owners. Typical authorization checks involve
querying for membership in a particular user group, possession of a
particular clearance, or looking for that user on a resource's approved
access control list, akin to a bouncer at an exclusive nightclub. Any
access control mechanism is clearly dependent on effective and forge-
resistant authentication controls used for authorization.

11. Authorization and Access Control
• Access Control refers to the much more general way of controlling
access to web resources, including restrictions based on things like
the time of day, the IP address of the HTTP client browser, the domain
of the HTTP client browser, the type of encryption the HTTP client can
support, number of times the user has authenticated that day, the
possession of any number of types of hardware/software tokens, or
any other derived variables that can be extracted or calculated easily.

12. • Before choosing the access control mechanisms specific to your web
application, several preparatory steps can help expedite and clarify the
design process;
1: Try to quantify the relative value of information to be protected in terms
of Confidentiality, Sensitivity, Classification, Privacy, and Integrity related to
the organization as well as the individual users. Consider the worst case
financial loss that unauthorized disclosure, modification, or denial of service
of the information could cause. Designing elaborate and inconvenient access
controls around unclassified or non-sensitive data can be counterproductive
to the ultimate goal or purpose of the web application.

13. Authorization and Access Control
2: Determine the relative interaction that data owners and creators will
have within the web application. Some applications may restrict any
and all creation or ownership of data to anyone but the administrative
or built-in system users. Are specific roles required to further codify the
interactions between different types of users and administrators?
3: Specify the process for granting and revoking user access control
rights on the system, whether it be a manual process, automatic upon
registration or account creation, or through an administrative front-end
tool.

14. Authorization and Access Control
4: Clearly delineate the types of role driven functions the application will
support. Try to determine which specific user functions should be built into
the web application (logging in, viewing their information, modifying their
information, sending a help request, etc.) as well as administrative functions
(changing passwords, viewing any users data, performing maintenance on
the application, viewing transaction logs, etc.).
5: Try to align your access control mechanisms as closely as possible to your
organization's security policy. Many things from the policy can map very well
over to the implementation side of access control (acceptable time of day of
certain data access, types of users allowed to see certain data or perform
certain tasks, etc.). These types of mappings usually work the best with Role
Based Access Control.

15. Discretionary Access Control
• Discretionary Access Control (DAC) is a means of restricting access to
information based on the identity of users and/or membership in
certain groups. Access decisions are typically based on the
authorizations granted to a user based on the credentials he
presented at the time of authentication (user name, password,
hardware/software token, etc.). In most typical DAC models, the
owner of information or any resource is able to change its
permissions at his discretion (thus the name). DAC has the drawback
of the administrators not being able to centrally manage these
permissions on files/information stored on the web server. A DAC
access control model often exhibits one or more of the following
attributes.

16. Discretionary Access Control
1: Data Owners can transfer ownership of information to other users
2: Data Owners can determine the type of access given to other users (read,
write, copy, etc.)
3: Repetitive authorization failures to access the same resource or object
generates an alarm and/or restricts the user's access
4: Special add-on or plug-in software required to apply to an HTTP client to
prevent indiscriminant copying by users ("cutting and pasting" of
information)
5: Users who do not have access to information should not be able to
determine its characteristics (file size, file name, directory path, etc.)
6: Access to information is determined based on authorizations to access
control lists based on user identifier and group membership.

17. Access-Lists (ACL)
• Access-list (ACL) is a set of rules defined for controlling the network traffic
and reducing network attack. ACLs are used to filter traffic based on the set
of rules defined for the incoming or out going of the network.
• ACL features –
• The set of rules defined are matched serial wise i.e matching starts with
the first line, then 2nd, then 3rd and so on.
• The packets are matched only until it matches the rule. Once a rule is
matched then no further comparison takes place and that rule will be
performed.
• There is an implicit deny at the end of every ACL, i.e., if no condition or rule
matches then the packet will be discarded.

18. Access-Lists (ACL)
• Once the access-list is built, then it should be applied to inbound or
outbound of the interface:
• Inbound access lists – When an access list is applied on inbound
packets of the interface then first the packets will processed
according to the access list and then routed to the outbound
interface.
• Outbound access lists – When an access list is applied on outbound
packets of the interface then first the packet will be routed and then
processed at the outbound interface.

19. Types of ACL –
There are two main different types of Access-list namely:
• Standard Access-list – These are the Access-list which are made using the
source IP address only. These ACLs permit or deny the entire protocol suite.
They don’t distinguish between the IP traffic such as TCP, UDP, Https etc. By
using numbers 1-99 or 1300-1999, router will understand it as a standard
ACL and the specified address as source IP address.
• Extended Access-list – These are the ACL which uses both source and
destination IP address. In these type of ACL, we can also mention which IP
traffic should be allowed or denied. These use range 100-199 and 2000-
2699.

20. Categories of access list
• Also there are two categories of access list:
• Numbered access list – These are the access list which cannot be
deleted specifically once created i.e if we want to remove any rule
from an Access-list then this is not permitted in the case of numbered
access list. If we try to delete a rule from access list then the whole
access list will be deleted. The numbered access list can be used with
both standard and extended access list.
• Named access list – In these type of access list, a name is assigned to
identify an access list. It is allowed to delete a named access list unlike
numbered access list. Like numbered access list, these can be used
with both standard and extended access list.

21. Rules for ACL –
1: The standard Access-list is generally applied close to the destination (but not always).
2: The extended Access-list is generally applied close to the source (but not always).
3: We can assign only one ACL per interface per protocol per direction, i.e., only one
inbound and outbound ACL is permitted per interface.
4: We can’t remove a rule from an Access-list if we are using numbered Access-list. If we
try to remove a rule then whole ACL will be removed. If we are using named access lists
then we can delete a specific rule.
5: Every new rule which is added into the access list will be placed at the bottom of the
access list therefore before implementing the access lists, analyses the whole scenario
carefully.
6: As there is an implicit deny at the end of every access list, we should have at least a
permit statement in our Access-list otherwise all traffic will be denied.
7: Standard access lists and extended access lists cannot have the same name.

22. Advantages of ACL –
• Improve network performance.
• Provides security as administrator can configure the access list
according to the needs and deny the unwanted packets from entering
the network.
• Provides control over the traffic as it can permit or deny according to
the need of network.
•