[RESOLVED] kerberos
Results 1 to 6 of 6

Thread: [RESOLVED] kerberos

  1. #1
    Join Date
    Apr 2005
    Posts
    551

    Resolved [RESOLVED] kerberos

    can someone please expain exactly what kerberos does? it is a security protocol yes? to validate logins. but if i know a users password i can still validate as that user to gain access to their files. so to me this makes no difference to the standard challenge response apart from kerberos's mutual authentication.
    Is that right or am i way off?

    Also, is it transparant to the user? from what i have read it seems that the user has to call the admin and get permission to logon but surely that cant be right?

    thanks
    SANITY IS JUST A STATE OF MIND

  2. #2
    Join Date
    Apr 2005
    Location
    Maryland, USA
    Posts
    17,806

  3. #3
    Join Date
    Apr 2005
    Posts
    551
    "An authentication protocol in which a trusted third party, an arbitrator, is relied upon to perform the authentication of clients on a TCP/IP network."

    This is what i dont get. is the trusted third party a person or protocol?
    SANITY IS JUST A STATE OF MIND

  4. #4
    Join Date
    Apr 2005
    Location
    Maryland, USA
    Posts
    17,806
    Does this help?

    http://www.isi.edu/~brian/security/kerberos.html
    The Basics of Kerberos

    Kerberos's fundamental approach is to create a service whose sole purpose is to authenticate. The reason for doing this is that it frees other services from having to maintain their own user account records. The lynchpin to this approach is that both user and service implicitly trust the Kerberos authentication server (AS); the AS thus serves as an introducer for them. In order for this to work, both the user and the service must have a shared secret key registered with the AS; such keys are typically called long-term keys, since they last for weeks or months.

    There are three basic steps involved in authenticating a user to an end service. First, the user sends a request to the AS, asking it to authenticate him to the service. Fundamentally, this request consists only of the service's name, although in practice, it contains some other information that we don't have to concern ourselves with here.

    In the second step, the AS prepares to introduce the user and the service to each other. It does this by generating a new, random secret key that will be shared only by the user and the service. It sends the user a two-part message. One part contains the random key along with the service's name, encrypted with the user's long-term key; the other part contains that same random key along with the user's name, encrypted with the service's long-term key. In Kerberos parlance, the former message is often called the user's credentials, the latter message is called the ticket, and the random key is called the session key.

    At this stage, only the user knows the session key (provided he really is the user and knows the appropriate long-term key). He generates a fresh message, such as a timestamp, and encrypts it with the session key. This message is called the authenticator. He sends the authenticator, along with the ticket, to the service. The service decrypts the ticket with its long-term key, recovers the session key, which is in turn used to decrypt the authenticator. The service trusts the AS, so it knows that only the legitimate user could have created such an authenticator. This completes the authentication of the user to the service.

  5. #5
    Join Date
    Apr 2005
    Posts
    551
    thank you very much. thats what i needed.
    SANITY IS JUST A STATE OF MIND

  6. #6
    Join Date
    Apr 2005
    Location
    Maryland, USA
    Posts
    17,806

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •