Podstrony

• Index
• Cisco IP Routing Fundamentals
• Tcp Ip Biblia Pl (Helion)
• IBM TCP IP tutorial
• Benioff Dav
• Zimmer Bradley Marion Dom swiatow (2)
• Heisenberg Werner Carl Fizyka a filozofia
• Kazantzakis Nikos Ostatnie kuszenie Chrystusa (SC
• Michał Huzarski Taktyka ogólna wojsk lądowych
• Eco Umberto Imie Rozy (2)
• sw. Jan Od Krzyza Dziela (3)
• zanotowane.pl
• doc.pisz.pl
• pdf.pisz.pl
• nie-szalona.pev.pl

[ Pobierz całość w formacie PDF ]
.Tickets are reusable.Every ticket has a lifetime, typically eight hours.After aticket has expired, you have to identify yourself to Kerberos again, enteringyour login name and password.Unlike a ticket, which can be reused, a new authenticator is required every timethe client initiates a new connection with a server.The authenticator carries atimestamp within it, and the authenticator expires a few minutes after it isissued.(This is the reason why clocks must be synchronized between clientsand servers.)A server should maintain a history of previous client requests for which thetimestamp in the authenticator is still valid.This way a server can rejectduplicate requests that could arise from a stolen ticket and authenticator.5.11.4 Kerberos Database ManagementKerberos needs a record for each user and service in its realm and each recordkeeps only the needed information as follows:Principal identifier (c,s)Private key for this principal (Kc,Ks)Date of expiration for this identityChapter 5.TCP/IP Security Overview 343 Date of the last modification in this recordIdentity of the principal who last modified this record (c,s)Maximum lifetime of tickets to be given to this principal (Lifetime)Attributes (unused)Implementation data (not visible externally)The private key field is enciphered using a master key so that removing thedatabase will not cause any problem as the master key is not in it.The entity responsible for managing this database is the Kerberos DatabaseManager (KDBM).There is only one KDBM in a realm, but it is possible to havemore than one Kerberos Key Distribution Server (KKDS), each one having a copyof the Kerberos database.This is done to improve availability and performance sothat the user can choose one in a group of KKDSs to send its request to.TheKKDS performs read-only operations, leaving the actualization to the KDBM, whichcopies the entire database a few times a day.This is done to simplify the operationusing a Kerberos protected protocol.This protocol is basically a mutualauthentication between KDBM and KKDS before a file transfer operation withcheckpoints and checksum.5.11.5 Kerberos Authorization ModelThe Kerberos Authentication Model permits only the service to verify the identity ofthe requester but it gives no information on whether the requester can use theservice or not.The Kerberos Authorization Model is based on the principle thateach service knows the user so that each one can maintain its own authorizationinformation.However, the Kerberos Authentication System could be extended byinformation and algorithms that could be used for authorization purposes.(This ismade easier in Version 5.Please see the next section.) The Kerberos could thencheck if a user/client is allowed to use a certain service.Obviously, both the client and the server applications must be able to handle theKerberos authentication process.That is, both the client and the server must bekerberized.5.11.6 Kerberos Version 5 EnhancementsKerberos Version 5 has a number of enhancements over Version 4.Some of theimportant ones are:Use of encryption has been separated into distinct program modules whichallows for supporting multiple encryption systems.Network addresses that appear in protocol messages are now tagged with atype and length field.This allows support of multiple network protocols.Message encoding is now described using the ASN.1 (Abstract Syntax Notation1) syntax in accordance with ISO standards 8824 and 8825.The Kerberos Version 5 ticket has an expanded format to support new features(for example, the inter-realm cooperation).As mentioned in 5.11.2,  Naming on page 340, the principal identifier naminghas changed.Inter-realm support has been enhanced.344 TCP/IP Tutorial and Technical Overview Authorization and accounting information can now be encrypted and transmittedinside a ticket in the authorization data field.This facilitates the extension ofthe authentication scheme to include an authorization scheme as well.A binding is provided for the Generic Security Service API (GSSAPI) to theKerberos Version 5 implementation.5.12 Remote Access Authentication ProtocolsRemote dial-in to the corporate intranet and to the Internet has made the remoteaccess server a very vital part of today's internetworking services.More and moremobile users are requiring access not only to central-site resources, but toinformation sources on the Internet.The widespread use of the Internet and thecorporate intranet has fueled the growth of remote access services and devices.There is an increasing demand for simplified connection to corporate networkresources from mobile computing devices such as a notebook computer, or apalmtop device for e-mail access.The emergence of remote access has caused significant development work in thearea of security.The AAA (triple A) security model has evolved in the industry toaddress the issues of remote access security.Authentication, authorization andaccounting answers the questions who, what, and when respectively.A briefdescription of each of the three As in the AAA security model is listed below:AuthenticationThis is the action of determining who a user (or entity) is.Authentication cantake many forms.Traditional authentication utilizes a name and a fixedpassword.Most computers work this way, However, fixed passwords havelimitations, mainly in the area of security.Many modern authenticationmechanisms utilize one-time passwords or a challenge-response query.Authentication generally takes place when the user first logs in to a machineor requests a service of it.AuthorizationThis is the action of determining what a user is allowed to do.Generallyauthentication precedes authorization, but again, this is not required.Anauthorization request may indicate that the user is not authenticated.(wedon't know who they are.) In this case it is up to the authorization agent todetermine if an unauthenticated user is allowed the services in question.Incurrent remote authentication protocols authorization does not merely provideyes or no answers, but it may also customize the service for the particularuser.AccountingThis is typically the third action after authentication and authorization.Butagain, neither authentication or authorization are required.Accounting is theaction of recording what a user is doing, and/or has done.In the distributed client/server security database model, a number ofcommunications servers, or clients, authenticate a dial-in user's identity through asingle, central database, or authentication server.The authentication server storesall information about users, their passwords and access privileges.Distributedsecurity provides a central location for authentication data that is more secure thanscattering the user information on different devices throughout a network.A singleauthentication server can support hundreds of communications servers, serving upChapter 5.TCP/IP Security Overview 345to tens of thousand of users.Communications servers can access anauthentication server locally or remotely over WAN connections.Several remote access vendors and the Internet Engineering Task Force (IETF)have been in the forefront of this remote access security effort, and the meanswhereby such security measures are standardized.Remote Authentication Dial InUser Service (RADIUS) and Terminal Access Controller Access Control System(TACACS) are two such cooperative ventures that have evolved out of the Internetstandardizing body and remote access vendors [ Pobierz całość w formacie PDF ]