HOPE draft 3

From Higher Intellect wiki
Jump to: navigation, search
======================================
HOPE draft 3 - Secure Login revision 3
======================================

** Hotline Transactions:
htlcHdrLogin:        = &h0000006b (107)

htlsHdrTask:         = &h00010000 (65536)

** Hotline Objects:
htlcDataIcon         = &h0068 (104)
htlcDataLogin        = &h0069 (105)
htlcDataNick         = &h0066 (102)
htlcDataPassword     = &h006a (106)

htlsDataLogin        = &h0069 (105)

** HOPE transactions:
<none>

** HOPE objects:
htlxDataAppID        = &h0e01 (3585)
htlxDataAppString    = &h0e02 (3586)
htlxDataSessionKey   = &h0e03 (3587)
htlxDataMACAlgorithm = &h0e04 (3588)

** Data Values:
0x####      = fixed value in hexadecimal
<type:name> = variable value
[...]+      = repeating group
//          = comments

** Data Types:
u##  = ##-bit unsigned integer
str  = variable sized string
str4 = 4-byte string (OSType)

** HOPE Secure Login in a nutshell:
1. Client sends its app-info and a list of algorithms in order of
preference to the server in a login packet with an invalid login (ascii 00).

2. The server (if it supports HOPE) will reply with its app-info, the
session key for the connection, the algorithm to be used for the secure
login, and indicates if only the password, or also the login should be
encrypted.

3. The client encrypts the password - and if the server supports it the
login too - and sends it in a normal login packet. Everything continues
like a normal hotline session from that moment on.

** Client-Server dialog

htlcHdrLogin // this packet is called the "Identification Transaction"
  htlcDataLogin: 0x00  // fixed value
  htlxDataMACAlgorithm: <u16:count> [<u8:length> <str:name>]+
               example: 0002  09 "HMAC-SHA1" 08 "HMAC-MD5"
               // supported algorithms in order of preference
  htlxDataAppID: <str4:id> // the creator/id of the app. 4 bytes.
  htlxDataAppString: <str:desc> // the name+version of your app

htlsHdrTask  // this packet is called the "Identification Reply"
  htlxDataSessionKey: <str:sessionkey>  // the session key for the connection
  htlxDataMACAlgorithm: 0x0001 <u8:length> <str:name>  // algorithm used
  htlsDataLogin: <str:name>  // blank if login should not be hashed
                             // mac alg name if it should
  htlxDataAppID: <str4:id> // the creator/id of the server app. 4 bytes.
  htlxDataAppString: <str:desc> // the name+version of the server app

htlcHdrLogin
  htlcDataLogin: <str:inverse(login)> // if htlsDataLogin was blank
                 <str:mac(login,sessionkey)> // if htlsDataLogin was non-blank
  htlcDataPassword: <str:mac(password,sessionkey)>
  htlcDataNick:  <str:nickname>
  htlcDataIcon:  <u16:icon>

** Notes and Details

The htlxDataMACAlgorithm in the identification transaction contains a list
of names of algorithms. The first two bytes is the number of algorithms in
the list, then the sequence of pascal strings (len+data) follows. The first
algorithm is the most preferably, the last algorithm is the least
preferable.

If the program is a MacOS application, AppID should be the creator.
Otherwise you should pick a 4-character abbreviation of your program's
name. AppString is free to be filled in by the application, and should
contain at least the name and version of the application. It should be
human-readable formatted.

The sessionkey exists of two parts: a random sequence of bytes, and the IP
of the server. The random sequence of bytes can be of any length. The IP of
the server is encoded as 4 bytes. The server IP can be used by the client
to check if it's authentic (the same value as it connected to) to prevent
fraud. If it doesn't match, the client is recommended to put a warning on
screen, and disrecommended to continue logging in.

The htlsDataLogin in the identification reply should be set to the
algorithm name by the server if it supports an encrypted login in addition
to an encrypted password. It should be blank (length = 0) if the server
does not support an encrypted login. The client is recommended to simply
check if it's blank or non-blank.

The server is required to support the algorithm "INVERSE" and if the server
doesn't support any of the algorithms supplied by the client, or if the
server doesn't support Secure Login at all (but does support HOPE), it
should return "INVERSE" as the algorithm to be used.

** MAC Algorithms

Neither the server nor the client is required to implement all or any of
them, except for the algorithm "INVERSE" which must be supported by both
client and server.

NOTE: In case of the referenced documents describing HMAC-SHA1 and
HMAC-MD5: "K" is the password and "text" is the session key.

Currently, the following algorithms are defined:
(in order of safety. Safest algorithm first)

"HMAC-SHA1": hmac_sha1(password,sessionkey). Explained in detail in section
2.2 of:
<http://snad.ncsl.nist.gov/itg/doc/draft-ietf-ipsec-ah-hmac-sha-01.txt>

"SHA1": sha1(password + sessionkey). Explained in detail at:
<http://bilbo.isu.edu/security/isl/fip180-1.html>

"HMAC-MD5": hmac_md5(password,sessionkey). Explained in detail in section
2.2 of:
<http://snad.ncsl.nist.gov/itg/doc/draft-ietf-ipsec-ah-hmac-md5-01.txt>

"MD5": md5(password + sessionkey). Explained in detail at:
<http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/13xx/1321>

"INVERSE": the bitwise inverse of the password. (Required)


Share your opinion