📄 rfc2522.txt
字号:
(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,
Karn & Simpson Experimental [Page 15]
RFC 2522 Photuris Protocol March 1999
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.
Karn & Simpson Experimental [Page 16]
RFC 2522 Photuris Protocol March 1999
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.
Karn & Simpson Experimental [Page 17]
RFC 2522 Photuris Protocol March 1999
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.
Karn & Simpson Experimental [Page 18]
RFC 2522 Photuris Protocol March 1999
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.
Karn & Simpson Experimental [Page 19]
RFC 2522 Photuris Protocol March 1999
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
Karn & Simpson Experimental [Page 20]
RFC 2522 Photuris Protocol March 1999
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.
Karn & Simpson Experimental [Page 21]
RFC 2522 Photuris Protocol March 1999
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -