Dear Alan, WG
We are restarting the thread on the T+ enhancements for SSH. As background: on
the recent doc, we had conflated the SSH enhancements with the TLS
modifications, we have taken advice of WG to split these into separate docs,
the TLS doc is being progressed independently.
The first item we’d like to discuss regarding the SSH doc relates to Alan’s
broad concern raised here:
"If we're going to extend TACACS+ by adding major new features, I would suggest
that it's a priority to design these features correctly, the first time.
Experience shows that it is extremely difficult to extend fixed-field packet
formats. It's almost always better to use an extensible format, as with
DHCPv4, DHCPv4, DNS options, YANG, RADIUS, Diameter, etc.
Using a format with fixed fields now makes it more difficult to extend TACACS+
in the future. There will just be one complex format added after another. The
alternative is instead to define an extensible format, in which case new
extensions become trivial."
We believe that we can address this issue, but first one detour into why we
were looking to enhance the T+ Authentication Packet: To provide the support
for SSH key transfer to the client in a flexible way, we plan to simply import
the extensible arguments that are present in T+ Authorization and Accounting,
to Authentication, as an addition to Authentication phase.
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.
The downside to this approach, as has been pointed out, is that by embedding
the original T+ Authentication root into the extended packet, we are bringing
along all its fixed fields,, for example: username. This compares to other
protocols, such as RADIUS, that include username as one of the extensible
attributes.
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:
Here is the original Authentication Start Packet from current T+:
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 |
+----------------+----------------+----------------+----------------+
| user ...
+----------------+----------------+----------------+----------------+
| port ...
+----------------+----------------+----------------+----------------+
| rem_addr ...
+----------------+----------------+----------------+----------------+
| data...
+----------------+----------------+----------------+----------------+
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 |
+----------------+----------------+----------------+----------------+
| arg_cnt |
+----------------+----------------+----------------+----------------+
| arg_1_len |
+----------------+----------------+----------------+----------------+
| ... |
+----------------+----------------+----------------+----------------+
| arg_N_len |
+----------------+----------------+----------------+----------------+
| user ...
+----------------+----------------+----------------+----------------+
| port ...
+----------------+----------------+----------------+----------------+
| rem_addr ...
+----------------+----------------+----------------+----------------+
| data...
+----------------+----------------+----------------+----------------+
| arg_1 ...
+----------------+----------------+----------------+----------------+
| arg_2 ...
+----------------+----------------+----------------+----------------+
| ...
+----------------+----------------+----------------+----------------+
| arg_N ...
+----------------+----------------+----------------+----------------+
Removing the fixed parts inherited from the original, the new proposal would
look 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
+----------------+----------------+----------------+----------------+
| arg_cnt |
+----------------+----------------+----------------+----------------+
| arg_1_len |
+----------------+----------------+----------------+----------------+
| ... |
+----------------+----------------+----------------+----------------+
| arg_N_len |
+----------------+----------------+----------------+----------------+
| arg_1 ...
+----------------+----------------+----------------+----------------+
| arg_2 ...
+----------------+----------------+----------------+----------------+
| ...
+----------------+----------------+----------------+----------------+
| arg_N ...
+----------------+----------------+----------------+----------------+
The New Extended Authentication Packet would then pretty much simply be a set
of arguments, whilst still maintaining the base style that keeps the new packet
syntactically compatible with the arguments of the other T+ phases.
It will require the definition of attribute names that were previously
specified as fixed fields.
Does this approach address your concerns?
Many Thanks,
Regards,
The authors.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
