Network Working Group P. Karn
Request for Comments: 2522 Qualcomm
Category: EXPerimental W. Simpson
DayDreamer
March 1999
Photuris: Session-Key Management Protocol
Status of this Memo
This document defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn
and William Allen Simpson (1994-1999). All Rights Reserved.
Abstract
Photuris is a session-key management protocol intended for use with
the IP Security Protocols (AH and ESP). This document defines the
basic protocol mechanisms.
Table of Contents
1. IntrodUCtion .......................................... 1
1.1 Terminology ..................................... 1
1.2 Protocol Overview ............................... 3
1.3 Security Parameters ............................. 5
1.4 LifeTimes ....................................... 6
1.4.1 Exchange LifeTimes .............................. 6
1.4.2 SPI LifeTimes ................................... 7
1.5 Random Number Generation ........................ 8
2. Protocol Details ...................................... 9
2.1 UDP ............................................. 9
2.2 Header Format ................................... 10
2.3 Variable Precision Integers ..................... 11
2.4 Exchange-Schemes ................................ 13
2.5 Attributes ...................................... 13
3. Cookie Exchange ....................................... 14
3.0.1 Send Cookie_Request ............................. 14
3.0.2 Receive Cookie_Request .......................... 15
3.0.3 Send Cookie_Response ............................ 15
3.0.4 Receive Cookie_Response ......................... 16
3.1 Cookie_Request .................................. 17
3.2 Cookie_Response ................................. 18
3.3 Cookie Generation ............................... 19
3.3.1 Initiator Cookie ................................ 19
3.3.2 Responder Cookie ................................ 20
4. Value Exchange ........................................ 21
4.0.1 Send Value_Request .............................. 21
4.0.2 Receive Value_Request ........................... 22
4.0.3 Send Value_Response ............................. 22
4.0.4 Receive Value_Response .......................... 23
4.1 Value_Request ................................... 24
4.2 Value_Response .................................. 25
4.3 Offered Attribute List .......................... 26
5. Identification Exchange ............................... 28
5.0.1 Send Identity_Request ........................... 29
5.0.2 Receive Identity_Request ........................ 29
5.0.3 Send Identity_Response .......................... 30
5.0.4 Receive Identity_Response ....................... 30
5.1 Identity_Messages ............................... 31
5.2 Attribute Choices List .......................... 33
5.3 Shared-Secret ................................... 34
5.4 Identity Verification ........................... 34
5.5 Privacy-Key Computation ......................... 36
5.6 Session-Key Computation ......................... 37
6. SPI Messages .......................................... 38
6.0.1 Send SPI_Needed ................................. 38
6.0.2 Receive SPI_Needed .............................. 39
6.0.3 Send SPI_Update ................................. 39
6.0.4 Receive SPI_Update .............................. 39
6.0.5 Automated SPI_Updates ........................... 40
6.1 SPI_Needed ...................................... 41
6.2 SPI_Update ...................................... 43
6.2.1 Creation ........................................ 44
6.2.2 Deletion ........................................ 45
6.2.3 Modification .................................... 45
6.3 Validity Verification ........................... 45
7. Error Messages ........................................ 46
7.1 Bad_Cookie ...................................... 47
7.2 Resource_Limit .................................. 47
7.3 Verification_Failure ............................ 48
7.4 Message_Reject .................................. 49
8. Public Value Exchanges ................................ 50
8.1 Modular Exponentiation Groups ................... 50
8.2 Moduli Selection ................................ 50
8.2.1 Bootstrap Moduli ................................ 51
8.2.2 Learning Moduli ................................. 51
8.3 Generator Selection ............................. 51
8.4 Exponent Selection .............................. 52
8.5 Defective Exchange Values ....................... 53
9. Basic Exchange-Schemes ................................ 54
10. Basic Key-Generation-Function ......................... 55
10.1 MD5 Hash ........................................ 55
11. Basic Privacy-Method .................................. 55
11.1 Simple MaSKINg .................................. 55
12. Basic Validity-Method ................................. 55
12.1 MD5-IPMAC Check ................................. 55
13. Basic Attributes ...................................... 56
13.1 Padding ......................................... 56
13.2 AH-Attributes ................................... 57
13.3 ESP-Attributes .................................. 57
13.4 MD5-IPMAC ....................................... 58
13.4.1 Symmetric Identification ........................ 58
13.4.2 Authentication .................................. 59
13.5 Organizational .................................. 60
APPENDICES ................................................... 61
A. Automaton ............................................. 61
A.1 State Transition Table .......................... 62
A.2 States .......................................... 65
A.2.1 Initial ......................................... 65
A.2.2 Cookie .......................................... 66
A.2.3 Value ........................................... 66
A.2.4 Identity ........................................ 66
A.2.5 Ready ........................................... 66
A.2.6 Update .......................................... 66
B. Use of Identification and Secrets ..................... 67
B.1 Identification .................................. 67
B.2 Group Identity With Group Secret ................ 67
B.3 Multiple Identities With Group Secrets .......... 68
B.4 Multiple Identities With Multiple Secrets ....... 69
OPERATIONAL CONSIDERATIONS ................................... 70
SECURITY CONSIDERATIONS ...................................... 70
HISTORY ...................................................... 71
ACKNOWLEDGEMENTS ............................................. 72
REFERENCES ................................................... 73
CONTACTS ..................................................... 75
COPYRIGHT .................................................... 76
1. Introduction
Photuris [Firefly] establishes short-lived session-keys between two
parties, without passing the session-keys across the Internet. These
session-keys directly replace the long-lived secret-keys (such as
passWords and passphrases) that have been historically configured for
security purposes.
The basic Photuris protocol utilizes these existing previously
configured secret-keys for identification of the parties. This is
intended to speed deployment and reduce administrative configuration
changes.
This document is primarily intended for implementing the Photuris
protocol. It does not detail service and application interface
definitions, although it does mention some basic policy areas
required for the proper implementation and operation of the protocol
mechanisms.
Since the basic Photuris protocol is extensible, new data types and
protocol behaviour should be expected. The implementor is especially
cautioned not to depend on values that appear in examples to be
current or complete, since their purpose is primarily pedagogical.
1.1. Terminology
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC-2119].
byte An 8-bit quantity; also known as "octet" in
standardese.
exchange-value The publically distributable value used to calculate
a shared-secret. As used in this document, refers
to a Diffie-Hellman exchange, not the public part of
a public/private key-pair.
private-key A value that is kept secret, and is part of an
asymmetric public/private key-pair.
public-key A publically distributable value that is part of an
asymmetric public/private key-pair.
secret-key A symmetric key that is not publically
distributable. As used in this document, this is
distinguished from an asymmetric public/private
key-pair. An example is a user password.
Security Association (SA)
A collection of parameters describing the security
relationship between two nodes. These parameters
include the identities of the parties, the transform
(including algorithm and algorithm mode), the key(s)
(such as a session-key, secret-key, or appropriate
public/private key-pair), and possibly other
information such as sensitivity labelling.
Security Parameters Index (SPI)
A number that indicates a particular set of uni-
directional attributes used under a Security
Association, such as transform(s) and session-
key(s). The number is relative to the IP
Destination, which is the SPI Owner, and is unique
per IP (Next Header) Protocol. That is, the same
value MAY be used by multiple protocols to
concurrently indicate different Security Association
parameters.
session-key A key that is independently derived from a shared-
secret by the parties, and used for keying one
direction of traffic. This key is changed
frequently.
shared-secret As used in this document, the calculated result of
the Photuris exchange.
SPI Owner The party that corresponds to the IP Destination;
the intended recipient of a protected datagram.
SPI User The party that corresponds to the IP Source; the
sender of a protected datagram.
transform A cryptographic manipulation of a particular set of
data. As used in this document, refers to certain
well-specified methods (defined elsewhere). For
example, AH-MD5 [RFC-1828] transforms an IP datagram
into a cryptographic hash, and ESP-DES-CBC [RFC-
1829] transforms plaintext to ciphertext and back
again.
Many of these terms are hierarchically related:
Security Association (bi-directional)
- one or more lists of Security Parameters (uni-directional)
-- one or more Attributes
--- may have a key
--- may indicate a transform
Implementors will find details of cryptographic hashing (such as
MD5), encryption algorithms and modes (such as DES), digital
signatures (such as DSS), and other algorithms in [Schneier95].
1.2. Protocol Overview
The Photuris protocol consists of several simple phases:
1. A "Cookie" Exchange guards against simple flooding attacks sent
with bogus IP Sources or UDP Ports. Each party passes a "cookie"
to the other.
In return, a list of supported Exchange-Schemes are offered by the
Responder for calculating a shared-secret.
2. A Value Exchange establishes a shared-secret between the parties.
Each party passes an Exchange-Value to the other. These values
are used to calculate a shared-secret. The Responder remains
stateless until a shared-secret has been created.
In addition, supported attributes are offered by each party for
use in establishing new Security Parameters.
3. An Identification Exchange identifies the parties to each other,
and verifies the integrity of values sent in phases 1 and 2.
In addition, the shared-secret provides a basis to generate
separate session-keys in each direction, which are in turn used
for conventional authentication or encryption. Additional
security attributes are also exchanged as needed.
This exchange is masked for party privacy protection using a
message privacy-key based on the shared-secret. This protects the
identities of the parties, hides the Security Parameter attribute
values, and improves security for the exchange protocol and
security transforms.
4. Additional messages may be exchanged to periodically change the
session-keys, and to establish new or revised Security Parameters.
These exchanges are also masked for party privacy protection in
the same fashion as above.
The sequence of message types and their purposes are summarized in
the diagram below. The first three phases (cookie, exchange, and
identification) must be carried out in their entirety before any
Security Association can be used.
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
[generate shared-secret from exchanged values]
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
[make SPI session-keys in each direction]
SPI User SPI Owner
======== =========
SPI_Needed ->
list SPI attribute(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
<- SPI_Update
make SPI
pick SPI attribute(s)
make SPI session-key(s)
make validity key
authenticate
make privacy key(s)
mask/encrypt message
Either party may initiate an exchange at any time. For example, the
Initiator need not be a "caller" in a telephony link.
The Initiator is responsible for recovering from all message losses
by retransmission.
1.3. Security Parameters
A Photuris exchange between two parties results in a pair of SPI
values (one in each direction). Each SPI is used in creating
separate session-key(s) in each direction.
The SPI is assigned by the entity controlling the IP Destination: the
SPI Owner (receiver). The parties use the combination of IP
Destination, IP (Next Header) Protocol, and SPI to distinguish the
correct Security Association.
When both parties initiate Photuris exchanges concurrently, or one
party initiates more than one Photuris exchange, the Initiator
Cookies (and UDP Ports) keep the exchanges separate. This results in
more than one initial SPI for each Destination.
To create multiple SPIs with different parameters, the parties may
also send SPI_Updates.
There is no requirement that all such outstanding SPIs be used. The
SPI User (sender) selects an appropriate SPI for each datagram
transmission.
Implementation Notes:
The method used for SPI assignment is implementation dependent.
The only requirement is that the SPI be unique for the IP
Destination and IP (Next Header) Protocol.
However, selection of a cryptographically random SPI value can
help prevent attacks that depend on a predicatable sequence of
values. The implementor MUST NOT expect SPI values to have a
particular order or range.
1.4. LifeTimes
The Photuris exchange results in two kinds of state, each with
separate LifeTimes.
1) The Exchange LifeTime of the small amount of state associated with
the Photuris exchange itself. This state may be viewed as between
Internet nodes.
2) The SPI LifeTimes of the individual SPIs that are established.
This state may be viewed as between users and nodes.
The SPI LifeTimes may be shorter or longer than the Exchange
LifeTime. These LifeTimes are not required to be related to each
other.
When an Exchange-Value expires (or is replaced by a newer value), any
unexpired derived SPIs are not affected. This is important to allow
traffic to continue without interruption during new Photuris
exchanges.
1.4.1. Exchange LifeTimes
All retained exchange state of both parties has an associated
Exchange LifeTime (ELT), and is subject to periodic expiration. This
depends on the physical and logistical security of the machine, and
is typically in the range of 10 minutes to one day (default 30
minutes).
In addition, during a Photuris exchange, an Exchange TimeOut (ETO)
limits the wait for the exchange to complete. This timeout includes
the packet round trips, and the time for completing the
Identification Exchange calculations. The time is bounded by both
the maximum amount of calculation delay expected for the processing
power of an unknown peer, and the minimum user expectation for
results (default 30 seconds).
These Exchange LifeTimes and TimeOuts are implementation dependent
and are not disclosed in any Photuris message. The paranoid operator
will have a fairly short Exchange LifeTime, but it MUST NOT be less
than twice the ETO.
To prevent synchronization between Photuris exchanges, the
implementation SHOULD randomly vary each Exchange LifeTime within
twice the range of seconds that are required to calculate a new
Exchange-Value. For example, when the Responder uses a base ELT of
30 minutes, and takes 10 seconds to calculate the new Exchange-Value,
the equation might be (in milliseconds):
1790000 + urandom(20000)
The Exchange-Scheme, Exchange-Values, and resulting shared-secret MAY
be cached in short-term storage for the Exchange LifeTime. When
repetitive Photuris exchanges occur between the same parties, and the
Exchange-Values are discovered to be unchanged, the previously
calculated shared-secret can be used to rapidly generate new
session-keys.
1.4.2. SPI LifeTimes
Each SPI has an associated LifeTime, specified by the SPI owner
(receiver). This SPI LifeTime (SPILT) is usually related to the
speed of the link (typically 2 to 30 minutes), but it MUST NOT be
less than thrice the ETO.
The SPI can also be deleted by the SPI Owner using the SPI_Update.
Once the SPI has expired or been deleted, the parties cease using the
SPI.
To prevent synchronization between multiple Photuris exchanges, the
implementation SHOULD randomly vary each SPI LifeTime. For example,
when the Responder uses a base SPILT of 5 minutes, and 30 seconds for
the ETO, the equation might be (in milliseconds):
285000 + urandom(30000)
There is no requirement that a long LifeTime be accepted by the SPI
User. The SPI User might never use an established SPI, or cease
using the SPI at any time.
When more than one unexpired SPI is available to the SPI User for the
same function, a common implementation technique is to select the SPI
with the greatest remaining LifeTime. However, selecting randomly
among a large number of SPIs might provide some defense against
traffic analysis.
To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD
remember those SPIs, but mark them as unusable until the Photuris
exchange shared-secret used to create them also expires and purges
the associated state.
When the SPI Owner detects an incoming SPI that has recently expired,
but the associated exchange state has not yet been purged, the
implementation MAY accept the SPI. The length of time allowed is
highly dependent on clock drift and variable packet round trip time,
and is therefore implementation dependent.
1.5. Random Number Generation
The security of Photuris critically depends on the quality of the
secret random numbers generated by each party. A poor random number
generator at either party will compromise the shared-secret produced
by the algorithm.
Generating cryptographic quality random numbers on a general purpose
computer without hardware assistance is a very tricky problem. In
general, this requires using a cryptographic hashing function to
"distill" the entropy from a large number of semi-random external
events, such as the timing of key strokes. An Excellent discussion
can be found in [RFC-1750].
2. Protocol Details
The Initiator begins a Photuris exchange under several circumstances:
- The Initiator has a datagram that it wishes to send with
confidentiality, and has no current Photuris exchange state with
the IP Destination. This datagram is discarded, and a
Cookie_Request is sent instead.
- The Initiator has received the ICMP message [RFC-1812] Destination
Unreachable: Communication Administratively Prohibited (Type 3,
Code 13), and has no current Photuris exchange state with the ICMP
Source.
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Bad SPI (Type 40, Code 0), that matches current Photuris
exchange state with the ICMP Source.
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Need Authentication (Type 40, Code 4), and has no
current Photuris exchange state with the ICMP Source.
- The Initiator has received the ICMP message [RFC-2521] Security
Failures: Need Authorization (Type 40, Code 5), that matches
current Photuris exchange state with the ICMP Source.
When the event is an ICMP message, special care MUST be taken that
the ICMP message actually includes information that matches a
previously sent IP datagram. Otherwise, this could provide an
opportunity for a clogging attack, by stimulating a new Photuris
Exchange.
2.1. UDP
All Photuris messages use the User Datagram Protocol header [RFC-
768]. The Initiator sends to UDP Destination Port 468.
When replying to the Initiator, the Responder swaps the IP Source and
Destination, and the UDP Source and Destination Ports.
The UDP checksum MUST be correctly calculated when sent. When a
message is received with an incorrect UDP checksum, it is silently
discarded.
Implementation Notes:
It is expected that installation of Photuris will ensure that UDP
checksum calculations are enabled for the computer operating
system and later disabling by operators is prevented.
Internet Protocol version 4 [RFC-791] restricts the maximum
reassembled datagram to 576 bytes.
When processing datagrams containing variable size values, the
length must be checked against the overall datagram length. An
invalid size (too long or short) that causes a poorly coded
receiver to abort could be used as a denial of service attack.
2.2. Header Format
All of the messages have a format similar to the following, as
transmitted left to right in network order (most significant to least
significant):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message
+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes.
Responder-Cookie 16 bytes.
Message 1 byte. Each message type has a unique value.
Initial values are assigned as follows:
0 Cookie_Request
1 Cookie_Response
2 Value_Request
3 Value_Response
4 Identity_Request
5 Secret_Response (optional)
6 Secret_Request (optional)
7 Identity_Response
8 SPI_Needed
9 SPI_Update
10 Bad_Cookie
11 Resource_Limit
12 Verification_Failure
13 Message_Reject
Further details and differences are elaborated in the individual
messages.
2.3. Variable Precision Integers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Size 2, 4, or 8 bytes. The number of significant bits
used in the Value field. Always transmitted most
significant byte first.
When the Size is zero, no Value field is present;
there are no significant bits. This means "missing"
or "null". It should not be confused with the value
zero, which includes an indication of the number of
significant bits.
When the most significant byte is in the range 0
through 254 (0xfe), the field is 2 bytes. Both
bytes are used to indicate the size of the Value
field, which ranges from 1 to 65,279 significant
bits (in 1 to 8,160 bytes).
When the most significant byte is 255 (0xff), the
field is 4 bytes. The remaining 3 bytes are added
to 65,280 to indicate the size of the Value field,
which is limited to 16,776,959 significant bits (in
2,097,120 bytes).
When the most significant 2 bytes are 65,535
(0xffff), the field is 8 bytes. The remaining 6
bytes are added to 16,776,960 to indicate the size
of the Value field.
Value 0 or more bytes. Always transmitted most
significant byte first.
The bits used are right justified within byte
boundaries; that is, any unused bits are in the most
significant byte. When there are no unused bits, or
unused bits are zero filled, the value is assumed to
be an unsigned positive integer.
When the leading unused bits are ones filled, the
number is assumed to be a two"s-complement negative
integer. A negative integer will always have at
least one unused leading sign bit in the most
significant byte.
Shortened forms SHOULD NOT be used when the Value includes a number
of leading zero significant bits. The Size SHOULD indicate the
correct number of significant bits.
Implementation Notes:
Negative integers are not required to be supported, but are
included for completeness.
No more than 65,279 significant bits are required to be supported.
Other ranges are vastly too long for these UDP messages, but are
included for completeness.
2.4. Exchange-Schemes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme Size
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scheme 2 bytes. A unique value indicating the Exchange-
Scheme. See the "Basic Exchange-Schemes" for
details.
Size 2 bytes, ranging from 0 to 65,279. See "Variable
Precision Integer".
Value 0 or more bytes. See "Variable Precision Integer".
The Size MUST NOT be assumed to be constant for a particular Scheme.
Multiple kinds of the same Scheme with varying Sizes MAY be present
in any list of schemes.
However, only one of each Scheme and Size combination will be present
in any list of schemes.
2.5. Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Length Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 1 byte. A unique value indicating the kind of
attribute. See the "Basic Attributes" for details.
When the value is zero (padding), no Length field is
present (always zero).
Length 1 byte. The size of the Value(s) field in bytes.
When the Length is zero, no Value(s) field is
present.
Value(s) 0 or more bytes. See the "Basic Attributes" for
details.
The Length MUST NOT be assumed to be constant for a particular
Attribute. Multiple kinds of the same Attribute with varying Lengths
MAY be present in any list of attributes.
3. Cookie Exchange
Initiator Responder
========= =========
Cookie_Request ->
<- Cookie_Response
offer schemes
3.0.1. Send Cookie_Request
The Initiator initializes local state, and generates a unique
"cookie". The Initiator-Cookie MUST be different in each new
Cookie_Request between the same parties. See "Cookie Generation" for
details.
- If any previous exchange between the peer IP nodes has not expired
in which this party was the Initiator, this Responder-Cookie is
set to the most recent Responder-Cookie, and this Counter is set
to the corresponding Counter.
For example, a new Virtual Private Network (VPN) tunnel is about
to be established to an existing partner. The Counter is the same
value received in the prior Cookie_Response, the Responder-Cookie
remains the same, and a new Initiator-Cookie is generated.
- If the new Cookie_Request is in response to a message of a
previous exchange in which this party was the Responder, this
Responder-Cookie is set to the previous Initiator-Cookie, and this
Counter is set to zero.
For example, a Bad_Cookie message was received from the previous
Initiator in response to SPI_Needed. The Responder-Cookie is
replaced with the Initiator-Cookie, and a new Initiator-Cookie is
generated. This provides bookkeeping to detect bogus Bad_Cookie
messages.
Also, can be used for bi-directional User, Transport, and Process
oriented keying. Such mechanisms are outside the scope of this
document.
- Otherwise, this Responder-Cookie and Counter are both set to zero.
By default, the Initiator operates in the same manner as when all
of its previous exchange state has expired. The Responder will
send a Resource_Limit when its own exchange state has not expired.
The Initiator also starts a retransmission timer. If no valid
Cookie_Response arrives within the time limit, the same
Cookie_Request is retransmitted for the remaining number of
Retransmissions. The Initiator-Cookie value MUST be the same in each
such retransmission to the same IP Destination and UDP Port.
When Retransmissions have been exceeded, if a Resource_Limit message
has been received during the exchange, the Initiator SHOULD begin the
Photuris exchange again by sending a new Cookie_Request with updated
values.
3.0.2. Receive Cookie_Request
On receipt of a Cookie_Request, the Responder determines whether
there are sufficient resources to begin another Photuris exchange.
- When too many SPI values are already in use for this particular
peer, or too many concurrent exchanges are in progress, or some
other resource limit is reached, a Resource_Limit message is sent.
- When any previous exchange initiated by this particular peer has
not exceeded the Exchange TimeOut, and the Responder-Cookie does
not specify one of these previous exchanges, a Resource_Limit
message is sent.
Otherwise, the Responder returns a Cookie_Response.
Note that the Responder creates no additional state at this time.
3.0.3. Send Cookie_Response
The IP Source for the Initiator is examined. If any previous
exchange between the peer IP nodes has not expired, the response
Counter is set to the most recent exchange Counter plus one (allowing
for out of order retransmissions). Otherwise, the response Counter
is set to the request Counter plus one.
If (through rollover of the Counter) the new Counter value is zero
(modulo 256), the value is set to one.
If this new Counter value matches some previous exchange initiated by
this particular peer that has not yet exceeded the Exchange TimeOut,
the Counter is incremented again, until a unique Counter value is
reached.
Nota Bene:
No more than 254 concurrent exchanges between the same two peers
are supported.
The Responder generates a unique cookie. The Responder-Cookie value
in each successive response SHOULD be different. See "Cookie
Generation" for details.
The Exchange-Schemes available between the peers are listed in the
Offered-Schemes.
3.0.4. Receive Cookie_Response
The Initiator validates the Initiator-Cookie, and the Offered-
Schemes.
- When an invalid/expired Initiator-Cookie is detected, the message
is silently discarded.
- When the variable length Offered-Schemes do not match the UDP
Length, or all Offered-Schemes are obviously defective and/or
insufficient for the purposes intended, the message is silently
discarded; the implementation SHOULD log the occurance, and notify
an operator as appropriate.
- Once a valid message has been received, later Cookie_Responses
with matching Initiator-Cookies are also silently discarded, until
a new Cookie_Request is sent.
When the message is valid, an Exchange-Scheme is chosen from the list
of Offered-Schemes.
This Scheme-Choice may affect the next Photuris message sent. By
default, the next Photuris message is a Value_Request.
Implementation Notes:
Only the Initiator-Cookie is used to identify the exchange. The
Counter and Responder-Cookie will both be different from the
Cookie_Request.
Various proposals for extensions utilize the Scheme-Choice to
indicate a different message sequence. Such mechanisms are
outside the scope of this document.
3.1. Cookie_Request
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Counter
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. A randomized value that identifies the
exchange. The value MUST NOT be zero. See "Cookie
Generation" for details.
Responder-Cookie 16 bytes. Identifies a specific previous exchange.
Copied from a previous Cookie_Response.
When zero, no previous exchange is specified.
When non-zero, and the Counter is zero, contains the
Initiator-Cookie of a previous exchange. The
specified party is requested to be the Responder in
this exchange, to retain previous party pairings.
When non-zero, and the Counter is also non-zero,
contains the Responder-Cookie of a previous
exchange. The specified party is requested to be
the Responder in this exchange, to retain previous
party pairings.
Message 0
Counter 1 byte. Indicates the number of previous exchanges.
When zero, the Responder-Cookie indicates the
Initiator of a previous exchange, or no previous
exchange is specified.
When non-zero, the Responder-Cookie indicates the
Responder to a previous exchange. This value is set
to the Counter from the corresponding
Cookie_Response or from a Resource_Limit.
3.2. Cookie_Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Counter Offered-Schemes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Cookie_Request.
Responder-Cookie 16 bytes. A randomized value that identifies the
exchange. The value MUST NOT be zero. See "Cookie
Generation" for details.
Message 1
Counter 1 byte. Indicates the number of the current
exchange. Must be greater than zero.
Offered-Schemes 4 or more bytes. A list of one or more Exchange-
Schemes supported by the Responder, ordered from
most to least preferable. See the "Basic Exchange-
Schemes" for details.
Only one Scheme (#2) is required to be supported,
and SHOULD be present in every Offered-Schemes list.
More than one of each kind of Scheme may be offered,
but each is distinguished by its Size. The end of
the list is indicated by the UDP Length.
3.3. Cookie Generation
The exact technique by which a Photuris party generates a cookie is
implementation dependent. The method chosen must satisfy some basic
requirements:
1. The cookie MUST depend on the specific parties. This prevents an
attacker from oBTaining a cookie using a real IP address and UDP
port, and then using it to swamp the victim with requests from
randomly chosen IP addresses or ports.
2. It MUST NOT be possible for anyone other than the issuing entity
to generate cookies that will be accepted by that entity. This
implies that the issuing entity will use local secret information
in the generation and subsequent verification of a cookie. It
must not be possible to deduce this secret information from any
particular cookie.
3. The cookie generation and verification methods MUST be fast to
thwart attacks intended to sabotage CPU resources.
A recommended technique is to use a cryptographic hashing function
(such as MD5).
An incoming cookie can be verified at any time by regenerating it
locally from values contained in the incoming datagram and the local
secret random value.
3.3.1. Initiator Cookie
The Initiator secret value that affects its cookie SHOULD change for
each new Photuris exchange, and is thereafter internally cached on a
per Responder basis. This provides improved synchronization and
protection against replay attacks.
An alternative is to cache the cookie instead of the secret value.
Incoming cookies can be compared directly without the computational
cost of regeneration.
It is recommended that the cookie be calculated over the secret
value, the IP Source and Destination addresses, and the UDP Source
and Destination ports.
Implementation Notes:
Although the recommendation includes the UDP Source port, this is
very implementation specific. For example, it might not be
included when the value is constant.
However, it is important that the implementation protect mutually
suspicious users of the same machine from generating the same
cookie.
3.3.2. Responder Cookie
The Responder secret value that affects its cookies MAY remain the
same for many different Initiators. However, this secret SHOULD be
changed periodically to limit the time for use of its cookies
(typically each 60 seconds).
The Responder-Cookie SHOULD include the Initiator-Cookie. The
Responder-Cookie MUST include the Counter (that is returned in the
Cookie_Response). This provides improved synchronization and
protection against replay attacks.
It is recommended that the cookie be calculated over the secret
value, the IP Source and Destination addresses, its own UDP
Destination port, the Counter, the Initiator-Cookie, and the
currently Offered-Schemes.
The cookie is not cached per Initiator to avoid saving state during
the initial Cookie Exchange. On receipt of a Value_Request
(described later), the Responder regenerates its cookie for
validation.
Once the Value_Response is sent (also described later), both
Initiator and Responder cookies are cached to identify the exchange.
Implementation Notes:
Although the recommendation does not include the UDP Source port,
this is very implementation specific. It might be successfully
included in some variants.
However, it is important that the UDP Source port not be included
when matching existing Photuris exchanges for determining the
appropriate Counter.
The recommendation includes the Offered-Schemes to detect a
dynamic change of scheme value between the Cookie_Response and
Value_Response.
Some mechanism MAY be needed to detect a dynamic change of pre-
calculated Responder Exchange-Value between the Value_Response and
Identity_Response. For example, change the secret value to render
the cookie invalid, or explicitly mark the Photuris exchange state
as expired.
4. Value Exchange
Initiator Responder
========= =========
Value_Request ->
pick scheme
offer value
offer attributes
<- Value_Response
offer value
offer attributes
[generate shared-secret from exchanged values]
4.0.1. Send Value_Request
The Initiator generates an appropriate Exchange-Value for the
Scheme-Choice. This Exchange-Value may be pre-calculated and used
for multiple Responders.
The IP Destination for the Responder is examined, and the attributes
available between the parties are listed in the Offered-Attributes.
The Initiator also starts a retransmission timer. If no valid
Value_Response arrives within the time limit, the same Value_Request
is retransmitted for the remaining number of Retransmissions.
When Retransmissions have been exceeded, if a Bad_Cookie or
Resource_Limit message has been received during the exchange, the
Initiator SHOULD begin the Photuris exchange again by sending a new
Cookie_Request.
4.0.2. Receive Value_Request
The Responder validates the Responder-Cookie, the Counter, the
Scheme-Choice, the Exchange-Value, and the Offered-Attributes.
- When an invalid/expired Responder-Cookie is detected, a Bad_Cookie
message is sent.
- When too many SPI values are already in use for this particular
peer, or too many concurrent exchanges are in progress, or some
other resource limit is reached, a Resource_Limit message is sent.
- When an invalid Scheme-Choice is detected, or the Exchange-Value
is obviously defective, or the variable length Offered-Attributes
do not match the UDP Length, the message is silently discarded;
the implementation SHOULD log the occurance, and notify an
operator as appropriate.
When the message is valid, the Responder sets its Exchange timer to
the Exchange TimeOut, and returns a Value_Response.
The Responder keeps a copy of the incoming Value_Request cookie pair,
and its Value_Response. If a duplicate Value_Request is received, it
merely resends its previous Value_Response, and takes no further
action.
4.0.3. Send Value_Response
The Responder generates an appropriate Exchange-Value for the
Scheme-Choice. This Exchange-Value may be pre-calculated and used
for multiple Initiators.
The IP Source for the Initiator is examined, and the attributes
available between the parties are listed in the Offered-Attributes.
Implementation Notes:
At this time, the Responder begins calculation of the shared-
secret. Calculation of the shared-secret is executed in parallel
to minimize delay.
This may take a substantial amount of time. The implementor
should ensure that retransmission is not blocked by this
calculation. This is not usually a problem, as retransmission
timeouts typically exceed calculation time.
4.0.4. Receive Value_Response
The Initiator validates the pair of Cookies, the Exchange-Value, and
the Offered-Attributes.
- When an invalid/expired cookie is detected, the message is
silently discarded.
- When the Exchange-Value is obviously defective, or the variable
length Offered-Attributes do not match the UDP Length, the message
is silently discarded; the implementation SHOULD log the
occurance, and notify an operator as appropriate.
- Once a valid message has been received, later Value_Responses with
both matching cookies are also silently discarded, until a new
Cookie_Request is sent.
When the message is valid, the Initiator begins its parallel
computation of the shared-secret.
When the Initiator completes computation, it sends an
Identity_Request to the Responder.
4.1. Value_Request
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Counter Scheme-Choice
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Exchange-Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Cookie_Response.
Responder-Cookie 16 bytes. Copied from the Cookie_Response.
Message 2
Counter 1 byte. Copied from the Cookie_Response.
Scheme-Choice 2 bytes. A value selected by the Initiator from the
list of Offered-Schemes in the Cookie_Response.
Only the Scheme is specified; the Size will match
the Initiator-Exchange-Value, and the Value(s) are
implicit.
Initiator-Exchange-Value
Variable Precision Integer. Provided by the
Initiator for calculating a shared-secret between
the parties. The Value format is indicated by the
Scheme-Choice.
The field may be any integral number of bytes in
length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
Initiator-Offered-Attributes
4 or more bytes. A list of Security Parameter
attributes supported by the Initiator.
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
4.2. Value_Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Reserved
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Exchange-Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Responder-Offered-Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Initiator-Cookie 16 bytes. Copied from the Value_Request.
Responder-Cookie 16 bytes. Copied from the Value_Request.
Message 3
Reserved 3 bytes. For future use; MUST be set to zero when
transmitted, and MUST be ignored when received.
Responder-Exchange-Value
Variable Precision Integer. Provided by the
Responder for calculating a shared-secret between
the parties. The Value format is indicated by the
current Scheme-Choice specified in the
Value_Request.
The field may be any integral number of bytes in
length, as indicated by its Size field. It does not
require any particular alignment. The 32-bit
alignment shown is for convenience in the
illustration.
Responder-Offered-Attributes
4 or more bytes. A list of Security Parameter
attributes supported by the Responder.
The contents and usage of this list are further
described in "Offered Attributes List". The end of
the list is indicated by the UDP Length.
4.3. Offered Attribute List
This list includes those attributes supported by the party that are
available to the other party. The attribute formats are specified in
the "Basic Attributes".
The list is composed of two or three sections: Identification-
Attributes, Authentication-Attributes, and (optional) Encapsulation-
Attributes. Within each section, the attributes are ordered from
most to least preferable.
The first section of the list includes methods of identification. An
Identity-Choice is selected from this list.
The second section of the list begins with "AH-Attributes" (#1). It
includes methods of authentication, and other operational types.
The third section of the list begins with "ESP-Attributes" (#2). It
includes methods of authentication, compression, encryption, and
other operational types. When no Encapsulation-Attributes are
offered, the "ESP-Attributes" attribute itself is omitted from the
list.
Attribute-Choices are selected from the latter two sections of the
list.
Support is required for the "MD5-IPMAC" (#5) attribute for both
"Symmetric Identification" and "Authentication" and they SHOULD be
present in every Offered-Attributes list.
Implementation Notes:
For example,
"MD5-IPMAC" (Symmetric Identification),
"AH-Attributes",
"MD5-IPMAC" (Authentication).
Since the offer is made by the prospective SPI User (sender),
order of preference likely reflects the capabilities and
engineering tradeoffs of a particular implementation.
However, the critical processing bottlenecks are frequently in the
receiver. The SPI Owner (receiver) may express its needs by
choosing a less preferable attribute.
The order may also be affected by operational policy and requested
services for an application. Such considerations are outside the
scope of this document.
The list may be divided into additional sections. These sections
will always follow the ESP-Attributes section, and are
indistinguishable from unrecognized attributes.
The authentication, compression, encryption and identification
mechanisms chosen, as well as the encapsulation modes (if any),
need not be the same in both directions.
5. Identification Exchange
Initiator Responder
========= =========
Identity_Request ->
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
<- Identity_Response
make SPI
pick SPI attribute(s)
identify self
authenticate
make privacy key(s)
mask/encrypt message
[make SPI session-keys in each direction]
The exchange of messages is ordered, although the formats and
meanings of the messages are identical in each direction. The
messages are easily distinguished by the parties themselves, by
examining the Message and Identification fields.
Implementation Notes:
The amount of time for the calculation may be dependent on the
value of particular bits in secret values used in generating the
shared-secret or identity verification. To prevent analysis of
these secret bits by recording the time for calculation, sending
of the Identity_Messages SHOULD be delayed until the time expected
for the longest calculation. This will be different for different
processor speeds, different algorithms, and different length
variables. Therefore, the method for estimating time is
implementation dependent.
Any authenticated and/or encrypted user datagrams received before
the completion of identity verification can be placed on a queue
pending completion of this step. If verification succeeds, the
queue is processed as though the datagrams had arrived subsequent
to the verification. If verification fails, the queue is
discarded.
5.0.1. Send Identity_Request
The Initiator chooses an appropriate Identification, the SPI and
SPILT, a set of Attributes for the SPI, calculates the Verification,
and masks the message using the Privacy-Method indicated by the
current Scheme-Choice.
The Initiator also starts a retransmission timer. If no valid
Identity_Response arrives within the time limit, its previous
Identity_Request is retransmitted for the remaining number of
Retransmissions.
When Retransmissions have been exceeded, if a Bad_Cookie message has
been received during the exchange, the Initiator SHOULD begin the
Photuris exchange again by sending a new Cookie_Request.
5.0.2. Receive Identity_Request
The Responder validates the pair of Cookies, the Padding, the
Identification, the Verification, and the Attribute-Choices.
- When an invalid/expired cookie is detected, a Bad_Cookie message
is sent.
- After unmasking, when invalid Padding is detected, the variable
length Attribute-Choices do not match the UDP Length, or an
attribute was not in the Offered-Attributes, the message is
silently discarded.
- When an invalid Identification is detected, or the message
verification fails, a Verification_Failure message is sent.
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
When the message is valid, the Responder sets its Exchange timer to
the Exchange LifeTime (if this has not already been done for a
previous exchange). When its parallel computation of the shared-
secret is complete, the Responder returns an Identity_Response.
The Responder keeps a copy of the incoming Identity_Request values,
and its Identity_Response. If a duplicate Identity_Request is
received, it merely resends its previous Identity_Response, and takes
no further action.
5.0.3. Send Identity_Response
The Responder chooses an appropriate Identification, the SPI and
SPILT, a set of Attributes for the SPI, calculates the Verification,
and masks the message using the Privacy-Method indicated by the
current Scheme-Choice.
The Responder calculates the SPI session-keys in both directions.
At this time, the Responder begins the authentication and/or
encryption of user datagrams.
5.0.4. Receive Identity_Response
The Initiator validates the pair of Cookies, the Padding, the
Identification, the Verification, and the Attribute-Choices.
- When an invalid/expired cookie is detected, the message is
silently discarded.
- After unmasking, when invalid Padding is detected, the variable
length Attribute-Choices do not match the UDP Length, or an
attribute was not in the Offered-Attributes, the message is
silently discarded.
- When an invalid Identification is detected, or the message
verification fails, a Verification_Failure message is sent.
- Whenever such a problem is detected, the Security Association is
not established; the implementation SHOULD log the occurance, and
notify an operator as appropriate.
- Once a valid message has been received, later Identity_Responses
with both matching cookies are also silently discarded, until a
new Cookie_Request is sent.
When the message is valid, the Initiator sets its Exchange timer to
the Exchange LifeTime (if this has not already been done for a
previous exchange).
The Initiator calculates the SPI session-keys in both directions.
At this time, the Initiator begins the authentication and/or
encryption of user datagrams.
5.1. Identity_Messages
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initiator-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Responder-Cookie ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message LifeTime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security-Parameters-Index
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Identity-Choice
+ + + + + + + + + + + + + + + + + +
~ Identification ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Verification ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute-Choices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiator-Cookie 16 bytes. Copied from the Value_Request.
Responder-Cookie 16 bytes. Copied from the Value_Request.
Message 4 (Request) or 7 (Response)
LifeTime 3 bytes. The number of seconds remaining before the
indicated SPI expires.
When the SPI is zero, this field MUST be filled with
a random non-zero value.
Security-Parameters-Index (SPI)
4 bytes. The SPI to be used for incoming
communications.
When zero, indicates that no SPI is created in this
direction.
Identity-Choice 2 or more bytes. An identity attribute is selected
from the list of Offered-Attributes sent by the
peer, and is used to calculate the Verification.
The field may be any integral number of bytes in
length, as indicated by its Length field. It does
not require any particular alignment. The 16-bit
alignment shown is for convenience in the
illustration.
Identification Variable Precision Integer, or alternative format
indicated by the Identity-Choice. See the "Basic
Attributes" for details.
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Verification Variable Precision Integer, or alternative format
indicated by the Identity-Choice. The calculation
of the value is described in "Identity
Verification".
The field may be any integral number of bytes in
length. It does not require any particular
alignment. The 32-bit alignment shown is for
convenience in the illustration.
Attribute-Choices
0 or more bytes. When the SPI is non-zero, a list
of attributes selected from the list of Offered-
Attributes supported by the peer.
The contents and usage of this list are further
described in "Attribute Choices List". The end of
the list is indicated by the UDP Length after
removing the Padding (UDP Length - last Padding
value).
Padding 8 to 255 bytes. This field is filled up to at least
a 128 byte boundary, measured from the beginning of
the message. The number of pad bytes are chosen
randomly.
In addition, when a Privacy-Method indicated by the
current Scheme-Choice requires the plaintext to be a
multiple of some number of bytes (the block size of
a block cipher), this field is adjusted as necessary
to the size required by the algorithm.
Self-Describing-Padding begins with the value 1.
Each byte contains the index of that byte. Thus,
the final pad byte indicates the number of pad bytes
to remove. For example, when the unpadded message
length is 120 bytes, the padding values might be 1,
2, 3, 4, 5, 6, 7, and 8.
The portion of the message after the SPI field is masked using the
Privacy-Method indicated by the current Scheme-Choice.
The fields following the SPI are opaque. That is, the values are set
prior to masking (and optional encryption), and examined only after
unmasking (and optional decryption).
5.2. Attribute Choices List
This list specifies the attributes of the SPI. The attribute formats
are specified in the "Basic Attributes".
The list is composed of one or two sections: Authentication-
Attributes, and/or Encapsulation-Attributes.
When sending from the SPI User to the SPI Owner, the attributes are
processed in the order listed. For example,
"ESP-Attributes",
"Deflate" (Compression),
"XOR" (Encryption),
"DES-CBC" (Encryption),
"XOR" (Encryption),
"AH-Attributes",
"AH-Sequence",
"MD5-IPMAC" (Authentication),
would result in ESP with compression and triple encryption (inside),
and then AH authentication with sequence numbers (outside) of the ESP
payload.
The SPI Owner will naturally process the datagram in the reverse
order.
This ordering also affects the order of key generation. Both SPI
Owner and SPI User generate the keys in the order listed.
Implementation Notes:
When choices are made from the list of Offered-Attributes, it is
not required that any Security Association include every kind of
offered attribute in any single SPI, or that a separate SPI be
created for every offered attribute.
Some kinds of attributes may be included more than once in a
single SPI. The set of allowable combinations of attributes are
dependent on implementation and operational policy. Such
considerations are outside the scope of this document.
The list may be divided into additional sections. This can occur
only when both parties recognize the affected attributes.
The authentication, compression, encryption and identification
mechanisms chosen, as well as the encapsulation modes (if any),
need not be the same in both directions.
5.3. Shared-Secret
A shared-secret is used in a number of calculations. Regardless of
the internal representation of the shared-secret, when used in
calculations it is in the same form as the Value part of a Variable
Precision Integer:
- most significant byte first.
- bits used are right justified within byte boundaries.
- any unused bits are in the most significant byte.
- unused bits are zero filled.
The shared-secret does not include a Size field.
5.4. Identity Verification
These messages are authenticated using the Identity-Choice. The
Verification value is calculated prior to masking (and optional
encryption), and verified after unmasking (and optional decryption).
The Identity-Choice authentication function is supplied with two
input values:
- the sender (SPI Owner) verification-key,
- the data to be verified (as a concatenated sequence of bytes).
The resulting output value is stored in the Verification field.
The Identity-Choice verification data consists of the following
concatenated values:
+ the Initiator Cookie,
+ the Responder Cookie,
+ the Message, LifeTime and SPI fields,
+ the Identity-Choice and Identification,
+ the SPI User Identity Verification (response only),
+ the Attribute-Choices following the Verification field,
+ the Padding,
+ the SPI Owner TBV,
+ the SPI Owner Exchange-Value,
+ the SPI Owner Offered-Attributes,
+ the SPI User TBV,
+ the SPI User Exchange-Value,
+ the SPI User Offered-Attributes,
+ the Responder Offered-Schemes.
The TBV (Three Byte Value) consists of the Counter and Scheme-Choice
fields from the Value_Request, or the Reserved field from the
Val
