AMQP Security SIG
Subbu Srinivasan
Cisco Systems
Introduction
This write up explains the initial proposal for supporting encryption/digital signature
operations as part of the basic AMQP protocol, this particular proposal addresses the
infrastructure for the base protocol to offer security on the wire. It DOES not deal with
the support required for additional application level semantics like partial content
encryption and non-repudiation.
The security sig believes that we should focus on proposing message level crypto
semantics and not on the transport level semantics since the transport level semantics are
well defined and understood. Additionally it is the committee’s belief that we should
push strongly for message level semantics to be part of the specification for several well
documented reasons, we also refrain from making any implementation specific
guidelines in this document.
Frames are units of physical transmission between two AMQP entities and hence any
crypto related semantics need to be introduced at a higher level.
General Description
The current specification lays out the following kinds of segments.
1. Type = 0, Network control
2. Type = 1, Session control
3. Type = 2, Execution control
4. Type = 17, Method
5. Type = 18, Content header
6. Type = 19, Content body
7. Type = 24, Heartbeat
8. Type = 28, Trace
9. Type= XX Security Context - New
10. Type= YY Signature Context - New
Security is an orthogonal component that spans across all the boundaries; hence we
introduce the notion of a sec-context and a signature segment. Security context segment
will be used to attach a security context object that can be used by peers for several
security related aspects. Signature context is a special segment that gets added at the end
of the segment that contains the computed signature of the content segments.
One sample segment trace on the wire will look like this.
[method][sec-context] [header] [body] [body] [signature
context]
The signed value will be computed by processing the various body
frames and appending a frame or multiple frames at the end. This
follows a logical step in how signature calculation/verification is
done.
AMQP spec defines notion of field tables that are table value pairs. We can use this
mechanism to carry the security context object in the segments to the other peer.
Field Table Definitions
The security context and the signature segment can carry table value pairs similar to the
header segment. We introduce the following types of table value pairs.
Field table values for security context frame
Name
E
Type
Zero length field
C
Variable length field
D
Zero length field
S
Zero length field
Comment
Indicates that the content
segment is encrypted, all
the content frames in this
segment are encrypted
This contains the actual
security context created as
part of this session
field indicates that content
has been signed
field indicates that header
has been signed
Field table values for signature context frame
Name
D
Type
Variable length field
A
Fixed length field
Comment
Indicates that this value pair
contains the signed value of
the content segments
Denotes the algorithm used
for computing the signature
Field table values for header frame
Name
S
Type
Variable length
A
Fixed length
Comment
Indicates that this value pair
contains the signed value of
the header
Denotes the algorithm used
for computing the signature