diff options
| author | George Kadianakis <desnacked@riseup.net> | 2016-12-01 16:14:10 -0500 |
|---|---|---|
| committer | George Kadianakis <desnacked@riseup.net> | 2016-12-01 16:15:11 -0500 |
| commit | 2b650b67e4fb0d06e1fb33cf6122ab31a5b39038 (patch) | |
| tree | 5a01711726ff733059719daf0c5a3dc0ad759723 /proposals/224-rend-spec-ng.txt | |
| parent | 890779ffec60f067048c4e4a9895ccdd49d183a5 (diff) | |
| download | torspec-2b650b67e4fb0d06e1fb33cf6122ab31a5b39038.tar.gz torspec-2b650b67e4fb0d06e1fb33cf6122ab31a5b39038.zip | |
prop224: Remove username/password intro-layer auth.
Authorized clients need a x25519 key to decrypt the descriptor anyway,
so having username/password method for the intro-layer authorization is
not very helpful, since they will need to remember the x25519 key anyway.
Perhaps in the future we can reinstate the username/password method, by
having x25519/ed25519 keypairs be generated from the low-entropy
username/password pair.
Diffstat (limited to 'proposals/224-rend-spec-ng.txt')
| -rw-r--r-- | proposals/224-rend-spec-ng.txt | 26 |
1 files changed, 5 insertions, 21 deletions
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 4f05638..0b23fc1 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -60,8 +60,7 @@ Table of contents: 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] 3.4. Authentication during the introduction phase. [INTRO-AUTH] - 3.4.1. Password-based authentication. - 3.4.2. Ed25519-based authentication. + 3.4.1. Ed25519-based authentication. 4. The rendezvous protocol 4.1. Establishing a rendezvous point [EST_REND_POINT] 4.2. Joining to a rendezvous point [JOIN_REND] @@ -1733,26 +1732,11 @@ Table of contents: 3.4. Authentication during the introduction phase. [INTRO-AUTH] - Hidden services may restrict access only to authorized users. One - mechanism to do so is the credential mechanism, where only users who - know the credential for a hidden service may connect at all. For more - fine-grained conntrol, a hidden service can be configured with - password-based or public-key-based authentication. + Hidden services may restrict access only to authorized users. + One mechanism to do so is the credential mechanism, where only users who + know the credential for a hidden service may connect at all. -3.4.1. Password-based authentication. - - To authenticate with a password, the user must include an extension - field in the encrypted part of the INTRODUCE1 cell with an - EXT_FIELD_TYPE type of [01] and the contents: - - Username [00] Password. - - The username may not include any [00] bytes. The password may. - - On the server side, the password MUST be stored hashed and salted, - ideally with scrypt or something better. - -3.4.2. Ed25519-based authentication. +3.4.1. Ed25519-based authentication. To authenticate with an Ed25519 private key, the user must include an extension field in the encrypted part of the INTRODUCE1 cell with an |