search

haussli / draft-dahm-opsawg-tacacs-security

IETF draft for new tacacs+ security features
1 stars 1 forks source link

AVP concatenation and separators as related to ssh pubkeys #11

Closed haussli closed 3 years ago

haussli commented 3 years ago

The solution to PR #6 is that duplicate AVPs are concatenated. Does this affect the new ssh_pubkey_type or ssh_pubkey in S5?

haussli commented 3 years ago

Be more specific about duplicate AVP concatenation and how to address it for AVPs ssh_pubkey_type or ssh_pubkey. Committed in d7c5022a31.

haussli commented 3 years ago

As paraphrased by Douglas: 1) arguments with same name will be joined together by receiver 2) therefore the sender MUST be aware that the splitting up done as they are sent WILL BE lost on the receive end. 3) therefore if it is required that attributes with the same name are to be interpreted as separate attributes then the sender and receiver MUST have their own scheme to delimit the attributes.

Douglas suggests changing the text as "separator" -> "delimiter" to avoid confusion with the AVP [*=] sparators. Passing this PR to Douglas to make this update.

Another option to consider is that the receiver could add the delimiters it needs, BUT that means that a sender can not split a value among multiple AVPs. eg:

AVP_name<value A bytes 0-128> AVP_name<value A bytes 129-255> AVP_name<value B bytes 0-128> AVP_name<value B bytes 129-255>

I do not know why a sender would want to do that; laziness? A value would have to be rather large to warrant it.

dcmgashcisco commented 3 years ago

Have removed the section that attributes with same name will be concatenated, and have specified that behavior of attributes that are repeated will be documented specifically by attribute so that the semantics may be considered appropriately..