Difference between revisions of "SCEP in IPA"

From Dogtag
Jump to: navigation, search
Line 1: Line 1:
 +
= SCEP in IPA =
 
== Short Term Solution ==
 
== Short Term Solution ==
 
=== Description ===
 
=== Description ===

Revision as of 15:32, 15 November 2011

SCEP in IPA

Short Term Solution

Description

  1. In the DMZ, install the Dogtag Perl-based RA. Point this RA to the IPA-CA. (ipa-host:443). It will talk to the IPA-CA directly. As part of the setup, an RA agent is created that allows the RA to send agent authenticated requests to the IPA-CA(similar tot IPA-RA plugin)
  2. Populate RA with relevant agents/users
  3. For full operation (users, agents), then following servlets need to be exposed in the dogtag-proxy.conf file on the IPA server's /etc/httpd/conf.d/ directory.
conn.ca1.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient
conn.ca1.servlet.addagent=/ca/admin/ca/registerRaUser
conn.ca1.servlet.revoke=/ca/subsystem/ca/doRevoke
conn.ca1.servlet.unrevoke=/ca/subsystem/ca/doUnrevoke
  1. For SCEP operations only, the following servlets need to be exposed in the dogtag-proxy.conf file. Most likely, this directive would have to be placed in the stanza where client auth is required - to be investigated.
/ca/ee/ca/pkiclient
  1. Some more servlets may need to be exposed for installation of the RA to succeed - to be investigated.

How this works

  1. client contacts dogtag-RA and requests a pin (one time password). This generates a pin request on the RA.
  2. An agent connects to the RA using a browser and provides a agent cert for authentication. The agent approves the pin request and a pin is generated.
  3. The agent provides the pin to the client in an out-of-band method. (phone, email)
  4. Client router sends SCEP requests to enroll to dogtag RA, providing the pin as the challenge password.
  5. RA confirms that the pin is correct, and if so, passes the agent authenticated requests to the IPA-CA. The RA retrieves the issued cert.
  6. RA then deletes the pin from its database
  7. RA provides cert to the client router.

Problems

  1. RA maintains its own identity store of authorized agents. This means dual maintenanceof identity information (ipa and ra).
  2. RA store is in sqlite - which has no real time replication mechanism
  3. RA is in DMZ. Better not to have identity/pin info in the DMZ.

Long Term Solution

  1. IPA would be the location for identity and pin operations.
  2. Clients inside the firewall would connect directly to IPA.
  3. Clients outside the firewall would connect to a scaled down RA, which would simply proxy the requests to IPA.

How this works - clients inside firewall

  1. User contacts IPA and provides kerberos credentials. Through some UI or CLI command, he requests that router X be able to enroll via SCEP. As the user is authenticated as an agent, IPA generates a pin and provides it to the user.
  2. router contacts IPA with relevant pin in SCEP request.
  3. IPA verifies pin and sends an agent authenticated SCEP request (from the extended IPA-RA plugin) to the IPA-CA.
  4. IPA-CA issues the cert
  5. IPA returns cert to client router

How this works - clients outside firewall

  1. Client contacts new dummy RA in the DMZ and requests a pin.
  2. Pin request is proxied to IPA.
  3. Agent contacts IPA and provides kerberos credentials. Through some UI or CLI command, he lists the pending pin requests and approves the pin request. IPA generates a pin and displays it. The agent provides the pin to the client in an out-of-band manner.
  4. router contacts the RA with relevant pin in SCEP request.
  5. RA proxies this request to IPA
  6. IPA verifies pin and sends an agent authenticated SCEP request (from the extended IPA-RA plugin) to the IPA-CA.
  7. IPA-CA issues the cert
  8. IPA returns cert to the RA, which returns it to the client router.