a Secarta project ...

HTTPsec Authentication Protocol

[ View as one printable page ]

Preamble

1. Introduction

1.1. Editorial Conventions

1.2. Terms

1.3. Identifiers

2. Summary

2.1. Authentication Model

2.2. Peer Identifiers

2.3. Protocol Operation

2.3.1. Initialization

2.3.2. Continuation

3. Protocol Messages

3.1. Initialization Messages

3.1.1. Initialization Request

3.1.2. Initialization Response

3.2. Continuation Messages

3.2.1. Continuation Request

3.2.2. Continuation Response

3.3. Challenge Messages

3.3.1. Challenge Response

3.4. Message Flow

4. Protocol Directives

4.1. id

4.2. dh

4.3. certificate

4.4. url

4.5. group

4.6. nonce

4.7. auth

4.8. token

4.9. signature

4.10. count

4.11. mac

4.12. digest

5. Other Headers

5.1. Content-Encoding

5.2. Cache-Control

5.3. Expires

6. Protocol Computations

6.1. Algorithms

6.1.1. Hash Algorithm

6.1.2. Public Key Algorithm

6.1.3. Encryption Scheme

6.1.4. Signature Scheme

6.1.5. Block Cipher

6.1.6. Block Cipher Mode

6.2. Header Canonicalization

6.3. Initialization Transcript

6.4. Continuation Request Transcript

6.5. Continuation Response Transcript

6.6. Shared Secret

6.7. Keys

6.7.1. MAC Keys

6.7.2. Cipher Keys

6.8. Message Body Ciphering

7. Message Validation

7.1. Initialization Request Validation

7.2. Initialization Response Validation

7.3. Continuation Request Validation

7.4. Continuation Response Validation

8. Cache Considerations

9. Security Considerations

10. References

11. Editor Address

2.1. Authentication Model

This scheme uses public keys for the mutual authentication of peers. More precisely, it allows one peer to authenticate a message that purports to originate from another peer.

As with all public key authentication schemes, acceptance of the authenticity of a peer is equivalent to establishing that the peer possesses the private key paired with a certain public key. The authentication model is thus predicated on the assumption that the authenticator can correctly associate a public key with the peer it is authenticating. Accordingly, a candidate purporting to be such a peer is considered authentic if it can demonstrate its ability to invoke the associated private key. This document does not address the process by which a public key is associated (correctly or not) with a peer. The protocol is intended to be able to integrate with any number of such mechanisms, from "leap of faith" type schemes such as employed by SSH, to trust-based schemes such as PKI style certification.