Using Public-Key Infrastructure (PKI) in Your Network

The S- and K-Series PKI implementation supports the secure authentication of an SSH client to an Extreme Networks S- and K-Series device using an X.509 certificate and authorization using RADIUS, TACACS, or local policy.

There are three primary aspects to PKI configuration:

• X.509 certificate – The specification of a certificate issued by a Certification Authority (CA) that binds a public key to an organizational or common name or an alternative DNS-entry. The X.509 certificate commands allow users to enter X.509 certificates via the command line and to group these certificates into lists. An SSH server requiring PKI services references these certificate lists.
• Online Certificate Status Protocol (OCSP) – An Internet protocol, defined in RFC 2560, used for obtaining the revocation status of an X.509 digital certificate. The OCSP commands are used to enable, disable and configure certificate revocation checking.
• Authentication and Authorization– The verification of the user certificate‘s issuance chain back to the certificate authority by the SSH server in order to determine whether the user is who they claim to be followed by a verification of the validity of the public user certificate. The authentication commands define a set of rules used for extracting a user‘s authentication credentials from the X.509 certificate‘s subject field. The extracted credential is then presented to a RADIUS, TACSACS+ or local authentication server.
  

  Note

  The SSH server must be configured for SSH client authentication using PKI. See Configuring Secure Shell for SSH server authentication configuration details.

There are no PKI MIB objects. PKI is exclusively managed by the CLI. CLI users with admin access (su) can set, show and clear all of the PKI configuration objects. Users with read-only (ro) or read-write (rw) access are restricted to displaying show commands.

The following figure presents a PKI login flow overview in a RADIUS server authorization context.

Public-Key Infrastructure Login Flow Overview

Callout 1 is the initial series of message exchanges initiated by the SSH client. The S- or K-Series device providing the SSH client with the list of supported authentication methods one of which is public key. The SSH client responds with its public key certificate.

At Callout 2, the S- or K-Series device checks to make sure the certificate signature from SSH client matches a trusted certificate authority‘s certificate defined in PKI certificate authority list on the S- or K-Series SSH server.

At Callout 3, the S- or K-Series device sends an OCSP request that contains the Client‘s certificate serial number to the OCSP responder to check the validity of the Clients X.509 certificate, and the OCSP Responder uses the serial number to look up the revocation status of the SSH client‘s certificate. If the OCSP responder determines that the certificate has not been revoked by the certificate authority, the server sends back a GOOD response. The responder certificate is an OCSP signing certificate issued by the CA that issued the certificate that is being validated. Supported certificates are common issuer, Delegated Trust Model (DTM), and Trusted Responder Model (TRM) as defined in FRC 5280. When using TRM, use the set pki ocsp signature-ca-list command to specify the trusted list. Lists are created using the set pki certificate command.

At Callout 4, the S- or K-Series device queries the setting of the PKI authorization user name and potentially prompts for the RADIUS password. These values will be used to verify the Authorization of the SSH client‘s user.

At Callout 5, Radius Authorization is configured on the S- or K-Series device. The resulting Radius Access Request contains the appropriate username and password. Radius Server sends Access-Accept message and the SSH client is now both authenticated (PKI) and authorized (RADIUS) and SSH negotiates a PTY and a shell to use for the user login session.