Refining the IPsec Peer Authorization Database

Document Sample
Refining the IPsec Peer Authorization Database Powered By Docstoc
					Refining the IPsec Peer
Authorization Database
       Steve Kent
      2401bis PAD Highlights
• The PAD specifies how to authenticate each peer, e.g.,
  via shared secret or use of a certificate, and how to
  obtain revocation status info if certificates are used
• The PAD specifies the TSi addresses or symbolic
  names that a peer is authorized to represent when
  (child) SAs are negotiated and that are used for SPD
• If symbolic names are specified, they are compared to
  the IKE ID, otherwise the TSi values from CREATE
  CHILD SA are used
• The ID of the peer is taken from the IKE ID payload
  (this identity may be completely independent from child
  SA IDs)
                      PAD Model
            Auth method        Child SA                 Revocation
    Peer ID              flag
             & auth data      constraints                 status

address range or                     address range or
symbolic name                        symbolic name

                            Use IKE ID
                             or TSi?                 Pointer to CRL
                                                    or OCSP data, if
              Shared secret or                       certificates are
            Certificate (EE or TA)                         used
         Why Constraints?
• Need to know whether SAs created by a peer
  will be identified in the SPD by symbolic
  name, or by address
• For name, use IKE ID to locate SPD entry,
  otherwise use TSi
• Apply constraints before doing SPD lookup,
  to prevent an authenticated peer from
  creating SAs for which it is not authorized
  Matching Rules for the PAD
• Two forms of matching take place in the PAD
  – Using the IKE ID payload as a key to locate a PAD
  – Using child SA constraints to filter the TSi address
    or IKE ID, before doing an SPD lookup
• The PAD should accommodate matching
  rules for names, and range matching for IP
  addresses, to facilitate concise expression of
  both sets of info
           More Matching
• The Peer ID may be a symbolic name (DN,
  FQDN, or RFC 822 address) or an IP address
  (v4 or v6)
• The child SA constraints may be of the same
  types, to accommodate named SPD entries
• For FQDN and RFC 822 address, star-name
  matching seems appropriate
• For DNs, there are matching rules from X.500
• For addresses, ranges seem appropriate
        Example PAD Entries
IKE          IKE Auth          SA                  Revocation
Peer ID      Data              Constraints         info   Certificate for   IPv4:   OCSP server
       name and public
*    Certificate for   * (user LDAP server
    (TA)      names)          name for
*    Certificate for   IPv4:   OCSP server
    (TA)      name and public
   More Example PAD Entries
IKE Peer         IKE Auth SA                  Revocation
ID               Data     Constraints         info
C = US, O =      Shared   IPv4:   N/A
BBN, OU =        secret
Security Dept,
CN = Stephen
                          NOT IPv4:           N/A
                       Shared   IPv4:   N/A
     Is This What We Need?
• Does it cover what implementations do today?
• Does the PAD need to be ordered, like the
  SPD, because of possible peer ID name
• Are any important cases not covered?
• Do we need to accommodate self-signed
  certificates, and if so, how?
• Do we need negative SA constraints entry to
  accommodate self-signed certificates while
  also accommodating other, authenticated

Shared By: