Low Infrastructure Public Key Based GSS Security Mechanisms

1. William (Andy) Adamson Olga Kornievskaia Center for Information Technology Integration University of Michigan IETF67, San Diego Low Infrastructure Public Key Based GSS Security Mechanisms

2. Outline • Problem Statement • Existing Work • Draft- • SPKM3 • LIPKEY • Unsolved issues

3. 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

4. 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

5. 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.

6. 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

7. 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.

8. 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

9. 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

10. 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

11. 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

12. 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?

13. 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.

14. 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

15. SPKM3 overview • Algorithms • Integrity • Confidentiality • One-way function for key-derivation • Key-establishment (Diffie-Hellman)

16. Proposed I-AGLs • NULL-MAC • Md5WithRSAEncryption • Sha1WithRSAEncryption • DsaWithSHA1 • DES-MAC • MD5-DES-MAC • SUM64-DES-CBC

17. Proposed C-ALGs • Cast5CBC • AES256-CBC • AES128-CBC • DES-EDE3-CBC

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Issues • Naming • Algorithms • Backward compatibility • Error handling

28. 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

29. 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

30. 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

31. 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)

32. 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)

33. 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

34. 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

35. 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

36. 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)

37. 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)?

38. 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

39. Additional issues • AuthorizationData field in request (SPKM-REQ) • CertificatePair structure not needed • SPKM2 specific fields (timestamp, non DH k-alg) • QOP

40. Conclusions • If algorithms, writing and naming issues are addressed…