DOCSLIB.ORG

Windows 2000 Kerberos Authentication

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Operating System Windows 2000 Kerberos Authentication White Paper Abstract The next generation of the Microsoft® Windows® operating system will adopt Kerberos as the default protocol for network authentication. An emerging standard, Kerberos provides a foundation for interoperability while enhancing the security of enterprise-wide network authentication. Windows 2000 implements Kerberos version 5 with extensions for public key authentication. The Kerberos client is implemented as a security provider through the Security Support Provider Interface. Initial authentication is integrated with the Winlogon single sign-on architecture. The Kerberos Key Distribution Center (KDC) is integrated with other Windows 2000 security services running on the domain controller and uses the domain’s Active Directory as its security account database. This white paper examines components of the protocol and provides detail on its implementation. © 1999 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft, Active Desktop, BackOffice, the BackOffice logo, MSN, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 0999 &217(176Ã ,1752'8&7,21 Authentication in Windows 2000 1 Benefits of Kerberos Authentication 1 Standards for Kerberos Authentication 2 Extensions to the Kerberos Protocol 3 29(59,(:Ã2)Ã7+(Ã.(5%(526Ã35272&2/ Basic Concepts 4 Authenticators 4 Key Distribution 6 Session Tickets 7 Ticket-Granting Tickets 9 Authentication Across Domain Boundaries 10 Subprotocols 11 AS Exchange 11 TGS Exchange 12 CS Exchange 13 Tickets 14 What Is in a Ticket 14 What Clients Know About Tickets 15 How the KDC Limits a Ticket’s Lifetime 15 What Happens When Tickets Expire 16 Renewable TGTs 16 Delegation of Authentication 17 Proxy Tickets 17 Forwarded Tickets 18 .(5%(526Ã&20321(176Ã,1Ã:,1'2:6Ã Key Distribution Center 19 Account Database 19 Kerberos Policy 20 Delegation of Authentication 21 Preauthentication Error! Bookmark not defined. Kerberos Security Support Provider 22 Credentials Cache 23 DNS Name Resolution 24 IP Transport 24 $87+25,=$7,21Ã'$7$ Access Control in Windows 2000 26 How the KDC Prepares Authorization Data 27 How Services Use Authorization Data 28 Why Authorization Data Is Signed 29 ,17(5$&7,9(Ã/2*21 The Logon Process 30 Password Logon 31 Smart Card Logon 33 Preauthentication Data 34 5(027(Ã/2*21 Security Support Provider Interface 35 Security Support Provider Negotiation 36 Example: Opening a File on a Remote Server 36 Negotiating a Security Support Provider 36 How the Client Initiates Authentication 37 How the Server Responds 37 Mutual Authentication 37 Example: Cross-Domain Authentication 38 ,17(523(5$%,/,7< Scenarios 41 For More Information 42 ,1752'8&7,21Ã This paper provides a technical introduction to how the Microsoft® Windows® 2000 operating system implements the Kerberos version 5 authentication protocol. The paper includes detailed explanations of important concepts, architectural elements, and features of Kerberos authentication. The first section, “Overview of the Kerberos Protocol,” is for anyone unfamiliar with Kerberos authentication. Following this introduction to the protocol are several sections with details of Microsoft’s implementation in Windows 2000. The paper concludes with a brief discussion of requirements for interoperability with other implementations. $XWKHQWLFDWLRQÃLQÃ:LQGRZVÃÃ Windows 2000 supports several protocols for verifying the identities of users who claim to have accounts on the system, including protocols for authenticating dial-up connections and protocols for authenticating external users who access the network over the Internet. But there are only two choices for network authentication within Windows 2000 domains: • Kerberos Version 5. The Kerberos version 5 authentication protocol is the default for network authentication on computers with Windows 2000. • Windows NT LAN Manager (NTLM). The NTLM protocol was the default for network authentication in the Windows NT® 4.0 operating system. It is retained in Windows 2000 for compatibility with downlevel clients and servers. NTLM is also used to authenticate logons to standalone computers with Windows 2000. Computers with Windows 3.11, Windows 95, Windows 98, or Windows NT 4.0 will use the NTLM protocol for network authentication in Windows 2000 domains. Computers running Windows 2000 will use NTLM when authenticating to servers with Windows NT 4.0 and when accessing resources in Windows NT 4.0 domains. But the protocol of choice in Windows 2000, when there is a choice, is Kerberos version 5. %HQHILWVÃRIÃ.HUEHURVÃ$XWKHQWLFDWLRQÃ The Kerberos protocol is more flexible and efficient than NTLM, and more secure. The benefits gained by using Kerberos authentication are: • More efficient authentication to servers. With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the server does not need to go to a domain controller. It can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server once and reuse them throughout a network logon session. • Mutual authentication. NTLM allows servers to verify the identities of their clients. It does not allow clients to verify a server’s identity, or one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. Parties at both ends of a network connection can know that the party on the other end is who it claims to be. Windows 2000 White Paper 1 • Delegated authentication. Windows services impersonate clients when accessing resources on their behalf. In many cases, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and Kerberos provide the information that a service needs to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when connecting to back-end services on other computers. The Kerberos protocol has a proxy mechanism that allows a service to impersonate its client when connecting to other services. No equivalent is available with NTLM. • Simplified trust management. One of the benefits of the Kerberos protocol is that trust between the security authorities for Windows 2000 domains is by default two-way and transitive. Networks with multiple domains no longer require a complex web of explicit, point-to-point trust relationships. Instead, the many domains of a large network can be organized in a tree of transitive, mutual trust. Credentials issued by the security authority for any domain are accepted everywhere in the tree. If the network includes more than one tree, credentials issued by a domain in any tree are accepted throughout the forest. • Interoperability. Microsoft’s implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows 2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication. 6WDQGDUGVÃIRUÃ.HUEHURVÃ$XWKHQWLFDWLRQÃ The Kerberos protocol originated at MIT more than a decade ago, where it was developed by engineers working on Project Athena.1 The first public release of the protocol was Kerberos version 4. Following wide industry review of the protocol, its authors developed and released Kerberos version 5. That version is now on a standards track with the IETF. The implementation of the protocol in Windows 2000 closely follows the specification defined in Internet RFC 1510.2 In addition, the mechanism and format for passing security tokens in Kerberos messages follows the specification defined in Internet RFC 1964.3 1 Miller, S., Neuman, C., Schiller, J., and J. Saltzer, “Section E.2.1: Kerberos Authentication and Authorization System,” MIT Project Athena, Cambridge, MA, December 1987. 2 Kohl, J., and C. Neuman, “The Kerberos Network Authentication Service (V5),” RFC 1510, September 1993. 3 Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” RFC 1964, June 1996. Windows 2000 White Paper 2 ([WHQVLRQVÃWRÃWKHÃ.HUEHURVÃ3URWRFROÃ Windows 2000 implements extensions to the Kerberos protocol that permit initial authentication using public key certificates rather than conventional shared secret keys. This enhancement allows the protocol to support interactive logon with a smart card. The extensions for public key authentication are based on a draft specification submitted to the IETF working group by a number of third parties with interests in public key technology.4 Microsoft is participating in the standards
Recommended publications
  • Glossary.Pdf

    Glossary.Pdf

    Glossary Note: Terms in italics are described in their own glossary entries. 3DES. See Data Encryption Standard. A A RR. Type identifier for a DNS Address resource record. Active Directory (AD). The directory service for Windows 2000. A hierarchical, object-oriented database that stores distributed data for Windows 2000 domains, trees, and forests. Active Directory-integrated zones. DNS zones for which zone data are stored in Active Directory. All copies of an Active Directory-integrated zone are peers and can accept changes to the zone. Zone data are replicated through Active Directory. Zone transfers are required only when importing data from a primary zone or exporting data to a secondary zone. AD. Abbreviation for Active Directory. address class. See IP address class. address resolution protocol (ARP). A protocol used by IP to discover the hardware address of the device to which a datagram is being sent. Address resource record. A DNS resource record that maps a FQDN to an IP address. Referred to as Host resource records when administering Windows 2000 DNS. Referred to as Host Address resource records in this book. AH. See authentication header. ARP. See address resolution protocol. asymmetric cryptography. A cryptography method that uses one key for encryption and another key for decryption. Also called public key cryptography. attribute. A characteristic of an object in an object- oriented database such as Active Directory; often called a property in Windows 2000. authentication. The ability of one entity to reliably determine the identity of another entity. authentication header (AH). A security protocol used by IPSec that provides authentication and message integrity.
  • National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme

    National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme

    National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Common Criteria Evaluation and Validation Scheme Validation Report Nexor MMHS Security Report Number: CCEVS-VR-05-0095 Dated: 14 March 2005 National Institute of Standards and Technology National Security Agency Information Technology Laboratory Information Assurance Directorate 100 Bureau Drive 9800 Savage Road STE 6740 Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6740 Nexor MMHS Security Validation Report ACKNOWLEDGEMENTS Validation Team Dr. Jerome Myers The Aerospace Corporation Columbia, Maryland Common Criteria Testing Laboratory Science Applications International Corporation Common Criteria Testing Laboratory 7125 Columbia Gateway Drive, Suite 300 Columbia, Maryland 21046 2 Nexor MMHS Security Validation Report Table of Contents 1 EXECUTIVE SUMMARY____________________________________________ 4 2 Identification ______________________________________________________ 5 3 Security Policy _____________________________________________________ 7 3.1 Communications Policy _______________________________________________ 7 3.2 User Data Protection Policy ____________________________________________ 7 3.3 Identification and Authentication Policy _________________________________ 8 3.4 Management Policy___________________________________________________ 8 4 Assumptions and Clarification of Scope_________________________________ 9 4.1 Usage Assumptions ___________________________________________________ 9 4.2 Clarification of Scope _________________________________________________
  • Centralised Authentication

    Centralised Authentication

    Centralised Authentication Fabian Alenius Guerreiro Jo~ao Uwe Bauknecht March 3, 2009 Contents 1 Introduction 2 2 LDAP 3 2.1 History of LDAP . 3 2.2 Directory servers . 3 2.3 Distinguished Names . 3 2.4 Directory Information Trees . 3 2.5 LDAP Authentication . 4 2.6 SASL binding . 4 3 Authentication Methods [5] 5 3.1 Kerberos . 5 3.1.1 Protocol draft 1.0 . 5 3.1.2 Analysis of Protocol draft 1.0 . 6 3.1.3 Protocol draft 2.0 . 6 3.1.4 Analysis of Protocol draft 2.0 . 7 3.1.5 Kerberos Version 4 . 7 3.1.6 Kerberos Conclusion . 8 3.2 X.509 certificates . 8 4 RADIUS 9 4.1 Introduction . 9 4.2 Functionality . 9 4.2.1 Authentication and Authorization . 9 4.2.2 Accounting . 10 4.2.3 Realms and Proxies . 10 4.3 Usage . 10 References 11 1 1 Introduction When a user wants to login to a computer system he has to go through the process of authentication. If the same user wants to authenticate against two computer systems he needs to authenticate twice. This becomes unpractical very fast as the number of systems grow, especially if the user has to remember separate usernames and passwords for each system. Another problem with this is that the management of the user accounts becomes complicated as we need several user accounts for each user. So, if we for example want to remove one user completely, we need to update all our systems. The solution to this problem is to use a centralized authentication server.
  • Leveraging the Kerberos Credential Caching Mechanism for Faster Re-Authentications in Wireless Access Networks

    Leveraging the Kerberos Credential Caching Mechanism for Faster Re-Authentications in Wireless Access Networks

    UBICOMM 2010 : The Fourth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies EAP-Kerberos: Leveraging the Kerberos Credential Caching Mechanism for Faster Re-authentications in Wireless Access Networks Saber Zrelli Yoichi Shinoda Nobuo Okabe Center for Information Science Corporate R&D Headquarters Japan Advanced Institute of Science and Technology Yokogawa Electric Corporation Ishikawa, Japan Tokyo, Japan [email protected] saber.zrelli,[email protected] Abstract—Although the wireless technology nowadays provides support cross-domain authentication that enables an access satisfying bandwidth and higher speeds, it still lacks improve- network to authenticate a roaming client that belongs to a ments with regard to handoff performance. Existing solutions remote domain. The cross-domain authentication requires for reducing handoff delays are specific to a particular network technology or require expensive upgrades of the whole infras- message exchange between the AAA server of the visited tructure. In this paper, we investigate performance benefits of network and the AAA server of the roaming station’s home leveraging the Kerberos ticket cashing mechanism for achieving network. Because these inter-domain exchanges occur over the faster re-authentications in IEEE 802.11 wireless access networks. Internet, they are subject to degradations such as packet loss For this purpose, we designed a new EAP authentication method, and network delays which increases the overall authentication EAP-Kerberos, and evaluated re-authentication performance in different scenarios. time. When a roaming station changes of access point, the same authentication procedure takes place again, disrupting Keywords-Wireless; Authentication; Handoff; Performance the user traffic at each handoff. I.
  • A Kerberos-Based Authentication Architecture for Wireless Lans

    A Kerberos-Based Authentication Architecture for Wireless Lans

    A Kerberos-Based Authentication Architecture for Wireless LANs Mohamed Ali Kaafar1, Lamia Benazzouz1, Farouk Kamoun1, and Davor Males2 1 Ecole Nationale des Seiences de l'lnformatique, Universitt~ de la Manouba. Tunisia {Medali.kaafar, Lamia.benazzouz, Farouk.kamoun}@ensi.rnu.tn 2 Laboratoire d'lnformatique de Paris 6 Universite Pierreet Marie Curie 8, rue du capitaine Scott 75015 Paris. France [email protected] Abstract. This work addresses the issues re1ated to authentication in wireless LAN environments, with emphasis on the IEEE 802.11 standard. lt proposes an authentication architecture for Wireless networks. This architecture called Wireless Kerberos (W-Kerberos), is based on the Kerberos authentication server and the IEEE 802.1X-EAP mode1, in order to satisfy both security and mobility needs. lt then, provides a mean of protecting the network, assuring mutual authentication, thwarts cryptographic attack risks via a key refreshment mechanism and manages fast and secure Handovers between access points. 1 Introduction Over recent years, wire1ess communication has enjoyed enormous growth, becoming popular in botb public and private sectors. Wireless Local Area Network (WLAN) technology is capable of offering instant, high-speed and mobile connectivity. While this technology offers a Iot of advantages, it does also introduce issues related to authentication, access control, confidentiality and data integrity. Today, wireless products are being developed that do not address all of the security services related to this technology. Although the IEEE 802.lli framework is proposing a "Robust Security Nework" architecture (RSN) to deal with the security wireless networks limitations, actually there is not a complete set of standards available that solves all the issues related to Wireless security [1].
  • 1. Privacy and Security 1.1. User Identity Authentication

    1. Privacy and Security 1.1. User Identity Authentication

    VA Enterprise Design Patterns: 1. Privacy and Security 1.1. User Identity Authentication Office of Technology Strategies (TS) Architecture, Strategy, and Design (ASD) Office of Information and Technology (OI&T) Version 2.0 Date Issued: March 2016 THIS PAGE INTENTIONALLY LEFT BLANK FOR PRINTING PURPOSES APPROVAL COORDINATION ___________________________________________ Rodney Emery Director, Technology Strategies and GEAC, ASD ASD Technology Strategies ___________________________________________ Paul A. Tibbits, M.D. DCIO Architecture, Strategy, and Design REVISION HISTORY Version Date Organization Notes Initial Draft/Outline of the update to the Internal and External User Identity Authentication Design Patterns issued for stakeholder review. Combined Internal and External Authentication 1.5 February 2016 ASD TS Design Plan documents and updated the name. Changed format to provide future state relevant to all authentication, internal and then external. Added IAM Infrastructure Integrity Risk Assessment and Recommended Actions. Includes the additional updates: Added overview diagram. Updated As-Is state for SSOe and use of MVI. Updated Internal and External current state diagrams. Clarified goal of IAM to provide a single source to access all identities and attributes in use across VA. Added requirement to create LOA Assessment 1.7 March 2016 ASD TS Examples specific to VA for every level and provided draft example. Updated Direct Client Authentication using PKI over TLS to be a temporary solution until SSOi supports LOA 4. Updated Use Cases. Updated scope to specify exclusion of Compliance Audit and Reporting (CAR), VA Credential Service Provider (CSP), electronic signature (eSig) and identity proofing (IP). REVISION HISTORY APPROVALS Version Date Approver Role 2.0 3/10/2016 Joseph Brooks Privacy and Security Design Pattern Lead TABLE OF CONTENTS TABLE OF CONTENTS ..............................................................................................................................................
  • Extending Oauth2.0 for Kerberos-Like Authentication to Avoid Internet Phishing Attacks

    Extending Oauth2.0 for Kerberos-Like Authentication to Avoid Internet Phishing Attacks

    Anoop Vijayan Extending OAuth2.0 for Kerberos-like authentication to avoid Internet phishing attacks Master thesis in Mobile Technology and Business Faculty of Information Technology University of Jyvaskyla Department of Computer Science and Information Systems Author: Anoop Vijayan Contact Information: [email protected] Supervisor(s): Timo Hamäläinen Department of Computer Science and Information Systems University of Jyvaskyla Reviewer(s): Timo Hamäläinen Department of Computer Science and Information Systems University of Jyvaskyla Title: Extending OAuth2.0 for Kerberos-like authentication to avoid Internet phishing attacks Project: Master thesis in Mobile Technology and Business Page count: 72 I ABSTRACT The combined use of OpenID and OAuth for authentication and authorization is gaining popularity day by day in Internet. Because of its simplicity to understand, use and robustness, they are used in many domains in web, especially where the apps and user base are huge like social networking. Also it reduces the burden of typing the password every time for authentication and authorization especially in hand-held gadgets. After a simple problem scenario discussion, it is clear that the OpenID+OAuth combination has some drawbacks from the authentication perspective. The two major problems discussed here include problems caused due to transfer of user credentials over Internet and complexity in setting up of two protocols separately for authentication and authorization. Both the problems are addressed by extending OAuth2.0. By using Kerberos-like authentication, the user has the possibility of not passing the credentials over Internet. It is worth to note that, OAuth2.0 also uses some kind of tokens for authorizations similar to Kerberos.
  • MS-ADSO]: Active Directory System Overview

    MS-ADSO]: Active Directory System Overview

    [MS-ADSO]: Active Directory System Overview Intellectual Property Rights Notice for Open Specifications Documentation . Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL’s, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft Open Specification Promise or the Community Promise. If you would prefer a written license, or if the technologies described in the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected]. Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights.
  • IBM Tivoli Monitoring: Active Directory Agent: User™S Guide

    IBM Tivoli Monitoring: Active Directory Agent: User™S Guide

    ® Tivoli Monitoring: Active Directory Agent Version 6.2.0 User’s Guide SC32-9444-01 ® Tivoli Monitoring: Active Directory Agent Version 6.2.0 User’s Guide SC32-9444-01 Note Before using this information and the product it supports, read the information in “Notices” on page 121. This edition applies to version 6.2 of IBM Tivoli Monitoring: Active Directory Agent (product number 5724-C71) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2005, 2007. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. © Copyright International Business Machines Corporation 2007. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Tables . .v Chapter 5. Attributes reference . .21 About attributes . .21 Chapter 1. Overview of the Monitoring More information about attributes . .21 Attribute groups and attributes for the Monitoring Agent for Active Directory . .1 Agent for Active Directory . .21 IBM Tivoli Monitoring overview . .1 Address Book attributes . .22 Features of the Monitoring Agent for Active DHCP attributes . .23 Directory . .1 Directory Services attributes . .24 New in this release . .2 DNS_ADIntegrated attributes . .26 Monitoring Agent for Active Directory components .3 DNS attributes . .27 User interface options . .3 Domain Controller Availability attributes . .29 Domain Controller Performance attributes . .31 Chapter 2. Requirements for the Exchange Directory Services attributes . .32 monitoring agent . .5 File Replication Service attributes . .33 Running as a non-Administrator user . .7 Group Policy Object attributes . .34 Ping variables .
  • Active Directory Replication Model Works - Directory Services: Windows

    Active Directory Replication Model Works - Directory Services: Windows

    How the Active Directory Replication Model Works - Directory Services: Windows ... Pagina 1 di 25 How the Active Directory Replication Model Works In this section Active Directory Replication Model Architecture Active Directory Replication Model Physical Structure Active Directory Data Updates Domain Controller Notification of Changes Identifying and Locating Replication Partners Urgent Replication Network Ports Used by Active Directory Replication Related Information Active Directory data takes the form of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. The values of the attributes define the object, and a change to a value of an attribute must be transferred from the domain controller on which it occurs to every other domain controller that stores a replica of that object. Thus, Active Directory replicates directory data updates at the attribute level. In addition, updates from the same directory partition are replicated as a unit to the corresponding replica on the destination domain controller over the same connection to optimize network usage. The information in this section applies to organizations that are designing, deploying, or operating an Active Directory infrastructure that satisfies the following requirements: A Domain Name System (DNS) infrastructure is in place that manages the name resolution for domain controllers in the forest. Active Directory-integrated DNS is assumed, wherein DNS zone data is stored in Active Directory and is replicated to all domain controllers that are DNS servers. All Active Directory sites have local area network (LAN) connectivity. IP connectivity is available between all datacenter locations and branch sites.
  • Secure Fast Handover in an Open Broadband Access Network Using Kerberos-Style Tickets

    Secure Fast Handover in an Open Broadband Access Network Using Kerberos-Style Tickets

    Secure Fast Handover in an Open Broadband Access Network using Kerberos-style Tickets Martin Gilje Jaatun1, Inger Anne T¿ndel1, Fr¶ed¶ericPaint2, Tor Hjalmar Johannessen2, John Charles Francis3, and Claire Duranton4 1 SINTEF ICT, Trondheim, Norway 2 Telenor R&D, Fornebu, Norway 3 Swisscom Innovations, Bern, Switzerland 4 France Telecom R&D, Issy-les-Moulineaux, France [email protected] Abstract. In an Open Broadband Access Network consisting of multi- ple Internet Service Providers, delay due to multi-hop processing of au- thentication credentials is a major obstacle to fast handover between ac- cess points, e®ectively preventing delay-sensitive interactive applications such as Voice over IP. By exploiting existing trust relationships between service providers and access points, it is possible to pre-authenticate a mobile terminal to an access point, creating a Kerberos-style ticket that can be evaluated locally. The terminal can thus perform a handover and be authenticated to the new access point, without incurring communi- cation and processing delays by involving other servers. 1 Introduction The Open Broadband Access Network (OBAN) [1] seeks to utilise excess ca- pacity available in residential broadband connections, by opening up private wireless access points to passers-by. It is intended as a multi-ISP network, where a roaming OBAN user may consume mobile IP services from residential wireless access points regardless of whether or not he has a contract with the same ISP as the residential user. In addition to serving as a lower-cost, higher-bandwidth alternative to services such as UMTS [2] or WiMAX [3], OBAN also intends to incorporate multi-lateral roaming agreements [4] towards such services, in e®ect creating a ubiquitous, world-wide network.
  • A New a Kerberos Model

    A New a Kerberos Model

    Volume 2, Issue 3, March 2012 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com 3 A NEW A KERBEROS MODEL Aditya Harbola* Deepti Negi Deepak Harbola School of computing School of computing Department of computer science Graphic Era University, Graphic Era University, BCTKEC, Dehradun, UK Dehradun, UK Dwarahat, UK [email protected] [email protected] [email protected] Abstract – An internet service provider (ISPs) offers easy access to the network to meet the ever growing demand for business. The authenticated subscribers must be verified for access authorization and for cost recovery, billing and resource planning purpose. For all business services coordination between the various administrative system’s are required. This paper presents a new AAA Kerberos protocol for distributed systems. Traditional Kerberos authentication schemes do not meet distributed system requirements of authorization, failsafe operation, accounting of service usage and resilience to loss of connectivity. Our new AAA Kerberos protocol model meets the requirements of authentication, authorization and accounting. Keywords - Authentication, authorization, accounting, key management, control systems. INTRODUCTION end user's resource consumption, which can then be processed for billing, auditing, and capacity-planning purposes. A network is full of challenges and meeting these One of the requirements of AAA framework is a good challenges in a simplified and scalable manner lies at the heart price-to-performance ratio offering high-volume disk storage of authentication, authorization, and accounting. AAA and optimized database administration. A single AAA server essentially defines a framework for coordinating the challenges can act as a centralized administrative control point for multiple across multiple network technologies and platforms.