Low Infrastructure Public Key Based GSS Security Mechanisms by qza17959

VIEWS: 0 PAGES: 40

									Low Infrastructure Public Key Based GSS
          Security Mechanisms


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

   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
       credentials
      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
    mechanisms
       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
    changes?
               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
        now.
       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

   NULL-MAC
   Md5WithRSAEncryption
   Sha1WithRSAEncryption
   DsaWithSHA1
   DES-MAC
   MD5-DES-MAC
   SUM64-DES-CBC
                 Proposed C-ALGs

   Cast5CBC
   AES256-CBC
   AES128-CBC
   DES-EDE3-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
                         Tokens

   Context establishment tokens
       SPKM-REQ, SPKM-REP-TI, SPKM-REP-IT
   Per message tokens
       SPKM-MIC, SPKM-WRAP
   Error and delete tokens
       SPKM-ERROR, SPKM-DEL, SPKM-GSS-ERROR
   All tokens are ASN1 encoded, integrity protected
                       SPKM-REQ

   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
                       SPKM-REP-TI

   Target verifies the request (signature and certificate
    verification), retrieves initiator’s DH parameters and
    public key, calculates the context key, derives the
    subkeys
   Creates the reply and signs it
       In anonymous SPKM3, the digest of the signature includes
        SPKM-REQ
   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
                      SPKM-REP-IT

   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
    verification
                         LIPKEY

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

                  draft-adamson-rfc2847-bis-00
   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

                  draft-adamson-rfc2847-bis-01
   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
                        Issues

   Naming
   Algorithms
   Backward compatibility
   Error handling
                          Algorithms

   Protocol negotiates a set of integrity (I-ALG),
    confidentiality (C-ALG), and one-way function (O-ALG)
    algorithms
   Some I-ALGs are only used during context
    establishment
       NULL-MAC, digital signature algorithms (eg.,
        md5RSAEncryption)
   Some algorithms are out of date and left for backward
    compatibility
                   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,
             value=UTF8String:service@hostname
            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
         code)
   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
    characters)
   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-
    GSS-ERROR
   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
    hanging
                   Additional issues

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

   If algorithms, writing and naming issues are
    addressed…

								
To top