Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/crypto/external/bsd/netpgp/dist/src/libpaa Add an implementa...
details: https://anonhg.NetBSD.org/src/rev/a893cfe261e4
branches: trunk
changeset: 757657:a893cfe261e4
user: agc <agc%NetBSD.org@localhost>
date: Fri Sep 10 05:15:16 2010 +0000
description:
Add an implementation of the Pubkey Access Authentication Scheme proposed
by Oliver Gould in
http://www.olix0r.net/PubKeyAccessAuthScheme.txt
This implementation includes an example client and server program, but
is not (yet) hooked into the build.
To quote from Oliver's RFC:
HTTP services are a core Internet technology, yet the Digest
authentication scheme provided by RFC 2617 only describes
authentication by way of shared-secrets (i.e. passwords).
This model has operational drawbacks, as authenticating
services are required to have access to a user's secret (or a
hash thereof), or retrograde technologies, such as cookies,
are employed.
Similarly to SSH's "publickey" authentication method [RFC
4252], the PubKey Access Authentication scheme allows an HTTP
server to authenticate clients using public key credentials.
Like the Digest Access Authentication Scheme [RFC 2617], the
PubKey.v1 scheme is based on a simple challenge-response
paradigm. The PubKey scheme responds to unauthorized clients
with a challenge value; and a valid response contains a
cryptographic signature of client's id, the authentication
realm, and the server's challenge.
The client's secret never leaves the client. The server
verifies the client's signed authorization request with the
client's published public keys.
libpaa(3) uses libnetpgp(3) for its digital signatures, SHA1Init(3)
for digests, and base64 encoding for transmission of data.
diffstat:
crypto/external/bsd/netpgp/dist/src/libpaa/PubKeyAccessAuthScheme.txt | 417 ++++++++++
crypto/external/bsd/netpgp/dist/src/libpaa/client.c | 87 ++
crypto/external/bsd/netpgp/dist/src/libpaa/libpaa.3 | 117 ++
crypto/external/bsd/netpgp/dist/src/libpaa/libpaa.c | 387 +++++++++
crypto/external/bsd/netpgp/dist/src/libpaa/libpaa.h | 93 ++
crypto/external/bsd/netpgp/dist/src/libpaa/server.c | 114 ++
6 files changed, 1215 insertions(+), 0 deletions(-)
diffs (truncated from 1239 to 300 lines):
diff -r 8ebc76551a8e -r a893cfe261e4 crypto/external/bsd/netpgp/dist/src/libpaa/PubKeyAccessAuthScheme.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/external/bsd/netpgp/dist/src/libpaa/PubKeyAccessAuthScheme.txt Fri Sep 10 05:15:16 2010 +0000
@@ -0,0 +1,417 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+DRAFT VERSION 0.4.2
+
+
+Oliver Vaughn Gould <ver%olix0r.net@localhost>
+July 2010
+
+
+ PubKey Access Authentication Scheme, Version 1
+ ----------------------------------------------
+
+ 0 Introduction
+ --------------
+
+ 0.1 Status of this Memo
+ ------------------------
+
+This document specifies a DRAFT protocol for the Internet community.
+
+
+ 0.2 Copyright Notice
+ ---------------------
+
+Copyright (C) Yahoo!, Inc. (2010). All rights reseved.
+
+
+ 0.3 Abstract
+ -------------
+
+HTTP services are a core Internet technology, yet the Digest authentication
+scheme provided by RFC 2617 only describes authentication by way of
+shared-secrets (i.e. passwords).
+
+The PubKey Access Authentication scheme aims to enhance security on the
+World Wide Web by bringing an equivalent of SSH's "publickey" authentication
+method to challenge-based HTTP client authentication.
+
+
+ 0.4 Table of Contents
+ ----------------------
+
+ 1 PubKey Access Authentication Scheme, Version 1
+ 1.1 Introduction
+ 1.1.1 Purpose
+ 1.1.2 Overall Operation
+ 1.2 Specification of PubKey.v1 Headers
+ 1.2.1 The WWW-Authenticate Response Header
+ 1.2.2 The Authorize Request Header
+ 1.3 Example
+ 1.4 Proxy-Authentication and Proxy-Authorization
+ 1.5 Operational Considerations
+ 1.5.1 Replay Attacks
+ 1.5.2 Man-in-the-Middle Attacks
+ 1.5.3 Brute Force Attacks
+ 1.5.4 Spoofing by Counterfeit Servers
+ 2 References
+ A Appendices
+ A.1 Challenge Generation
+
+
+ 1 PubKey Access Authentication Scheme, Version 1
+ -------------------------------------------------
+
+ 1.1 Introduction
+ -----------------
+
+ 1.1.1 Purpose
+ --------------
+
+HTTP services are a core Internet technology, yet the Digest authentication
+scheme provided by RFC 2617 only describes authentication by way of
+shared-secrets (i.e. passwords). This model has operational drawbacks, as
+authenticating services are required to have access to a user's secret (or
+a hash thereof), or retrograde technologies, such as cookies, are employed.
+
+Similarly to SSH's "publickey" authentication method [RFC 4252], the PubKey
+Access Authentication scheme allows an HTTP server to authenticate clients using
+public key credentials.
+
+
+ 1.1.2 Overall Operation
+ ------------------------
+
+Like the Digest Access Authentication Scheme [RFC 2617], the PubKey.v1
+scheme is based on a simple challenge-response paradigm. The PubKey scheme
+responds to unauthorized clients with a challenge value; and a valid
+response contains a cryptographic signature of client's id, the authentication
+realm, and the server's challenge.
+
+The client's secret never leaves the client. The server verifies the
+client's signed authorization request with the client's published public
+keys.
+
+
+ 1.2 Specification of PubKey.v1 Headers
+ ---------------------------------------
+
+ 1.2.1 The WWW-Authenticate Response Header
+ -------------------------------------------
+
+If a server receives a request for an access-protected object, and an
+acceptable Authorization header is not sent, the server responds with a
+"401 Unauthorized" status code, and a WWW-Authenticate header as per the
+framework defined above, which for the digest scheme is utilized as
+follows:
+
+ challenge = "PubKey.v1" pubkey-challenge
+
+ pubkey-challenge = 1#( realm | [domain] | challenge )
+
+ realm = "realm" "=" quoted-string
+ domain = "domain" "=" <"> URI ( 1*SP URI ) <">
+ URI = absoluteURI | abs_path
+ challenge = "challenge" "=" quoted-string
+
+The meanings of the values of the directives used above are as follows:
+
+ realm
+ A string to be displayed to clients so they know which username and
+ public key to use. This string should contain at least the name of
+ the host performing the authentication and might additionally
+ indicate the collection of users who might have access. An example
+ might be "admin%svc.domain.tld@localhost".
+
+ domain
+ An optional quoted, space-separated list of URIs that define the
+ protection space. If a URI is an abs_path, it is relative to the
+ canonical root URL of the server being accessed. An absoluteURI in this
+ list may refer to a different server than the one being accessed. The
+ client can use this list to determine the set of URIs for which the same
+ authentication information may be sent: any URI that has a URI in this
+ list as a prefix (after both have been made absolute) may be assumed to be
+ in the same protection space. If this directive is omitted or its value
+ is empty, the client should assume that the protection space consists of
+ all URIs on the responding server.
+
+ This directive is not meaningful in Proxy-Authenticate headers, for
+ which the protection space is always the entire proxy; if present it
+ should be ignored.
+
+ challenge
+ A quoted string of data, specified by the server, which should be returned
+ by the client unchanged in the Authorization header of subsequent
+ requests with URIs in the same protection space. It is recommended
+ that this string be base 64 or hexadecimal data.
+
+
+ 1.2.2 The Authorization Request Header
+ -------------------------------------
+
+The client is expected to retry the request, passing an Authorization
+header line, which is defined according to the framework above, utilized as
+follows.
+
+ credentials = "PubKey.v1" privkey-credentials
+
+ privkey-credentials = 1#( identifier | realm | challenge | signature )
+
+ identifier = "id" "=" identifier-value
+ identifier-value = quoted-string
+ challenge = "challenge" "=" challenge-value
+ challenge-value = quoted-string
+ signature = "signature" "=" signature-value
+ signature-value = quoted-string
+
+The values of the challenge and realm fields must be those supplied in the
+WWW-Authenticate response header for the entity being requested.
+
+ identifier
+ The client identifier in the specified realm. I.e. the client's username.
+
+ signature
+ A quoted base 64 encoded string representation of a signature generated
+ with the client's private key as follows.
+
+ signature = BASE64( D^M( authorization ))
+ authorization = identifier-value ";" realm-value ";" challenge-value
+
+If a directive or its value is improper, or required directives are
+missing, the proper response is 400 Bad Request. If the signature is
+invalid, then a login failure should be logged, since repeated login
+failures from a single client may indicate malfeasance.
+
+The client should be able to reuse this Authorization until a 401
+Unauthorized is reached, or an Authentication-Info header provides a new
+challenge.
+
+
+ 1.2.3 Authentication-Info Header
+ ---------------------------------
+
+The optional Authentication-Info header may be used by the server to
+communicate some information regarding the successful authentication in the
+response. Specifically, this header can be used to send a new challenge to
+an authorized client.
+
+ AuthenticationInfo = "Authentication-Info" ":" auth-info
+ auth-info = 1#( next-challenge )
+ next-challenge = "challenge" "=" challenge-value
+
+The meanings of the values used above are as follows:
+
+ next-challenge
+ The following request on this domain should contain an authorization
+ on this challenge value. It should be expected that reissuing the
+ used Authorization header will result in a 401 Unauthorized response.
+
+
+ 1.3 Example
+ ------------
+
+The following example assumes that an access-protected resource is being
+requested from the server via a GET request. The URI of the document is
+"http://svc.domain.tld/object";. Both client and server know the public key
+for the user identified as "McFly" in the realm "users%svc.domain.tld@localhost".
+
+The first time the client requests the document, no Authorization header is
+sent, so the server responds with:
+
+ 401 Unauthorized
+ WWW-Authenticate: PubKey.v1
+ challenge="aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09",
+ realm="users%svc.domain.tld@localhost"
+
+The client's user agent determines the client's identifier and private key
+to use for the realm. The user agent then uses this private key to sign
+the server's challenge, prompting the user as neccessary. Finally, the
+client sends a new request including the Authorization header:
+
+ Authorization: PubKey.v1
+ id="McFly",
+ challenge="aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09",
+ realm="users%svc.domain.tld@localhost",
+
signature="AAAAB3NzaC1yc2EAAAEAWARe6cScN5t0aFy0lBA1EbC/JoyRxsEuPsWtFZ3qw12lXYcmTXuq1v/0lwqcgZQgutQdiavR6O6157uyk0dkfuDXiuOjsngkmgp0oN/kwYxKPVrXMze1tFr8tFBUQU+JeCbvVd+o6LeD7pO29onXqf776N21nX1sRaeT+wX6qNMNEgJ7S3TzwTgMJ4Ub5dMCxXYCX7AW15YzLie213fvU3YiBh1ZHy//ubDb29d/2t941/gAdipjRQiabWK5lpfkmLJWJddlZq3IyFqiXMM1vpaGmiiM5w2fMpuzO8enyRTDtQQwLAxrffxY/n6RbGvUiEU4YzSGLlPE6KUU36dKOw=="
+
+The server verifies the client's signature on the following authorization
+string:
+
+ McFly;users%svc.domain.tld@localhost;aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk=;dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09
+
+Assuming that the challenge generation algorithm described in section A.1
+is used, the server then verfies its own signature of the challenge by
+decoding the challenge thusly:
+
+ b64-server-signature = "aKMpP2pkd3qiDnOUAHJ+pB1VdphaR2tFSF4J7wLWODk="
+ b64-challenge = "dXNlcnNAc3ZjLmRvbWFpbi50bGQ7MTI3ODExMjc5OTsxMjcuMC4wLjE7bThvK3JUa29rRVFPMFFLRUh2L280dz09"
+ challenge = "users%svc.domain.tld@localhost;1278112799;127.0.0.1;m8o+rTkokEQO0QKEHv/o4w=="
+
+After the server's signature is verified, it checks the realm, expiration, and
+source IP encoded in the challenge to authorize the request.
+
+
+ 1.4 Proxy-Authentication and Proxy-Authorization
+ -------------------------------------------------
+
+The PubKey.v1 authentication scheme may also be used for authenticating
+clients to proxies, proxies to proxies, or proxies to origin servers by use
+of the Proxy-Authenticate and Proxy-Authorization headers. These headers
+are instances of the Proxy-Authenticate and Proxy-Authorization headers
+specified in sections 10.33 and 10.34 of the HTTP/1.1 specification [RFC
+2616] and their behavior is subject to restrictions described there. The
+transactions for proxy authentication are very similar to those already
+described. Upon receiving a request which requires authentication, the
+proxy/server must issue the "407 Proxy Authentication Required" response
+with a "Proxy-Authenticate" header. The pubkey-challenge used in the
+Proxy-Authenticate header is the same as that for the WWW-Authenticate
+header as defined above in section 1.2.1.
+
+The client/proxy must then re-issue the request with a Proxy-Authorization
+header, with directives as specified for the Authorization header in
+section 1.2.2 above.
+
+Note that in principle a client could be asked to authenticate itself to
+both a proxy and an end-server, but never in the same response.
+
+
+ 1.5 Operational Considerations
+ -------------------------------
+
+ 1.5.1 Replay Attacks
+ ---------------------
+
+The challenge generation scheme described in section A.1 includes a
+server-signed time, client IP address, and random seed; after verifying its own
+signature, the server verifies that the authorized request is from the expected
+source and within the allowed session time.
+
+The server may preempt the need for an expired transaction by sending a new
+challenge in an AuthorizationInfo header.
+
+
+ 1.5.2 Man-in-the-Middle Attacks
+ --------------------------------
+
Home |
Main Index |
Thread Index |
Old Index