Low Infrastructure Public Key Based GSS Security Mechanisms

William (Andy) AdamsonOlga Kornievskaia

Center for Information Technology IntegrationUniversity 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…