Low Infrastructure Public Key Based GSS Security Mechanisms by qza17959


									Low Infrastructure Public Key Based GSS
          Security Mechanisms

                  William (Andy) Adamson
                      Olga Kornievskaia
       Center for Information Technology Integration
                   University of Michigan
                     IETF67, San Diego

   Problem Statement
   Existing Work
   Draft-
       SPKM3
       LIPKEY
   Unsolved issues
                   Problem Statement

The purpose of this BOF is to decide how to get a
  standards track solution for a low infrastructure GSS
  security mechanism which uses PKI credentials
Two modes are important
      A mode where both the target and the initiator have PKI
      A mode where the target has PKI credentials, and the
       initiator has a username and a password
                     Problem Statement

   By low infrastructure, we mean the protocol does not
    require an external Public Key Infrastructure for
    certificate verification.
       No directory service to store Public Key Certificates
       No support protocols or applications to retrieve certificates
        from such a directory service
   The NFS version 4 protocol is driving this need.
       Low infrastructure PKI eases cross domain NFS file sharing
                      Problem Statement

   The NFS version 4 protocol states as one of its four
    main goals
       Strong security with negotiation built into the protocol
   It supports the RPCSEC_GSS protocol, and specifies
    a mandatory minimal set of GSS security
       Kerberos V5
       LIPKEY and SPKM-3 (username & password with target PKI)
   Other mechanisms may also be specified and used for
    NFS version 4.1 security.
            Why NFS version 4 and PKI?

   NFS version 4 protocol wants to make use of existing
    Public Key Infrastructure, and to provide an alternative
    to Kerberos V5.
   I see several markets for NFS version 4 and PKI
       Existing username, password systems
       Government computing, where PK credentials are mandated
       Grid computing
         NFS version 4 and Grid Computing

   Grid computing is in dire need of a high performance
    distributed file system that can (among other things)
    leverage the Grid cross-organization low infrastructure
    Public Key model used by Globus GSI software.
       The grid community is looking to NFS version 4.x to solve
        their data management and access problems
       It is essential for NFS to have the ability to use grid X.509
        credentials for data security (mutual authentication mode)
       The need is immediate: For example, the Large Hadron
        Collider at CERN is scheduled to come back on line in 2007
        producing many peta-bytes of data.
         NFS version 4 and Grid Computing
   The National Science Foundation agrees: SPKM
    development and integration with GSI is funded by
    CITI’s GridNFS NSF project
   CITI is backing Open Science Grid managed clusters
    with NFSv4 using SPKM
       Run authenticated jobs in the future
       Use GSI identities mapped to ACLs
                     NFSv4 PKI History
   RFC2025 “The Simple Public-Key GSS-API
    Mechanism (SPKM)”
       Standards track, Network Working Group, October 1996
   RFC2847 “A Low Infrastructure Public Key Mechanism
    Using SPKM”
       Standards track, Network Working Group, June 2000
   RFC2847 refers to RFC2025 in describing SPKM-3
       No mention of mutual authentication (initiator credentials)
       Anonymous initiator secure channel used by LIPKEY
                    NFSv4 PKI History

   SPKM-3 meeting at the NFSv4 Bakeathon, Austin
    Texas, October 20 2003
       IBM and CITI talked about RFC2847 interoperability issues
   SPKM-3 has been in the Linux kernel since April 2004
       libgssapi_spkm3.so has also been available since 2004
   Hummingbird SPKM-3 and LIPKEY implementation
    tested at September 2006 NFSv4 Bakeathon
       Windows client interoperated with CITI SPKM-3 server
                    BOF Questions from Sam

   What deployed production code is out there that either
    interoperates with RFC2847 or draft-adamson?
        Linux
             No deployed Linux SPKM/LIPKEY
             Linux SPKM-3 implementation is RFC2847 compliant with mutual
              authentication added
        Hummingbird (Not an official statement, my understanding..)
             Hummingbird implementation is very new, and not yet deployed, but is in
              demand - they released a LIPKEY implementation in June 2006.
             RFC2847 compliant
        IBM (Not an official statement, my understanding..)
             Some RFC2847 SPKM-3 work was done
             No mention of SPKM with AIX product
               BOF Questions from Sam

   Can we meet our security and other requirements
    without making backward incompatible changes and
    forcing an OID change?
       No. RFC2025 is broken (and therefore so is RFC2847)
   Going forward, can we obtain a simpler spec or
    implementation by making non-backward compatible
               BOF Questions from Sam

   When will we get a spec out?
       Hopefully before IETF 68
   How long will the market wait?
       As I pointed out in previous slides, we need PK for NFS right
       Mutual Authentication mode for GRID
       Username/password mode for Hummingbird market.
               BOF Questions from Sam

   Which will take longer: fixing this spec (draft-adamson)
    or starting from scratch
       Considering the maturity of the Linux RFC2847
        implementation, from the Linux point of view, starting from
        scratch will take a lot longer
                          SPKM3 overview

   Algorithms
       Integrity
       Confidentiality
       One-way function for key-derivation
       Key-establishment (Diffie-Hellman)
                  Proposed I-AGLs

   Md5WithRSAEncryption
   Sha1WithRSAEncryption
   DsaWithSHA1
                 Proposed C-ALGs

   Cast5CBC
   AES256-CBC
   AES128-CBC
                  Proposed O-ALGs

   Use Diffie-Hellman, a non-negotiable key
    establishment (K-ALG), to establish a context key
   Use context key to derive subkeys for the negotiated I-
    ALG and C-ALG
   SHA1

   Context establishment tokens
   Per message tokens
   Error and delete tokens
   All tokens are ASN1 encoded, integrity protected

   Initiator creates a request and signs it using one of the
    digital signature integrity algorithms for mutual SPKM3
    and using NULL-MAC for anonymous SPm3
   Mandatory fields in the request are token id, context
    id, version, nonce, target name, list of i-algs, c-algs, o-
    algs, DH parameters
   In mutual SPKM3, initiator includes its certificate and
    optionally a CA chain

   Target verifies the request (signature and certificate
    verification), retrieves initiator’s DH parameters and
    public key, calculates the context key, derives the
   Creates the reply and signs it
       In anonymous SPKM3, the digest of the signature includes
   Mandatory field are token id, context id, version,
    client’s nonce, target name, server’s nonce, i-alg, c-
    alg, o-alg, DH public key, cert + CA chain

   Only present for mutual SPKM3 and is needs to
    prevent replay attacks
   Mandatory fields in the token are token id, context id,
    client’s nonce, server’s nonce, target’s name
   Initiator creates the reply and signs it
                     Error token(s)

   Error tokens can be use to negotiate details such as
    length of keys or DH parameters
   RFC2847 SPKM-ERROR token contains token id,
    context id. The token is signed using one of the digital
    signature algorithms
   SPKM-GSS-ERROR token contains token id, context
    id, major and minor status. As before, token is signed,
    but certificate and optionally CA chain is included for

   Uses anonymous SPKM3 to negotiate secure
   SPKM-REQ and SPKM-REP-TI tokens are exchanged
   Initiator then sends user’s id and password
                IETF Review Comments

   Wrong document reviewed
   Poor choice of words/incomplete spec
       [removed] references to non-repudiation
       [removed] advertisement-like SPKM features
       [specified] Diffie-Hellman groups
   Poor choice of algorithms
                IETF Review Comments

   Poor choice of algorithms
   Poor choice of words/style
       [removed] exportability concerns
       MAC and signature algorithms
       Explanations of the ANS1 structures
       QOP section
   Key Derivation Function

   Naming
   Algorithms
   Backward compatibility
   Error handling

   Protocol negotiates a set of integrity (I-ALG),
    confidentiality (C-ALG), and one-way function (O-ALG)
   Some I-ALGs are only used during context
       NULL-MAC, digital signature algorithms (eg.,
   Some algorithms are out of date and left for backward
                   Algorithms (cont)

   I-ALGs: hmac-sha1
   C-ALGs: aes256-cbc, aes128-cbc, des3-ede-cbc
   Specify algId for SPKM-REQ to be either NULL-MAC
    (for anonymous) or a digital signature algorithm, ie,
    sha1WithRSAEncryption (for mutual)
   Specify algId for SPKM-REP-TI and SPKM-REP-IT to
    be a digital signature algorithm
                             Naming (target)

   Client needs to create a target name then match it
    against server’s X509 certificate
       lacks server’s certificate
       has information such as server’s location (hostname) and
        service name
            Start with target name:
                 Type GSS_C_NT_HOSTBASED_SERVICE
                 Value nfs@citi.umich.edu
            Convert to X509 NAME
                 CN=nfs/citi.umich.edu
                Naming: do as PKINIT does
   Target acquires certificate with
       Extended Key Usage (EKU) X509v3 extension:
            per protocol: id-spkm3
            per server: id-spkm3-server
            per service: id-spkm3-nfs
       Subject Alternative Name (SAN):
            dnsName=hostname
            otherName: oid=id-spkm3-server,
            Draft-ietf-pkix-srvsan-03 proposal: otherName: oid=id-on-dnsSRV,
             value=UTF8String: _Service.Name (components of an SRV RR)
                        Naming (client)

   Server needs to create a canonical name from the
    client’s X509 certificate
       X509 DN has no defined canonical form
       Cannot do as PKINIT does! No namespace to fallback into
       Can still mandate to include an EKU for client’s certificates
        (id-spkm3 or id-spkm3-client)
                 Canonical X509 DN rules

   It is possible to state rules that if applied will produce
    (almost) a canonical name
        Start by creating an RFC2253 compliant string
         representation of the DN
        Apply rules proposed in the draft (origin:Java X509 source
   Known problems:
        Case (in)sense RDNs
              Canonicalization rules

   Leading zeros are removed from attribute types that
    are encoded as dotted decimal OIDs.
   DirectoryString attribute values of type PrintableString
    and UTF8String are not in hexadecimal format
   DirectoryString attribute values of types other than
    PrintableString and UTF8String are output in
    hexadecimal format
          Canonicalization rules           (cont)

   Leading and trailing white space characters are
    removed from non-hexadecimal attribute values
    (unless the value consists entirely of white space
   Internal substrings of one or more white space
    characters are converted to a single space in non-
    hexadecimal attribute values
         Canonicalization rules           (cont)

   Relative Distinguished Names containing more than
    one Attribute Value Assertion (AVA) are output in the
    following order: an alphabetical ordering of AVAs
    containing standard keywords, followed by a numeric
    ordering of AVAs containing OID keywords.
   The only characters in attribute values that are
    escaped are those which section 2.4 of RFC2253
    states must be escaped (they are escaped using a
    preceding backslash character)
               Backward compatibility

   SPKM-ERROR token should be replaced by SPKM-
   SPKM-DEL token should be removed because GSS
    API recommends that it is not used
   Moved AuthorizationData field
   Added extensibility markers to allow modification to
    the mechanism
   Should we worry about backward compatibility with
    RFC2847 (RFC2025)?
               Error handling problem

   Unlike a to-be-deprecated delete token, an error
    tokens are used during context establishment
   If server creates an error token and returns a failure
    major/minor status then, GSS API does not guarantee
    the token is sent
   If server were to return GSS_COMPLETE, then after
    client processes an error token and decides not to
    sent another SPKM-REQ token, the server is left
                   Additional issues

   AuthorizationData field in request (SPKM-REQ)
   CertificatePair structure not needed
   SPKM2 specific fields (timestamp, non DH k-alg)
   QOP

   If algorithms, writing and naming issues are

To top