Contents


Configure an IPsec environment using the Kerberos authentication mechanism

Effectively managing Keberos authentication between a set of IBM AIX systems using the IPsec protocol

Comments

Kerberos introduction

Kerberos is one of the user authentication protocols which works on a ticketing mechanism with symmetric encryption. In IBM® AIX®, the Kerberos protocol is provided through Network Authentication Service. So, in this article we will be using Kerberos and network authentication service interchangeably.

From a high level, Kerberos authentication works on the client/server model with a client contacting the server to obtain tickets. Here, the client can either be a user or a service (for example: Telnet, FTP, SSH, IPsec and so on). The following two types of tickets get exchanged between the server and the client during the process of Kerberos authentication:

  • Ticket granting ticket (TGT)
  • Service ticket

In Kerberos, the user or the service to be authenticated is known as the principal.

The server, more commonly known as the key distribution center (KDC), contains the private keys of all principals within its network. This server contains two parts: Authentication server and ticket-granting server. You can note that when the Network Authentication Service server is configured, a daemon (krb5kdc) starts running. This daemon performs the following tasks of KDC:

  1. Client sends out a request to the KDC.
  2. The KDC's authentication server checks the request and sends the TGT to the client. This TGT is encrypted using the client's password. So, only the client can decrypt this and this acts as a proof for the client's identity.
  3. If the client needs to use any service, the client sends out another request to KDC. This request consists of the TGT and the service it requires to use.
  4. This request is now handled by KDC's ticket-granting server. It does the validation of the request and issues a service ticket to the client system. This acts as a proof for the client's identity at the service side.
  5. The client forwards the service ticket to the service it need to use.
  6. The service contacts KDC's ticket-granting server for validation of the ticket and finally it provides access to the user to make use of the service.
Figure 1. Kerberos configuration

IPsec introduction

IPsec is a protocol that provides security at the IP layer in the network stack. This ensures that all the packets transmitted between two systems are encrypted.

The authentication between the two communicating systems can be achieved through pre-shared keys, public key infrastructure, or Kerberos authentication mechanism. Figure 2 represents the basic IPsec configuration.

Figure 2. IPsec basic configuration

This article describes how Kerberos authentication can be used along with the IPsec protocol to ensure that all packets transmitted between two systems are encrypted.

Prerequisites

Before we perform IPsec with Kerberos authentication, ensure that the following prerequisites are met, which would otherwise cause a failure during setup:

  1. Make sure that the host name on all the AIX systems are in the fully qualified domain name (FQDN) form.
  2. By default, some commands of Java™ are set. So, make sure that the PATH environment variable is changed to consider the Kerberos commands path at the /usr/krb5/sbin and /usr/krb5/bin/.
  3. Kerberos tickets contain information about when the tickets are generated and are valid for a few minutes of interval. So, make sure that the timings between the interacting systems are in sync with a maximum difference of 5 minutes between the systems.

Scope of this article

As per this article, we will have three systems configured:

  • One system will be configured as the Kerberos server and this provides authentication service and ticket-granting service
  • An IPsec channel will be established between the other two systems
    • One system acts as the IPsec initiator.
    • Another system acts as the IPsec responder.

For Kerberos authentication, it is required that the IPsec initiator system obtains an initial TGT and makes use of the IPsec service provided on the IPsec responder system. Hence both these systems also act as the Kerberos client systems.

After configuring these systems, we can ping from the IPsec initiator system to the IPsec responder system and verify that the IPsec tunnel is active. We can also confirm whether the Kerberos tickets are obtained properly on the Kerberos client systems.

Figure 3. IPsec with Kerberos configuration

As shown in Figure 3, we will configure britmanual06 as the Kerberos server system, britmanual07 as the IPsec initiator system, and britmanual08 as IPsec responder system. IPsec tunnel will be established between britmanual07 and britmanual08 systems.

Configuration steps

The configuration steps required to perform IPsec with kerberos authentication can be classified into the following two stages:

  1. Configure one system as Kerberos server and other two systems as Kerberos clients.
  2. Configure one Kerberos client system as the IPsec initiator and the other client system as IPsec responder.

1. Configure Kerberos server and Kerberos client systems

You need to perform the following steps to configure Kerberos server and client systems:

  1. Ensure that the Kerberos-related file set is installed on all three (server and client) systems (As stated before, one system will be used as Kerberos server and the Installation of the Kerberos file sets displays the following output:
    # installp -acXYgd . *
    +-----------------------------------------------------------------------------+
                        Pre-installation Verification...
    +-----------------------------------------------------------------------------+
    Verifying selections...done
    Verifying requisites...done
    Results...
    
    SUCCESSES
    ---------
      Filesets listed in this section passed pre-installation verification
      and will be installed.
    
      Selected Filesets
      -----------------
      krb5.client.rte 1.6.0.3                     # Network Authentication Servi...
      krb5.client.samples 1.6.0.3                 # Network Authentication Servi...
      krb5.lic 1.6.0.3                            # Network Authentication Servi...
      krb5.server.rte 1.6.0.3                     # Network Authentication Servi...
      krb5.toolkit.adt 1.6.0.3                    # Network Authentication Servi...
    
      << End of Success Section >>
    
    +-----------------------------------------------------------------------------+
                       BUILDDATE Verification ...
    +-----------------------------------------------------------------------------+
    Verifying build dates...done
    FILESET STATISTICS
    ------------------
        5  Selected to be installed, of which:
            5  Passed pre-installation verification
      ----
        5  Total to be installed
    
    +-----------------------------------------------------------------------------+
                             Installing Software...
    +-----------------------------------------------------------------------------+
    
    installp: APPLYING software for:
            krb5.lic 1.6.0.3
    
    
    ……………………………………………..……………………………………………..
    ……………………………………………..……………………………………………..
    ……………………………………………..……………………………………………..
    ……………………………………………..……………………………………………..
    ……………………………………………..……………………………………………..
    +-----------------------------------------------------------------------------+
                                    Summaries:
    +-----------------------------------------------------------------------------+
    
    Installation Summary
    --------------------
    Name                        Level           Part        Event       Result
    -------------------------------------------------------------------------------
    krb5.lic                    1.6.0.3         USR         APPLY       SUCCESS    
    krb5.client.rte             1.6.0.3         USR         APPLY       SUCCESS    
    krb5.client.samples         1.6.0.3         USR         APPLY       SUCCESS    
    krb5.client.rte             1.6.0.3         ROOT        APPLY       SUCCESS    
    krb5.toolkit.adt            1.6.0.3         USR         APPLY       SUCCESS    
    krb5.server.rte             1.6.0.3         USR         APPLY       SUCCESS    
    krb5.server.rte             1.6.0.3         ROOT        APPLY       SUCCESS    
    [root@britmanual08] /mnt/APPS/ezkrb/NAS_1603_fileset
    #
  2. Configure the Kerberos server on britmanual06.

    You can configure the AIX system as a Kerberos server using the config.krb5 command or the mkkrb5srv (present in /usr/sbin/) command.

    Syntax of this command is as follows:mkkrb5srv -r <Realm name> -d <Domain name> -a <principal name of the Kerberos server admin>

    You will be prompted to set the database master password and the administrator password. In this example, we have provided secret as the password. The following example explains how to configure the Kerberos server.

     [root@britmanual06] /
    # mkkrb5srv -r NFSREALM -d isst.aus.stglabs.ibm.com -a admin/admin
      Fileset                      Level  State      Description         
      ----------------------------------------------------------------------------
    Path: /usr/lib/objrepos
      krb5.server.rte            1.6.0.3  COMMITTED  Network Authentication Service
                                                     Server
    
    Path: /etc/objrepos
      krb5.server.rte            1.6.0.3  COMMITTED  Network Authentication Service
                                                     Server
    Initializing configuration...
    Creating /etc/krb5/krb5_cfg_type...
    Creating /etc/krb5/krb5.conf...
    Creating /var/krb5/krb5kdc/kdc.conf...
    Creating database files...
    Initializing database '/var/krb5/krb5kdc/principal' for realm 'NFSREALM'
    master key name 'K/M@NFSREALM'
    You are prompted for the database Master Password.
    It is important that you DO NOT FORGET this password.
    Enter database Master Password:
    Re-enter database Master Password to verify:
    WARNING: no policy specified for admin/admin@NFSREALM;
      defaulting to no policy. Note that policy may be overridden by
      ACL restrictions.
    Enter password for principal "admin/admin@NFSREALM":
    Re-enter password for principal "admin/admin@NFSREALM":
    Creating keytable...
    Creating /var/krb5/krb5kdc/kadm5.acl...
    Starting krb5kdc...
    krb5kdc was started successfully.
    Starting kadmind...
    kadmind was started successfully.
    The command completed successfully.
    Restarting kadmind and krb5kdc
    [root@britmanual06] /
    #
  3. Configure the Kerberos clients on britmanual07 and britmanual08.

    You can configure the AIX system as a Kerberos client system using the config.krb5 command or the mkkrb5clnt command (present in /usr/sbin/).

    Syntax of this command is as follows -

    mkkrb5clnt -r <Realm name> -d <Domain name> -s <fully qualified hostname of admin server> -c 
    <fully qualified hostname of KDC> -A -i <configure integrated Kerberos authentication> -K -T

    Here, Realm is used as a cluster within a complete administrative domain.

    The arguments have the following meaning:

    ArgumentDescription
    -ASpecifies the root to be added as a Kerberos administrative user
    -iConfigures integrated Kerberos authentication
    -KSpecifies Kerberos to be used as a default authentication scheme
    -TAcquires the server admin TGT based admin ticket

    Here we will be prompted to provide the administrator password that was set during the configuration of the krb server. If successful, we will be prompted to provide a password for the principal entry that will be created for the Kerberos client host system. As a default value, we have provided secret as the password.

    Refer to the following examples to configure the Kerberos clients (britmanual07 and britmanual08).

     [root@britmanual07] /
    # mkkrb5clnt -r NFSREALM -d isst.aus.stglabs.ibm.com -s britmanual06.isst.aus.stglabs.ibm.com -c 
    britmanual06.isst.aus.stglabs.ibm.com -A -i files -K -T
    Initializing configuration...
    Creating /etc/krb5/krb5_cfg_type...
    Creating /etc/krb5/krb5.conf...
    The command completed successfully.
    Password for admin/admin@NFSREALM:
    Configuring fully integrated login
    Authenticating as principal admin/admin with existing credentials.
    WARNING: no policy specified for host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM;
      defaulting to no policy. Note that policy may be overridden by
      ACL restrictions.
    Principal "host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM" created.
    
    Administration credentials NOT DESTROYED.
    Making root a Kerberos administrator
    Authenticating as principal admin/admin with existing credentials.
    WARNING: no policy specified for root/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM;
      defaulting to no policy. Note that policy may be overridden by
      ACL restrictions.
    Enter password for principal "root/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM":
    Re-enter password for principal "root/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM":
    
    Administration credentials NOT DESTROYED.
    Configuring Kerberos as the default authentication scheme
    Cleaning administrator credentials and exiting.
    [root@britmanual07] /
    #
    
    
     [root@britmanual08] /
    # mkkrb5clnt -r NFSREALM -d isst.aus.stglabs.ibm.com -s britmanual06.isst.aus.stglabs.ibm.com -c
    britmanual06.isst.aus.stglabs.ibm.com -A -i files -K -T
    Initializing configuration...
    Creating /etc/krb5/krb5_cfg_type...
    Creating /etc/krb5/krb5.conf...
    The command completed successfully.
    Password for admin/admin@NFSREALM:
    Configuring fully integrated login
    Authenticating as principal admin/admin with existing credentials.
    WARNING: no policy specified for host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM;
      defaulting to no policy. Note that policy may be overridden by
      ACL restrictions.
    Principal "host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM" created.
    
    Administration credentials NOT DESTROYED.
    Making root a Kerberos administrator
    Authenticating as principal admin/admin with existing credentials.
    WARNING: no policy specified for root/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM;
      defaulting to no policy. Note that policy may be overridden by
      ACL restrictions.
    Enter password for principal "root/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM":
    Re-enter password for principal "root/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM":
    
    Administration credentials NOT DESTROYED.
    Configuring Kerberos as the default authentication scheme
    Cleaning administrator credentials and exiting.
    [root@britmanual08] /
    #

    Make sure that the principal name entry corresponding to the client will be created in the KDC, which is host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM and host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM. We can verify this on the Kerberos server system using the kadmin.local command

  4. Prepare the keytab file on the Kerberos client systems.

    The keytab file must contain the principal name entry of both the client systems:

    • Entry of the IPsec initiator system is required to obtain an initial TGT.
    • Entry of the IPsec responder system is required during the setup of the IPsec channel.

    Instead of creating separate keytab files for both the Kerberos client systems, we can create only one keytab file and place it at /etc/krb5/ folder of both the systems. We can create the keytab file using the kadmin command.

    Refer to the following example on preparing the keytab file for both Kerberos client systems.

    root@britmanual08] /
    # kadmin -p admin/admin
    Authenticating as principal admin/admin with password.
    Password for admin/admin@NFSREALM:
    kadmin:  ktadd host/britmanual07.isst.aus.stglabs.ibm.com
    Entry for principal host/britmanual07.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual07.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual07.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual07.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual07.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    kadmin:  ktadd host/britmanual08.isst.aus.stglabs.ibm.com
    Entry for principal host/britmanual08.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual08.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual08.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual08.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
    Entry for principal host/britmanual08.isst.aus.stglabs.ibm.com with kvno 4, 
    encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
    kadmin:

    Now, we can see that the /etc/krb5/krb5.keytab file is created. You can list the entries within this file using the klist -k command. Refer to the following output of the klist -k command.

    [root@britmanual08] /
    # klist -kt
    Keytab name:  FILE:/etc/krb5/krb5.keytab
    KVNO Timestamp         Principal
    ---- ----------------- --------------------------------------------------------
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
    [root@britmanual08] /
    #
  5. We need to securely transfer this file to the other Kerberos client systems using application such as sftp and make sure that it is placed in the /etc/krb5/ folder. To ensure that we are referring to the same keytab file, we can list the keytab file entries on the other Kerberos client system. Refer to the following example that shows how to verify keytab file entries.
    [root@britmanual07] /
    # klist -kt
    Keytab name:  FILE:/etc/krb5/krb5.keytab
    KVNO Timestamp         Principal
    ---- ----------------- --------------------------------------------------------
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:14:48 host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
       4 04/20/17 07:15:00 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
    [root@britmanual07] /
    #
  6. Obtain an initial TGT on the britmanual07 system, which is also the IPsec initiator system.

    We can obtain the TGT from the keytab file entry created for this principal using the kinit command with -k option. We can list the ticket properties using the klist command. Refer to the following output of the kinit and klist commands to get the initial TGT.

    [root@britmanual07] /
    # kinit -k host/britmanual07.isst.aus.stglabs.ibm.com
    [root@britmanual07] /
    # klist -a
    Ticket cache:  FILE:/var/krb5/security/creds/krb5cc_0
    Default principal:  host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
    
    Valid starting     Expires            Service principal
    04/20/17 07:23:26  04/21/17 07:23:26  krbtgt/NFSREALM@NFSREALM
            Addresses: (none)
    [root@britmanual07] /
    #

    After completing the Kerberos server and client configuration, you can configure IPsec on these Kerberos client systems.

2. Configure IPsec initiator and responder systems with Kerberos authentication

The below steps need to be performed to configure IPsec initiator and responder systems

  1. Enable the Internet Key Exchange (IKE) interface on the IPsec initiator and responder systems. The following example shows the set of commands to enable IKE.
    [root@britmanual07] /
    # smit IPsec4
    Default rule for IPv4 in ODM has been changed.
    Successfully set default action to PERMIT
    
                                                                                       COMMAND STATUS
    
    Command: OK            stdout: yes           stderr: no
    
    Before command completion, additional instructions may appear below.
    
    IPsec_v4 Available
    Default rule for IPv4 in ODM has been changed.
    Successfully set default action to PERMIT
    
    [root@britmanual08] /
    # smit IPsec4
    Default rule for IPv4 in ODM has been changed.
    Successfully set default action to PERMIT
    
                                                                                       COMMAND STATUS
    
    Command: OK            stdout: yes           stderr: no
    
    Before command completion, additional instructions may appear below.
    
    IPsec_v4 Available
    Default rule for IPv4 in ODM has been changed.
    Successfully set default action to PERMIT
  2. Prepare and update the IPsec configuration file in the IKE database.

    The first step to configure IPsec on the AIX system is to prepare the IPsec configuration file on the initiator and responder systems. This configuration file is an XML file and do note that 'kerberos authentication' will be mentioned as the AuthenticationMethod

    The following XML code can be used on the IPsec initiator system (britmanual07). Ensure that the values of IPV4_Address of IKELocalIdentity and IKERemoteIdentity are changed acccordingly

    [root@britmanual07] /
    # cat ipsec_Kerberos.xml
    <?xml version="1.0"?>
    <AIX_VPN
          Version="2.0">
       <IKEProtection
             IKE_Role="Both"
             IKE_XCHGMode="Main"
             IKE_KeyOverlap="10"
             IKE_Flags_UseCRL="No"
             IKE_ProtectionName="P1Pol"
             IKE_ResponderKeyRefreshMaxKB="200"
             IKE_ResponderKeyRefreshMinKB="1"
             IKE_ResponderKeyRefreshMaxMinutes="480"
             IKE_ResponderKeyRefreshMinMinutes="1">
          <IKETransform
                IKE_Hash="MD5"
                IKE_DHGroup="1"
                IKE_Encryption="DES-CBC"
                IKE_KeyRefreshMinutes="480"
                IKE_AuthenticationMethod="GSSAPI_Krb5"/>
       </IKEProtection>
       <IKETunnel
             IKE_TunnelName="P1"
             IKE_ProtectionRef="P1Pol"
             IKE_Flags_AutoStart="Yes"
             IKE_Flags_MakeRuleWithOptionalIP="No">
          <IKELocalIdentity>
             <IPV4_Address
                   Value="10.33.0.121"/>
          </IKELocalIdentity>
          <IKERemoteIdentity>
             <IPV4_Address
                   Value="10.33.0.125"/>
          </IKERemoteIdentity>
       </IKETunnel>
      <IPSecProposal
             IPSec_ProposalName="P2Prop">
          <IPSecAHProtocol
                AH_KeyRefreshKB="0"
                AH_Authentication="AH_MD5"
                AH_EncapsulationMode="Transport"
                AH_KeyRefreshMinutes="580"/>
          <IPSecESPProtocol
                ESP_Encryption="ESP_DES"
                ESP_KeyRefreshKB="0"
                ESP_Authentication="HMAC-MD5"
                ESP_EncapsulationMode="Transport"
                ESP_KeyRefreshMinutes="580"/>
       </IPSecProposal>
       <IPSecProtection
             IPSec_Role="Both"
             IPSec_KeyOverlap="10"
             IPSec_ProposalRefs="P2Prop "
             IPSec_ProtectionName="P2Pol"
             IPSec_InitiatorDHGroup="0"
             IPSec_ResponderDHGroup="NO_PFS GROUP_1 GROUP_2 GROUP_5"
             IPSec_Flags_UseLifeSize="No"
             IPSec_Flags_UseCommitBit="No"
             IPSec_ResponderKeyRefreshMaxKB="200"
             IPSec_ResponderKeyRefreshMinKB="1"
             IPSec_ResponderKeyRefreshMaxMinutes="220"
             IPSec_ResponderKeyRefreshMinMinutes="1"/>
       <IPSecTunnel
            IKE_TunnelName="P1"
             IPSec_TunnelName="P2"
             IPSec_ProtectionRef="P2Pol"
             IPSec_Flags_OnDemand="Yes"
             IPSec_Flags_AutoStart="Yes">
          <IPSecLocalIdentity>
             <IPV4_Address
                   Value="10.33.0.121"/>
          </IPSecLocalIdentity>
          <IPSecRemoteIdentity>
             <IPV4_Address
                   Value="10.33.0.125"/>
          </IPSecRemoteIdentity>
       </IPSecTunnel>
    </AIX_VPN>
    [root@britmanual07] /
    #

    The following XML code can be used on the IPsec responder system (britmanual08). Ensure that the values of IPV4_Address of IKELocalIdentity and IKERemoteIdentity are changed acccordingly

    [root@britmanual08] /
    # cat ipsec_Kerberos.xml
    <?xml version="1.0"?>
    <AIX_VPN
          Version="2.0">
       <IKEProtection
             IKE_Role="Both"
             IKE_XCHGMode="Main"
             IKE_KeyOverlap="10"
             IKE_Flags_UseCRL="No"
             IKE_ProtectionName="P1Pol"
             IKE_ResponderKeyRefreshMaxKB="200"
             IKE_ResponderKeyRefreshMinKB="1"
             IKE_ResponderKeyRefreshMaxMinutes="480"
             IKE_ResponderKeyRefreshMinMinutes="1">
          <IKETransform
                IKE_Hash="MD5"
                IKE_DHGroup="1"
                IKE_Encryption="DES-CBC"
                IKE_KeyRefreshMinutes="480"
                IKE_AuthenticationMethod="GSSAPI_Krb5"/>
       </IKEProtection>
       <IKETunnel
             IKE_TunnelName="P1"
             IKE_ProtectionRef="P1Pol"
             IKE_Flags_AutoStart="Yes"
             IKE_Flags_MakeRuleWithOptionalIP="No">
          <IKELocalIdentity>
             <IPV4_Address
                   Value="10.33.0.125"/>
          </IKELocalIdentity>
          <IKERemoteIdentity>
             <IPV4_Address
                   Value="10.33.0.121"/>
          </IKERemoteIdentity>
       </IKETunnel>
      <IPSecProposal
             IPSec_ProposalName="P2Prop">
          <IPSecAHProtocol
                AH_KeyRefreshKB="0"
                AH_Authentication="AH_MD5"
                AH_EncapsulationMode="Transport"
                AH_KeyRefreshMinutes="580"/>
          <IPSecESPProtocol
                ESP_Encryption="ESP_DES"
                ESP_KeyRefreshKB="0"
                ESP_Authentication="HMAC-MD5"
                ESP_EncapsulationMode="Transport"
                ESP_KeyRefreshMinutes="580"/>
       </IPSecProposal>
       <IPSecProtection
             IPSec_Role="Both"
             IPSec_KeyOverlap="10"
             IPSec_ProposalRefs="P2Prop "
             IPSec_ProtectionName="P2Pol"
             IPSec_InitiatorDHGroup="0"
             IPSec_ResponderDHGroup="NO_PFS GROUP_1 GROUP_2 GROUP_5"
             IPSec_Flags_UseLifeSize="No"
             IPSec_Flags_UseCommitBit="No"
             IPSec_ResponderKeyRefreshMaxKB="200"
             IPSec_ResponderKeyRefreshMinKB="1"
             IPSec_ResponderKeyRefreshMaxMinutes="220"
             IPSec_ResponderKeyRefreshMinMinutes="1"/>
       <IPSecTunnel
            IKE_TunnelName="P1"
             IPSec_TunnelName="P2"
             IPSec_ProtectionRef="P2Pol"
             IPSec_Flags_OnDemand="Yes"
             IPSec_Flags_AutoStart="Yes">
          <IPSecLocalIdentity>
             <IPV4_Address
                   Value="10.33.0.125"/>
          </IPSecLocalIdentity>
          <IPSecRemoteIdentity>
             <IPV4_Address
                   Value="10.33.0.121"/>
          </IPSecRemoteIdentity>
       </IPSecTunnel>
    </AIX_VPN>
    [root@britmanual08] /
  3. Before loading the IPsec configuration file, we need to clear any older configuration present in the database. The following example provides a set of commands to clean the old configuration. Make sure to clear the old configuration on both, initiator and responder systems.
    [root@britmanual07] /
    # ikedb -x
    P1_ITD database created successfully
    P2_ITD database created successfully
    P1_PREKEY database created successfully
    PROPOSAL_LIST database created successfully
    PROPOSAL database created successfully
    POLICY database created successfully
    GROUP database created successfully
    NDBM:/etc/IPsec/inet/DB/privkey
    [root@britmanual07] /
    #
    
    [root@britmanual08] /
    # ikedb -x
    P1_ITD database created successfully
    P2_ITD database created successfully
    P1_PREKEY database created successfully
    PROPOSAL_LIST database created successfully
    PROPOSAL database created successfully
    POLICY database created successfully
    GROUP database created successfully
    NDBM:/etc/IPsec/inet/DB/privkey
    [root@britmanual08] /
    #
  4. Load the IPsec configuration file into the database on both IPsec initiator and responder systems. The following example shows how to load the IPsec configuration into database.
    [root@britmanual07] /
    # ikedb -p IPsec_Kerberos.xml
    [root@britmanual07] /
    #
    [root@britmanual08] /
    # ikedb -p IPsec_Kerberos.xml
    [root@britmanual08] /
    #
  5. Start the IPsec daemons (iked, tmd, cpsd, isakmpd) on the IPsec initiator and responder systems –and make sure that all the daemons as active. The following example shows how to start the IPsec daemons.
    [root@britmanual07] /
    # stopsrc -g ike
    0513-004 The Subsystem or Group, ike, is currently inoperative.
    [root@britmanual07] /
    # lssrc -g ike
    Subsystem         Group            PID          Status
     cpsd             ike                           inoperative
     tmd              ike                           inoperative
     iked             ike                           inoperative
    
    [root@britmanual07] /
    # startsrc -g ike
    0513-059 The cpsd Subsystem has been started. Subsystem PID is 21626958.
    0513-059 The tmd Subsystem has been started. Subsystem PID is 17891446.
    0513-059 The iked Subsystem has been started. Subsystem PID is 19267598.
    [root@britmanual07] /
    #
    [root@britmanual07] /
    # lssrc -g ike
    Subsystem         Group            PID          Status
     cpsd             ike              21626958     active
     tmd              ike              17891446     active
     iked             ike              19267598     active
    [root@britmanual07] /
    #
    [root@britmanual08] /
    # stopsrc -g ike
    0513-004 The Subsystem or Group, ike, is currently inoperative.
    [root@britmanual08] /
    # lssrc -g ike
    Subsystem         Group            PID          Status
     cpsd             ike                           inoperative
     tmd              ike                           inoperative
     iked             ike                           inoperative
     [root@britmanual08] /
    # startsrc -g ike
    0513-059 The cpsd Subsystem has been started. Subsystem PID is 22741118.
    0513-059 The tmd Subsystem has been started. Subsystem PID is 21495958.
    0513-059 The iked Subsystem has been started. Subsystem PID is 23265318.
    [root@britmanual08] /
    # lssrc -g ike
    Subsystem         Group            PID          Status
     cpsd             ike              22741118     active
     tmd              ike              21495958     active
     iked             ike              23265318     active
    [root@britmanual08] /
    #
  6. Start the IKE channel from the initiator system and ensure that the local ID and remote ID IP address matches with the systems across which we want to create the IPsec channel. The following example includes the commands to start the IKE channel on initiator system.
    [root@britmanual07] /
    # ike cmd=activate
    Phase 2 tunnel 1 On_Demand activate request initiated.
    [root@britmanual07] /
    # ike cmd=list
    Phase  Tun Id  Status      Local Id                        Remote Id
    1      1       Dormant     N/A                             10.33.0.125
    2      1       Dormant     10.33.0.121                     10.33.0.125
    [root@britmanual07] /
    # ike cmd=list
    Phase  Tun Id  Status      Local Id                        Remote Id
    1      1       Negotiating N/A                             10.33.0.125
    2      1       Dormant     10.33.0.121                     10.33.0.125
    [root@ britmanual07] /
    # ping 10.33.0.248
    PING 10.33.0.248 (10.33.0.248): 56 data bytes
    64 bytes from 10.33.0.248: icmp_seq=6 ttl=255 time=2 ms
    64 bytes from 10.33.0.248: icmp_seq=7 ttl=255 time=0 ms
    64 bytes from 10.33.0.248: icmp_seq=8 ttl=255 time=0 ms
    ^C
    --- 10.33.0.248 ping statistics ---
    9 packets transmitted, 3 packets received, 66% packet loss
    round-trip min/avg/max = 0/0/2 ms
    [root@britmanual07] /
    # ike cmd=list
    Phase  Tun Id  Status      Local Id                        Remote Id
    1      1       Active      10.33.0.121                     10.33.0.125
    2      1       Active      10.33.0.121                     10.33.0.125
    [root@britmanual07] /
    #
     
    [root@ britmanual08] /
    # ike cmd=list
    Phase  Tun Id  Status      Local Id                        Remote Id
    1      1       Active      10.33.0.125                     10.33.0.121
    2      1       Active      10.33.0.125                     10.33.0.121
    [root@ britmanual08] /
    #
  7. We can make sure that Kerberos authentication has taken place by verifying the Kerberos ticket exchanged. Run the klist command to list the tickets. Refer to the following output of the klist command.
    [root@britmanual07] /
    # klist
    Ticket cache:  FILE:/var/krb5/security/creds/krb5cc_0
    Default principal:  host/britmanual07.isst.aus.stglabs.ibm.com@NFSREALM
    Valid starting     Expires            Service principal
    09/10/14 01:49:09  09/11/14 01:49:09  krbtgt/NFSREALM@NFSREALM
    09/10/14 01:59:26  09/11/14 01:49:09 host/britmanual08.isst.aus.stglabs.ibm.com@NFSREALM
    [root@britmanual07] /
    #

    As we can see, a ticket host or an FQDN of the responder is obtained by the initiator system. This acts as service principal name. We were also not prompted for password because we had the keytab entry created on the responder system.

Conclusion

This article helps users understand how to configure an IPsec channel across two systems with Kerberos authentication. Kerberos authentication is more secured compared to a pre-shared key and it also provides the single sign-on (SSO) feature. So, with the same Kerberos setup, we can as well achieve user authentication for other applications without the need to enter password every time.

Resources


Downloadable resources


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=1048135
ArticleTitle=Configure an IPsec environment using the Kerberos authentication mechanism
publish-date=07282017