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. Summary

This specification describes a concrete syntax for a public key authentication scheme for HTTP transactions. It provides a minimal HTTP extension for mutual authentication and message origin authentication, via the integrity protection of a defined set of HTTP message headers. It offers message sequence integrity, forward secrecy, and optionally content integrity and content ciphering.

It is intended for application in situations where credential-based schemes are inappropriate for architectural reasons or are considered too weak, and also where message-layer and/or application-layer security requirements are not fulfilled by transport-layer or network-layer security protocols. It is not intended as a substitute for lower- or higher-layer security protocols, and indeed may be found to usefully coexist with these.