Hi Michael,
Many thanks for the feedback.
Just for clarification: rather than re-inventing a format, the intent we had is
to try to take a snippet from one part of the current T+ protocol, remove the
fixed fields, and then re-use that in another part.
The section that is referenced your mail was included in my query just to
illustrate of the part that was rejected from the first draft, for comparison
with the actual proposal.
The format that was intended to replace it is the final snippet, (which is
lifted from a different part of the protocol), shown below:
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+----------------+----------------+----------------+----------------+
| arg_cnt |
+----------------+----------------+----------------+----------------+
| arg_1_len |
+----------------+----------------+----------------+----------------+
| ... |
+----------------+----------------+----------------+----------------+
| arg_N_len |
+----------------+----------------+----------------+----------------+
| arg_1 ...
+----------------+----------------+----------------+----------------+
| arg_2 ...
+----------------+----------------+----------------+----------------+
| ...
+----------------+----------------+----------------+----------------+
| arg_N ...
+----------------+----------------+----------------+----------------+
It is extracted from the Author part of the T+ that is already in use.
I hope the clarification will sufficiently convey the intended re-use combined
with the removal of fixed fields.
However, if this is insufficient, then we will examine options, such as to
embed the needed functionality into the current protocol syntax without need of
extensions.
Many thanks,
Regards,
Doug.
On 30/08/2022, 17:04, "Michael Richardson" <[email protected]> wrote:
Douglas Gash \(dcmgash\)
<[email protected]<mailto:[email protected]>> wrote:
> By addition here, I mean that the plan was for the original
> Authentication packet to be interfered with in the minimal possible
> way, but the generic arguments section (essentially A-V Pairs)
> structure from Author and Acct were added to it. This gave us, we
> believed, the flexibility we need to SSH whilst keeping the root of the
> Authentication format consistent with the old authentication format to
> encourage adoption and simplify implementation.
Alan's point is that nobody should ever event any new TLV format. It's been
done.
Radius/Diameter have A-V pairs, **we have CBOR**, TLS packet format,
SSH packet format, IKEv2 packet format, and the list goes on.
PICK ONE and reuse it.
A CBOR map is a really good choice.
> We believe this might be addressed by simply taking the advice to
> remove the fixed fields from the new Extended Authentication
> Packet. Then, all the fields that might be needed, are simply added as
> members of the arguments (i.e. the A-V Pairs). The fixed fields such
> as: username, rem-addr, flags etc would no longer be brought across
> from the old Authentication Packet.
> To make this more concrete:
> The initial Extended Authentication Packet proposal added the arguments
> in the same pattern as authorisation and accounting, like this: 1 2 3 4
> 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
> +----------------+----------------+----------------+----------------+ |
> action | priv_lvl | authen_type | authen_service |
> +----------------+----------------+----------------+----------------+ |
> user_len | port_len | rem_addr_len | data_len |
> +----------------+----------------+----------------+----------------+ |
It still seems to me that you are inventing a new format, and I wouldn't call
this *at all* extensible.
--
Michael Richardson <[email protected]<mailto:[email protected]>> . o
O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
