[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rescert] Another attempt to round off the IR-ISP protocol
United Airlines decided that I'd rather spend this afternoon in
various Red Carpet clubs than on Bainbridge island, so here are the
detailed notes from this proofreading pass.
> Messages will be processed by the server in order of increasing
> msg_ref values, and detected out-of-order requests and duplicate
> requests will not be processed by the server, and will, instead,
> generate an error response.
I'm pretty sure this is incorrect. We we're not talking about
buffering out-of-order messages (the way that TCP does with
out-of-order segments), so I'd rephrase this as:
Messages will be processed by the server in the order received;
detected out-of-order and duplicate requests will not be processed
by the server, and will, instead, generate an error response.
> Messages are checked using the following tests:
>
> 1. Check that the CMS is well-formed
>
> 2. Check that the XML is well-formed
>
> 3. Check that the XML sender and recipient attributes reference a known
> client and this system respectively.
>
> 4. Verify the digital signature using the public key provided in the
> certificate carried in the CMS
>
> 5. Validate the CMS-provided certificate using the Business PKI that is
> associated with the sender
>
> 6. Use the XML msg_ref and CMS Signing_Time attribute values to detect
> that this message is correctly in sequence (using the algorithm
> described below)
>
> 7. The value of the version number of the message is 1.
Check #7 seems much too late. I'd put it just after check #2; if we
don't even understand the protocol version, there's not much point in
doing database lookups or signature checks.
If you buy the arguments from my previous message, the phrase "and CMS
Signing_Time attribute values" goes away (ie, we don't need to
synchronize clocks).
> Errors in tests 1 through 5 would generate an HTTP 400 Bad Data response.
> An error in steps 6 or 7 would generate a "Request-Not-Performed"
> response.
I think it would be fine for check #7 above to generate HTTP 400,
although I could be persuaded that it should generate a
Request-Not-Performed with a code of "wrong version".
The next chunk of text after this is all about the replay protection
algorithm, which I now think can be simplified quite a bit, as follows:
> Duplicate message detection relies on the server and client both
> running an absolute time clock (i.e. a clock that can produce a time
> value to a level of granularity of seconds or finer).
Delete, don't need synchronized clocks.
> The server holds per-client stored last_msg_ref values (initially set
> to 0), and per-client stored last_msg_time values (initially set to 0)
> and two statically configured time interval values, the reset_interval
> value and the allowed_clock_skew_interval value.
Change tail of this sentence to:
and one statically configured time interval value, the reset_interval.
> - The client passes its clock value to the server via the Signing
> Time attribute of the CMS message wrapper (see above).
Delete. CMS is going to stick a timestamp in there anyway, but this
protocol doesn't care anymore.
> - The server checks if the message is within the allowable clock
> skew. If the server detects that the received Signing Time is
> outside of the server's clock +/- allowed_clock_skew_interval, then
> the message is rejected]] with a time error. The server's clock
> value is communicated to the client via the Signing Time attribute
> of the CMS message wrapper in the response.
Delete, not needed.
> - The server checks that the msg_ref value is valid. If the message's
> msg_ref value is 0, or negative, then the message is rejected with
> an invalid msg_ref code, and the server's value for last_msg_ref is
> placed in the last_msg_processed attribute of the error response.
Remove everything after the last comma. Remainder is ok, but should
swap position with the immediately following paragraph.
> - If this is a new message channel, or if the message channel has
> been idle for a reset_interval period of time, then the server will
> set its local msg_ref counter for this client to that of the
> incoming message (msg_ref counter reset). i.e. If the last_msg_time
> for this client is 0, or if the last_msg_time is less than the
> server's current clock value minus the reset_interval, then the
> last_msg_ref for this client is set to the msg_ref value in this
> message, and the message is accepted for processing.
Ok, other than swapping position with the immediately preceding paragraph.
> - The server then checks for out-of-order and duplicate messages. If
> the msg_ref value is less than or equal to the last_msg_ref for
> this client, then the message is rejected with an incorrect msg_ref
> code, and the server's value for last_msg_ref is placed in the
> last_msg_processed attribute of the error response.
As above, remove everything after the last comma.
> The proposed value for allowed_clock_skew_interval is 60 (?) seconds.
Delete, not needed.
> The proposed value for reset_interval is 600 (?) seconds
Change to much longer interval, on the order of a day (86400 seconds).
Finally (for this section) there should probably be a note that,
whatever reordering might happen with other checks, the server MUST
NOT record new msg_ref values for the client until after the message
has passed the signature check.
> | suggested_sia_head="[directory url]" >
s/url/uri/
> | <certificate cert_url="url"
s/cert_url/cert_uri/g
> resource_set_ipv6="2003:A::/32,2001:7ABC::-2001:7FFF"). The XML
s/7FFF/7FFF::/
> If any of req_resource_set_* attributes are specified in the request,
> then any missing req_resource_set_* attributes are to be interpreted as
Deleting everything up through and including "then" would make this
sentence clearer, as the absence of req_resource_* attributes is
interpreted in exactly the same way if none are present. :)
> | <last_msg_processed>[msg_ref_value]</last_msg_processed>
Per my previous mail I'd remove this field.
> last_msg_processed :
> value indicates the responder's last processed msg_ref value. This
> element MUST be present when an "incorrect msg_ref" status code is
> used. It MUST NOT be present in all other cases.
Remove, as above.
> The error code set is:
>
> Code Value Description>
>
> 1000+ Client Error
>
> 1101 Message too old
> 1102 msg_ref value is invalid
> 1103 out of order msg_ref value
> 1104 version number error
> 1105 unrecognised request type
> 1201 request - no such resource class
> 1202 request - no resources allocated in resource class
> 1203 request - badly formed certificate request
> 1301 revoke - no such resource class
> 1302 revoke - no such key
>
>
> 2000+ Server Error
>
> 2001 Internal Server Error - Request not performed
Per my previous message, I'd really rather have tokens than numbers
here. Not particularly clever suggestions for the errors listed so
far:
invalid_msg_ref
unsupported_version_number
unrecognised_request_type
no_such_resource_class
no_resources_allocated_in_resource_class
badly_formed_certificate_request
no_such_key
internal_server_error
i don't particularly care whether we have different "no such resource
class" errors for different request types, seems unnecessary but not a
big deal.
i omitted some errors, here's why:
- message too old: timestamps removed from protocol, see above
- out of order msg_ref value: i don't see how the server can tell the
difference between this and "invalid msg_ref", so I combined them.
> 4. XML Schema
>
> The following is a RelaxNG [http://relaxng.org/] compact form schema
> describing the IR-ISP Protocol, version 1.
Thank you for providing this! I'm not (yet) competent to review it (I
expect to learn RelaxNG as I get into this part of the code), so no
comments at this time, other than to note that the schema does not
appear to lock down the error codes very tightly, it just says "oh,
there will be a number here". I consider the error codes to be part
of the protocol, and I expect the schema to reject messages that
it can detect as protocol violations, so I'd rather nail down the
explicit list of errors in the schema. Yes, this means we have to rev
the schema when we add a new error, that's appropriate if the errors
are part of the protocol.
