Principal Names and Key Distribution Center
Principal Names and Key Distribution CenterThe KDC uses a Principal Database (PD) to store the principal's information. The principal is identified by the principal name. The principal name consists of three parts to identify the principal: primary name , instance, and realm. The primary name is the client's name or service trying to access the server, such as rich or rcmd; the rcmd is a remote command. The instance is the current instance of the server specified in the Fully Qualified Name (FQN) form, or a special group that the user belongs to, such as root . For instance, in the FQN of security.richware.com , the server is security . The realm is the domain of the local Kerberos instance such as richware.com . The Key Distribution Center (KDC) is used to authenticate an identity. Once the identity is authenticated, it becomes a principal . In most cases Kerberos is used to authenticate the client to a server, or for mutual authentication. Mutual authentication is used to authenticate the client to the server and the server to the client. The authentication can be used on an open network, without depending on the operating system, relying on hardware devices, or using physical security involved in using special routers.
Differences between Kerberos v4 and v5There were many weaknesses in v4 of Kerberos. To make up for these issues, MIT started working on v5 in 1989. In 1993, v5 was developed and the specification was documented in RFC 1510. In this section, I describe the functionality of Kerberos and the difference between Kerberos versions 4 and 5, which include:
Modifications on encryption supportOne of the biggest issues with v4 was that it only implemented DES for encryption. The v5 uses the Generic Security Services Application Programming Interface (GSS-API) to support many encryption algorithms; v5 is a layer on top of GSS-API so that it may take advantage of everything that the GSS-API has to offer.
In addition, in Kerberos version 5, the ticket is updated to include a start date and end date for when the ticket is active. This is needed for scheduled clients to execute without human interaction at scheduled times. Modifications to the TGSAnother limitation of v4 was that everything was authenticated within the same realm, which meant that the user or client had to be local. In v5, the client can access many realms across the Internet; this is possible because TGS was modified to send and accept tickets to other TGSs. The principal can access a realm, which can communicate to another realm, which in turn can communicate with yet another realm, and so on, until the client's principal gets a ticket from the target service if the realm trusts the realm of the client's target realm. Modifications to the principal name representationIn v4, you have the primary name, the instance, and the realm name for the representation of a principal name. In v5, the principal name can append multiple names, such as rich/admin , so that instance is just a name appended to the first name. This gives the v5 format as multiple names and the realm. The format of the principal name, in v4, is name.instance@realm . For example, if name = rich , instance = admin and the realm = richware.com , then the principal name is rich.admin@richware.com . In this example, rich is the root user. Another principal name example is rcmd.security@richware.com , which is used to run the rcmd command in the rcmd server on richware.com . In Kerberos version 5, the principal takes on the form of name/name/domain so the above example becomes rich/admin/richware.com . Modifications to the TGS ticket request processWhen a user logs into a service that is protected by Kerberos, the user passes his principal's primary name as part of the input. The Kerberos client requests a ticket from the AS for access to a target service on a server. This TGS ticket has been modified to enhance some of the issues from version 4. Requesting the TGS Ticket in v4When the Kerberos client requests a ticket from the AS (to access a target service) the request that is being sent to the AS does not contain a password. The user's password is not exposed, but the principal's primary name is sent to the AS. This request also passes the TGS ID to request the ticket from the appropriate TGS and the timestamp of the ticket. This request is called the KRB_AS_REQ . The AS then looks up the principal from the PD. The password of the principal is used to encrypt the ticket's response stored in the PD. When an error happens, the KRB_ERROR message is sent to show that there is an error, otherwise the encrypted KRB_AS_REP message is sent as a response.  Figure 16-1: Kerberos messaging The KRB_AS_REP message will have a new randomly generated session key for temporary use from the client to the TGS. This message will contain the timestamp of the issue from the AS, the lifetime of the ticket, and the ticket to be used by the client to the TGS. When the client receives this ticket, the principal is prompted for its password, which is used to decrypt the KRB_AS_REP message. If the password doesn't decrypt the message, it is not considered a valid password. The principal's password from the PD is always the valid password. If the event decryption fails, the process may start again to get a valid decryption. After a valid decryption, the client now has an encrypted TGS ticket, a session key, and other information in the KRB_AS_REP . Figure 16-1 illustrates this Kerberos messaging.
Requesting the TGS ticket in v5One of the main differences between v4 and v5 is that v5 supports multiple realms outside the local realm. V5 also uses a start time and an end time for running jobs at a later time without human interaction. v5 passes messages the same way as v4; however, the structure of these messages is somewhat different since messages for v5 include the above-mentioned enhancements. In v5, just as in v4, a client logs in to the Kerberos client and transmits the principal's name and makes a request to the AS. v5 supports the principal's primary name, but it doesn't use the instance name; instead it treats regular names as instance names. Previously in the principal's primary name, the client might use rich.admin@richware.com , where admin is an instance name. In v5, the same principal name is rich/admin/richware.com , where the admin is a name of the group that rich belongs in. It is done this way because going across realms may need the support of a list of names. In v5 KRB_AS_REQ , the Kerberos AS request message contains the primary principal's name, the options , the client's realm, the times , and the nonce . The options are flags set to instruct the servers on what options are available in the protocol. The client uses the following flags to instruct the servers: The RENEWABLE-OK and ENC-TKT-IN-SKEY can set two flags. The RENEWABLE-OK option indicates that the client will accept a renewable ticket if a ticket with the requested life cannot otherwise be provided. If a ticket with the requested life cannot be provided, the KDC may issue a renewable ticket with a renew-till field equal to the requested end-time. The value of the renew-till field may still be adjusted by site-determined limits or limits imposed by the individual principal or server. The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service; it indicates that the to-be-issued ticket for the end server is to be encrypted in the session key from the additional ticket-granting ticket provided with the request. The times section contains the from-time (which is the desired start time of the target service), the till-time (which is end-time of the tickets), and the rtime (which requests the ticket renewal times). The nonce is a randomly generated number passed around the messages used to validate that no other client is trying to impersonate the source client. The return message from the AS has the INITIAL flag set to state that the message was returned from the AS protocol and not from the TGS. One of the reasons this flag is needed is because in v5, the AS can return the KRB_TGS_REP directly after a valid authentication. The PRE-AUTHENT and HW-AUTHENT flags provide additional information about the initial authentication; these flags are carried forward from the ticket-granting ticket. The PRE-AUTHENT flag indicates that during initial authentication, the client was authenticated by the KDC before the ticket was issued. The HW-AUTHENT indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. Figure 16-2 shows the v5 flags.  Figure 16-2: The v5 flags Modifications to the Service ticket request processAfter the client receives the TGS ticket from the AS, it must request the Service ticket from the TGS to access the target service. The client initiates this after decrypting the TGS ticket. Kerberos version 5 improves on the way version 4 requests the Service ticket. Requesting the Service ticket in v4When the client initiates the Service ticket request, it sends the KRB_TGS_REQ message, which contains the target service ID, the TGS ticket, and the client's authenticator. The client generates the authenticator with the client's ID, the client's address, and a new timestamp from the client. The authenticator is encrypted with the session key and is used to verify that the client, not an attacker, received the message. If the authenticator is ever reused, it will be rejected by the TGS. TGS then checks the timestamps to ensure that the session hasn't timed out. After checking the PD and verifying that the principal has access or permissions to the target server, the TGS replies with the KRB_TGS_REP response message if everything was successful; if there was an error, it responds with KRB_ERROR . The KRB_TGS_REP contains the new ticket for the target service encrypted by the service's password that was in the PD. Also, the KRB_TGS_REP has a new timestamp (generated by the TGS), the service's ID, and a random session key (generated by the TGS for the client and server to use when communicating). The message is encrypted in the previous session key for the client and TGS to communicate. Requesting the Service ticket in v5The v5 message operates similarly to the v4 message. Like v4, it includes an authenticator, a ticket, and the name of the requested service. The addition to version 5 includes the requested time and the nonce field mentioned in the previous message. In addition, the authenticator in v4 is very similar in v5; the flags are the difference again. One of the flags, the FORWARDABLE flag, is used by the TGS. When this flag is set, it tells the ticket-granting server that it is okay to issue a new ticket-granting ticket with a different network address based on the presented ticket. The FORWARDED flag is set by the TGS when the client sets the FORWARDABLE flag initially. When the FORWARDED flag is set, it indicates that the ticket has either been forwarded or was issued based on authentication involving a forwarded ticket-granting ticket. The PROXIABLE flag is another flag that is only interpreted by the TGS. This flag is similar to the FORWARDABLE flag, except that it tells the ticket-granting server that only non-ticket-granting tickets may be issued with the different network addresses. When the ticket is returned, the PROXY flag is set to state that the ticket is a proxy. One of the new features in v5 is the capability to set times beforehand for batch jobs. To implement this functionality, the client obtains tickets that will be used at a later time. By using the POSTDATED flag, the client can obtain these tickets at the job submission time and then leave them dormant for further validation at job execution time. The client issues the MAY-POSTDATE flag in the ticket to the TGS to tell the TGS that a postdated ticket may be issued based on this ticket-granting ticket. The TGS responds with the POSTDATED flag to indicate that the ticket has been postdated. The RENEWABLE flag may also be used to indicate that a ticket may be valid for a long period of time. However, keeping a ticket around longer can expose the credential to be broken for a longer period of time. When the RENEWABLE flag is set, the ticket contains two expiration times. The first is when the current instance of the ticket expires , and the second is the latest permissible time for the expiration. During the time, the ticket must occasionally renew itself to the KDC to stay active. If there are any issues with the ticket, it may set the INVALID flag stating that the ticket is INVALID and must be authenticated with the KDC again before use. Modifications to the client/server authentication processAfter the client receives the ticket to the target service, the client then needs to access the service. The client creates a new authenticator, and the authenticator is encrypted within the new session key for the client and service to use when communicating. Again, Kerberos version 5 improves on the authentication process of Kerberos version 4. Client/server authentication in v4The client sends the authenticator and the server's ticket in the form of a KRB_AP_REQ message. The server decrypts the ticket with its password and checks the authenticator to ensure that client matches for a validation. If the client requires mutual authentication, then one authentication is added to the timestamp and is encrypted with the session key of the client and server communication. If the client decrypts it and sees that an authentication was added to the timestamp, the server is also validated . If the client doesn't require mutual authentication, once the server authenticates the client, it gives the client access to its resources. Client/server authentication in v5Some of the features that have evolved over the years to improve the authentication protocol include the choice for authentication key. As mentioned before, v4 was limited to DES; in v5, the client has a choice for the type of authentication key. This field can be defaulted to the standard key. An optional sequence number may be used to keep track of the iteration of the message to avoid replay attacks. Modifications to ticketsThere are ticket changes between the two versions. This was done to address some of the issues that version 4 did not address. However, in both versions the ticket of the TGS is encrypted for security reasons. Tickets in v4The ticket of the TGS is encrypted with the TGS's password and contains the session key, the client's ID, the IP address of the client, the TGS's ID, the timestamp from the AS, and principal's lifetime that is specified in the PD. The TGS ticket contains the following fields:
These fields combined make up the ticket as:
The Key tgs means that the entire ticket is encrypted with the services' principal secret key. This ticket may be reused any number of times from the client as long as the lifetime is still active. The Service ticket is the same, except that now a ticket to the target server is also included with a session key encryption from the client to the server. The server ticket also includes identification to the client. Tickets in v5The ticket of the TGS is encrypted with the TGS's password and contains the session key, the flags, the IP address of the client, the realm of the client, and the times requested by the user. The TGS ticket fields contain the following:
These fields combined make up the ticket as:
The Key tgs means that the entire ticket is encrypted with the services' principal secret key. This ticket may be reused any number of times from the client as long as it falls within the times specified. The Service ticket is almost completely different. It includes a subkey for the encryption scheme, a sequence number to identify the message, the client identification, the timestamp, and the client realm. These fields are needed to change the realms and encryptions. Further security is added by specifying specific times of use and sequence numbers to avoid replay attacks.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
