Author: bdonlan Date: 2005-06-10 16:22:43 -0400 (Fri, 10 Jun 2005) New Revision: 756
Added: trunk/docs/auth-proposed.txt Modified: trunk/ Log: [EMAIL PROTECTED]: bdonlan | 2005-06-10 16:22:28 -0400 Add proposed authentication protocol Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/havercurs-objc:42820 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/local/trunk:11166 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/local/trunk-merge-10131:11178 27e50396-46e3-0310-8b22-ae223a1f35ce:/local:212 e9404bb1-7af0-0310-a7ff-e22194cd388b:/haver/local:1063 edfcd8bd-4ce7-0310-a97e-bb1efd40edf3:/local:238 + 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/havercurs-objc:43042 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/local/trunk:11166 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/local/trunk-merge-10131:11178 27e50396-46e3-0310-8b22-ae223a1f35ce:/local:212 e9404bb1-7af0-0310-a7ff-e22194cd388b:/haver/local:1040 edfcd8bd-4ce7-0310-a97e-bb1efd40edf3:/local:238 Added: trunk/docs/auth-proposed.txt =================================================================== --- trunk/docs/auth-proposed.txt 2005-06-10 20:10:15 UTC (rev 755) +++ trunk/docs/auth-proposed.txt 2005-06-10 20:22:43 UTC (rev 756) @@ -0,0 +1,140 @@ +--- Phase INIT: + +C: HAVER <user-agent> <features> + +user-agent is a freeform text string describing the client version. features is an arbitrarily long list of supported protocol extensions. +If the client sends anything not fitting this description, or some other error occurs, the server must immediately disconnect. + +S: HAVER <hostname> <server-version> <features> + +server-version is another string, akin to the user-agent, except describing the server version. +hostname is the server's canonical hostname, as used by later authentication protocols. The user agent should warn if this does not match what host +it connected to. +features is a list of supported protocol extensions. + +After S: HAVER is sent, processing proceeds to the LOGIN phase. + +--- Phase LOGIN: + +C: IDENT <name> + +<name> is the Haver name the user wishes to use. + +Potential responses: + +S: FAIL IDENT user.exists <name> + +There is already a user online by that name. Return to the beginning of phase LOGIN. + +S: FAIL IDENT invalid.user <name> + +<name> has invalid syntax for a Haver name. Return to the beginning of phase LOGIN. + +S: FAIL IDENT reserved.name <name> + +<name> is reserved for server use. Return to the beginning of phase LOGIN. + +S: FAIL IDENT user.denied <name> <detail> + +Access to the server by that name is forbidden by site policy. <detail> is +an optional freeform human-readable string describing the reason of the error. +Return to the beginning of phase LOGIN. + +S: ACCEPT <name> + +Login has been accepted, and normal command processing may proceed. + +S: AUTH:TYPE <protocols> + +Access to the requested name requires authentication by one of the +authentication protocols listed in <protocols>. Enter phase AUTH. + +--- Phase AUTH: + +At any time during phase AUTH or an authentication protocol, the following +commands may be used: + +C: IDENT <name> + +Abort the authentication and retry with a new name. The semantics of this +command and its responses are the same as in phase LOGIN. + +C: AUTH:TYPE <protocol> + +Begin authentication using the protocol named. If authentication is already +in progress with a different protocol, the old authentication context is +aborted. + +Responses to C: AUTH:TYPE: + +S: FAIL AUTH:TYPE unknown.protocol <protocol> + +Authentication protocol <protocol> is unknown to the server. + +# Note: in the following sections, <cmd> is to be considered equivalent to +# 'AUTH:' followed by the upper-case translation of <protocol> + +S: <cmd> <args> + +Protocol negotiation with <protocol> begins. <args> is a protocol-defined +argument list. At this point, server and client proceed with the protocol +with a series of <cmd> messages, until one of the following is sent: + +S: FAIL <cmd> auth.failed <protocol> + +Authentication failed with protocol <protocol>. The client may retry with +a different protocol, or the same protocol again, by sending C: AUTH:TYPE +again. + +S: ACCEPT <name> + +Authentication completed successfully. + + +--- AUTHENTICATION PROTOCOLS + +Protocol 'basic' + +The basic protocol implements a simple challenge-response password protocol. +The following values are defined: + +<passcode> = base64(sha1(<password> + <user> + <host>)) +<digest> = a digest algorithm (listed below) +<nonce> = a cryptographically secure random string + +The protocol is as follows: + +S: AUTH:TYPE ... basic ... +C: AUTH:TYPE basic +S: AUTH:BASIC <nonce> <digest algorithms> +C: AUTH:BASIC <digest> base64(digest(<nonce> + <passcode>)) + +S: FAIL AUTH:BASIC auth.failed basic + +Authentication failed, as the second argument of the prior C: AUTH:BASIC +message did not match the expected value + +S: FAIL AUTH:BASIC unknown.digest <digest> + +Digest <digest> is unknown. The client may retry its C: AUTH:BASIC with a +different digest algorithm. + +S: ACCEPT <name> + +Authentication succeeded. + +--- DIGEST ALGORITHMS + +<digest> must be listed in <digest algorithms> +These may be one of the following defined protocols: + +sha1: SHA-1 as defined in Secure Hash Standard, NIST FIPS 180-1 +sha256: SHA-256 as defined in Federal Information Processing Standard 180-2, Secure Hash Standard (SHS) +sha384: SHA-384 as defined in Federal Information Processing Standard 180-2, Secure Hash Standard (SHS) +sha512: SHA-512 as defined in Federal Information Processing Standard 180-2, Secure Hash Standard (SHS) +md5: The MD5 message digest algorithm as defined in RFC 1321. +ripemd160: The RIPEMD-160 algorithm. +x-<any>: Site-specific or experimental algorithm. + +It is strongly suggested that all servers and clients implement sha1. +Use of the md5 algorithm is discouraged. Property changes on: trunk/docs/auth-proposed.txt ___________________________________________________________________ Name: svn:eol-style + native
