draft-latzko-aaa-authentication-reqs-00.txt A Latzko Rutgers University AAA Authentication Requirements and Discussion Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A common definition base for Authentication, Authorization and Accounting service in the internet is highly desirable if for growth in a common direction. It is possible for Accounting to stand alone if one is willing to trust what the other person says. Authentication is required if Authorization is to work. This documents is a discussion and flow trace of a basic authentication flow. Assumptions One assumption which is made here is there is a single client talking to a single server for each transaction. The server may be a relay to other servers which actually host the authentication data. A second assumption is state is only maintained for the length of the authentication transaction before being passed to the authorization server, which itself may be a co-process or not. The third assumption is authentication may be the end of the transaction with no further authorization, or accounting performed. Fourthly, no assumptions are made to the actual mechanism performing the transaction. Latzko expires December 1999 [Page 1] INTERNET DRAFT 24 June 1999 Security This is essentially a security service, however, the actual transaction security is beyond the realm of this document and refers to well known security techniques documented elsewhere. Transaction flow client sends request for authentication service: either as part of the request the client send a handshake request using a shared secret key so there is reasonable trust between the client and server. or as part of the request a symmetrical key exchange (diffie-hellman for example) will occur so there is reasonable trust between the client and server. server responds with one of three things 1>yes, I'll serve you and the transaction continues 2>no, I won't serve you, and the transaction stops 3>maybe, I don't know you, send me something meaningful If maybe, then after some configured timeout, you either try the handshake again or stop. The timeout prevents a denial- of-service attack. The authentication server will then send to the client a request for token(s).(1) Along with this may be a series of key phrase prompts or other fixed string information needed by the client. [After the initial handshake the client then sends to the authentication server the token(s) to be authenticated. Done earlier...see above.] The minimum the token(s) must contain is a unique identifier (principle string) for the person or service being authenticated. The initial token exchange may also contain the a pass phrase or other information derivable only be the client entity. Latzko expires December 1999 [Page 2] INTERNET DRAFT 24 June 1999 Depending on the severity level required the response from the authentication server will be: denied ( included token incorrect ) denied ( out of resource ( time, login slots, cpu, whatever) accepted ( the token contained unique identification such as tautology, a biometric string, or a pass phrase embedded in the initial token exchange ) accepted for further processing. At this point if a challenge/response method is being used the challenge will be sent. If a biometric is being used the biometric device (having passed the key exchange and being trusted) then the biometric will be prompted for if it wasn't sent. If after further processing (which may be an iterative process ) validity is determined, then an accept message will then be sent. Random thoughts of completion. The security of the authentication server is only as good as the security of the token. If someone steals your password, you're out of luck The back end database used in this memo is not specified since that's an implementation specific problem. All transactions between the client and server will be encrypted. [1] in this case, a token is defined as '1. a thing serving as a symbol, reminder, or distinctive mark of something' in the form of a string of octets. Authors Address Alex Latzko Rutgers University Computing Services 110 Freylinghuysen Road Piscataway, New Jersey 08854-8089 Telephone: 1 732 445 5021 Email: latzko@noc.rutgers.edu Latzko expires December 1999 [Page 3]