slide1 n.
Skip this Video
Download Presentation
Low Infrastructure Public Key Based GSS Security Mechanisms

Loading in 2 Seconds...

play fullscreen
1 / 40

Low Infrastructure Public Key Based GSS Security Mechanisms - PowerPoint PPT Presentation

  • Uploaded on

William (Andy) Adamson Olga Kornievskaia Center for Information Technology Integration University of Michigan IETF67, San Diego. Low Infrastructure Public Key Based GSS Security Mechanisms. Outline. Problem Statement Existing Work Draft- SPKM3 LIPKEY Unsolved issues. Problem Statement.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Low Infrastructure Public Key Based GSS Security Mechanisms' - justin-macdonald

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
William (Andy) Adamson

Olga Kornievskaia

Center for Information Technology Integration

University of Michigan

IETF67, San Diego

Low Infrastructure Public Key Based GSS Security Mechanisms
  • Problem Statement
  • Existing Work
  • Draft-
    • SPKM3
    • LIPKEY
  • Unsolved issues
problem statement
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 statement1
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 statement2
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
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
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 computing1
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
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 history1
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
    • 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
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 sam1
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 sam2
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 sam3
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
SPKM3 overview
  • Algorithms
    • Integrity
    • Confidentiality
    • One-way function for key-derivation
    • Key-establishment (Diffie-Hellman)
proposed i agls
Proposed I-AGLs
  • Md5WithRSAEncryption
  • Sha1WithRSAEncryption
  • DsaWithSHA1
proposed c algs
Proposed C-ALGs
  • Cast5CBC
  • AES256-CBC
  • AES128-CBC
proposed o algs
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
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 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
  • 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
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 comments1
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) 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
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
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:
        • Value
      • Convert to X509 NAME
        • CN=nfs/
naming do as pkinit does
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
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
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
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
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 cont1
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
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
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
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 addressed…