Author: bdonlan Date: 2005-06-22 13:32:52 -0400 (Wed, 22 Jun 2005) New Revision: 792
Added: trunk/docs/proposed-std/ trunk/docs/proposed-std/auth-proposed.txt trunk/docs/proposed-std/reconnect.txt Removed: trunk/docs/auth-proposed.txt Modified: trunk/ Log: [EMAIL PROTECTED]: bdonlan | 2005-06-10 16:29:29 -0400 Comma-seperation [EMAIL PROTECTED]: bdonlan | 2005-06-10 16:43:33 -0400 x-<any> tweak [EMAIL PROTECTED]: bdonlan | 2005-06-22 13:30:54 -0400 Proposed seamless reconnect functionality Property changes on: trunk ___________________________________________________________________ Name: svk:merge - 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/havercurs-objc:43050 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:1132 edfcd8bd-4ce7-0310-a97e-bb1efd40edf3:/local:238 + 1f59643a-e6e5-0310-bc24-f7d4c744f460:/haver/havercurs-objc:43089 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:1132 edfcd8bd-4ce7-0310-a97e-bb1efd40edf3:/local:238 Deleted: trunk/docs/auth-proposed.txt =================================================================== --- trunk/docs/auth-proposed.txt 2005-06-21 20:05:46 UTC (rev 791) +++ trunk/docs/auth-proposed.txt 2005-06-22 17:32:52 UTC (rev 792) @@ -1,148 +0,0 @@ ---- Phase INIT: - -C: HAVER <user-agent> <features> - -user-agent is a freeform text string describing the client version. features is an arbitrarily long, comma-seperated list of supported protocol extensions. -If the client sends anything not fitting this description, or some other error occurs, the server must immediately disconnect. - -If <features> contains the element `auth', the server will attempt to use the authentication protocol with this connection. - -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 comma-seperated 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 exists.user <name> - -There is already a user online by that name. Return to the beginning of phase LOGIN. - -S: FAIL IDENT invalid.name <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. -This must only be sent if 'auth' was in the client's greeting message's <features> list. - -S: FAIL IDENT auth.needed <name> - -Login to <name> requires the use of authentication, and 'auth' was not advertised in the client features list. -Return to the beginning of phase LOGIN. - ---- 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, experimental, or non-standard algorithm. - -It is strongly suggested that all servers and clients implement sha1. -Use of the md5 algorithm is discouraged. Added: trunk/docs/proposed-std/auth-proposed.txt =================================================================== --- trunk/docs/proposed-std/auth-proposed.txt 2005-06-21 20:05:46 UTC (rev 791) +++ trunk/docs/proposed-std/auth-proposed.txt 2005-06-22 17:32:52 UTC (rev 792) @@ -0,0 +1,148 @@ +--- Phase INIT: + +C: HAVER <user-agent> <features> + +user-agent is a freeform text string describing the client version. features is an arbitrarily long, comma-seperated list of supported protocol extensions. +If the client sends anything not fitting this description, or some other error occurs, the server must immediately disconnect. + +If <features> contains the element `auth', the server will attempt to use the authentication protocol with this connection. + +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 comma-seperated 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 exists.user <name> + +There is already a user online by that name. Return to the beginning of phase LOGIN. + +S: FAIL IDENT invalid.name <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. +This must only be sent if 'auth' was in the client's greeting message's <features> list. + +S: FAIL IDENT auth.needed <name> + +Login to <name> requires the use of authentication, and 'auth' was not advertised in the client features list. +Return to the beginning of phase LOGIN. + +--- 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, experimental, or non-standard algorithm. + +It is strongly suggested that all servers and clients implement sha1. +Use of the md5 algorithm is discouraged. Property changes on: trunk/docs/proposed-std/auth-proposed.txt ___________________________________________________________________ Name: svn:eol-style + native Added: trunk/docs/proposed-std/reconnect.txt =================================================================== --- trunk/docs/proposed-std/reconnect.txt 2005-06-21 20:05:46 UTC (rev 791) +++ trunk/docs/proposed-std/reconnect.txt 2005-06-22 17:32:52 UTC (rev 792) @@ -0,0 +1,73 @@ +Seamless reconnect capability + +===OVERVIEW=== + +This proposed extension allows a user disconnected by network problems to +reconnect without sending a S: QUIT message, and maintaining whichever +channels they may be in. + +===PROTOCOL=== + +A client requests this capability by sending the 'reconnect' capability +string in its greeting: + +C: HAVER superclient/1.0 auth,reconnect + +And the server acknowledges with the same: + +S: HAVER server++/42.42 reconnect + +Should a client operating with the reconnect capability disconnect through +means other than an explicit C: BYE message, the server shall send in the +client's name a private message to all users who would receive a S: QUIT from +that user: + +S: FROM <name> NETDEAD <quit reason> + +<quit reason> is the same string that would come after S: QUIT <user> under +normal circumstances. + +After this message is sent, the user remains online for a server-defined +amount of time. Any private message sent to the user is responded to with +another NETDEAD message, and buffered at the server. + +If the client reconnects before the server timeout expires, the server must +attach it to the existing user entity on the server, and send a + +S: JOIN <channel> <user> + +for each channel the user is already in. It also must send a + +S: FROM <name> RECONNECT + +to each user who would receive a QUIT message from that user, plus the user +themself. This message must be received after all S: JOINs. Any private +messages sent while the user was offline SHOULD be replayed to the newly +reconnected client. The server MAY prepend a timestamp. All private messages +MUST be replayed before the RECONNECT message is received. + +If the client reconnects without sending the 'reconnect' capability, the +existing user entity MUST S: QUIT with the reason string 'ghost', as in: + +S: QUIT <user> ghost + +The server MUST create a new entity with the same state as a newly connecting +client for the reconnecting client. Any private messages SHOULD be replayed, +optionally with a timestamp, followed by a S: FROM <name> RECONNECT sent to +the reconnecting user only. + + +Should the client fail to reconnect before the timeout, the server SHOULD quit +the old entity with a + +S: QUIT <user> recon_timeout + +===SECURITY CONSIDERATIONS=== + +Servers should take precautions to avoid user takeovers. For authenticated +users, authentication MUST be used during the reconnect, and servers MAY +restrict authentication to the particular method used on the previous login. + +For unauthenticated users, servers SHOULD limit reconnect capability to the +same IP address as the first connection, and deny connections from other IPs +from attempting to reconnect. Property changes on: trunk/docs/proposed-std/reconnect.txt ___________________________________________________________________ Name: svn:eol-style + native
