Hi,
I hope that in the last few versions we have updated the document to
sufficiently answer the concerns raised, please let me know if any concerns
remain, many thanks.
The majority of the issues were responded to initially last summer, but the
balance should be by the latest version recently uploaded.
Please see the point-by point descriptions of changes or responses.
Many thanks,
1) 4.6. Text Encoding
All text fields in TACACS+ MUST be printable US-ASCII, excepting
Please add a reference to RFC 20 (for US-ASCII) here. Without out it
"printable" has no meaning.
TA> Agreed, will update as advised [AI=TA]
Specifically:
"3.7. Treatment of Text Strings
The TACACS+ protocol makes extensive use of text strings. The
original draft intended that these strings would be treated as byte
arrays where each byte would represent a US-ASCII character.
More recently, server implementations have been extended to interwork
with external identity services, and so a more nuanced approach is
needed. Usernames MUST be encoded and handled using the
UsernameCasePreserved Profile specified in RFC 8265 [RFC8265]. The
security considerations in Section 8 of that RFC apply.
Where specifically mentioned, data fields contain arrays of arbitrary
bytes as required for protocol processing. These are not intended to
be made visible through user interface to users.
All other text fields in TACACS+ MUST be treated as printable byte
arrays of US-ASCII as defined by RFC 20 [RFC0020]. The term
"printable" used here means the fields MUST exclude the "Control
Characters" defined in section 5.2 of RFC 20 [RFC0020]."
special consideration given to user field and data fields used for
passwords.
To ensure interoperability of current deployments, the TACACS+ client
and server MUST handle user fields and those data fields used for
passwords as 8-bit octet strings. The deployment operator MUST
ensure that consistent character encoding is applied from the end
client to the server. The encoding SHOULD be UTF-8, and other
Please add Normative RFC 3629 reference here for UTF-8.
TA> Agreed, will update as advised [AI=TA]
Specifically: Have removed all references to UTF-8.
encodings outside printable US-ASCII SHOULD be deprecated.
I am not sure what this mean. You didn't define allowed encoding (really you
mean charsets).
TA> Agreed, will update as advised [AI=TA]
Specifically: removed UTF-8, pleasee see ref to sectipn 3.7 above.
2) In 5.1:
The printable US-ASCII name of the client port on which the
authentication is taking place,
This doesn't mean anything. Is there a registry? It doesn't look like you
are
using transport service name registry for this. Is it a fixed list?
TA> Please see new sectin 3.7 above.
and its length in bytes. The value
of this field is client specific. (For example, Cisco uses "tty10"
to denote the tenth tty line and "Async10" to denote the tenth async
interface). The port_len indicates the length of the port field, in
bytes.
3) Later in 5.1:
A printable US-ASCII string indicating the remote location from which
the user has connected to the client. It is intended to hold a
network address
What are the allowed formats for IPv4 and IPv6? Or is this just human
readable?
TA> Current practice the field is normally MAC address or IP. Will recommend
that if IP is used, it SHOULD conform to RFC5952 [AI=TA]
Specifcially, added text: " For IPv6 address text
representation defined please see RFC 5952 [RFC5952]."
if the user is connected via a network, a caller ID
is the user is connected via ISDN or a POTS, or any other remote
location information that is available.
4) In 5.4:
If the information being requested by the server form the client is
sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
flag. When the client queries the user for the information, the
response MUST NOT be echoed as it is entered.
What does the last sentence mean? (When is it ever echoed?) Are you missing
a
forward reference or some explanation of echoing?
TA> Agreed, this requires clarification in document to indicate that the data
entered should not be reflected in the user interface. [AI=TA]
Specifically:
Section 5.4., paragraph 5:
OLD:
If the information being requested by the server form the client is
sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
flag. When the client queries the user for the information, the
response MUST NOT be echoed as it is entered.
NEW:
If the information being requested by the server form the client is
sensitive, then the server should set the TAC_PLUS_REPLY_FLAG_NOECHO
flag. When the client queries the user for the information, the
response MUST NOT be reflected in the user interface as it is
entered.
5) KRB5 and KRB4 need normative references.
TA> The KRB5 and KRB4 are not specifically used in this document, rather, there
is one field with an option that the client uses to indicate how it
authenticated, and these are option. This is not verifiable, so it is
recomended in the documen tnot to use this field for policy.For this reason, it
is not really useful to provide a normative reference, but it is required for
the document to explai this. So have added:[AI+TA]
6) Does this document need to obsolete RFC 1492?
TA> That could well be sensible, would follow WG consensus here.
After review, the differences between TACACS and TACACS+indicated that the
protocols were sufficiently different that TACACS+ does not directly obsoltere
plain TACACS,
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
In 4.8:
4.8. The TACACS+ Packet Header
The total length of the packet body (not including the header).
In network byte order? There is some text about that in 4.9, but readers
don't
know that yet.
TA> Agreed, will clarify [AI=TA]
Specifcially in 4.1:
" The following general rules apply to all TACACS+ packet types:
- To signal that any variable length data fields are unused, their
length value is set to zero. Such fields MUST be ignored, and
treated as if not present.
- the lengths of data and message fields in a packet are specified
by their corresponding length fields, (and are not null
terminated.)
- All length values are unsigned and in network byte order."
In 6.1:
The arguments are the primary elements of the authorization
interaction. In the request packet they describe the specifics of
the authorization that is being requested. Each argument is encoded
in the packet as a single arg filed (arg_1... arg_N) with a
Typo: filed --> field.
TA> Thanks, will correct. [AI=TA]
"Section 6.1., paragraph 29:
OLD:
The arguments are the primary elements of the authorization
interaction. In the request packet they describe the specifics of
the authorization that is being requested. Each argument is encoded
in the packet as a single arg filed (arg_1... arg_N) with a
corresponding length fields (which indicates the length of each
argument in bytes).
NEW:
The arguments are the primary elements of the authorization
interaction. In the request packet, they describe the specifics of
the authorization that is being requested. Each argument is encoded
in the packet as a single arg field (arg_1... arg_N) with a
corresponding length fields (which indicates the length of each
argument in bytes)."
corresponding length fields (which indicates the length of each
argument in bytes).
Later in the same section:
Optional arguments are ones that may be disregarded by either client
or server. Mandatory arguments require that the receiving side can
handle the attribute, that is: its implementation and configuration
includes the details of how to act on it. If the client receives a
mandatory argument that it cannot handle, it MUST consider the
authorization to have failed. It is legal to send an attribute-value
pair with a zero length value.
Last sentence: do you just mean that the value can be empty?
TA> Yes, this definition evolved, also had query about the use of the word
“legal” in this round of review.
Will change to “The value part of an attribute-value pair may be empty, that
is, the length of the value may be zero.” [AI=TA]
Specifically:
Section 6.1., paragraph 32:
OLD:
Optional arguments are ones that may be disregarded by either client
or server. Mandatory arguments require that the receiving side can
handle the attribute, that is: its implementation and configuration
includes the details of how to act on it. If the client receives a
mandatory argument that it cannot handle, it MUST consider the
authorization to have failed. It is legal to send an attribute-value
pair with a zero length value.
NEW:
Optional arguments are ones that may be disregarded by either client
or server. Mandatory arguments require that the receiving side can
handle the argument, that is: its implementation and configuration
includes the details of how to act on it. If the client receives a
mandatory argument that it cannot handle, it MUST consider the
authorization to have failed. The value part of an argument-value
pair may be empty, that is: the length of the value may be zero.
In 8.1:
Date Time
Absolute date/times are specified in seconds since the epoch, 12:00am
Jan 1 1970. The timezone MUST be UTC unless a timezone attribute is
specified. Stardate is canonically inconsistent and so SHOULD NOT be
used.
I am not sure what the last sentence means.
TA> Agree, will be removed [AI=TA]
In 8.2:
8.2. Authorization Attributes
For example: "shell", "tty-server", "connection", "system" and
"firewall". This attribute MUST always be included.
Is this a full list or is there a registry?
TA> This is not a full list, it is just for example. In order to prevent
interpretation that it is a full list, will change to [AI=TA]:
“The primary service. Specifying a service attribute indicates that
this is a request for authorization or accounting of that service.
For example: "shell". This attribute MUST always be included.”
Specifically:
Section 8.1., paragraph 15:
OLD:
The primary service. Specifying a service attribute indicates that
this is a request for authorization or accounting of that service.
For example: "shell", "tty-server", "connection", "system" and
"firewall". This attribute MUST always be included.
NEW:
The primary service. Specifying a service argument indicates that
this is a request for authorization or accounting of that service.
For example: "shell", "tty-server", "connection", "system" and
"firewall", others may be chosen for the required application. This
argument MUST always be included.
Later in the same section:
remote_host (String)
What is the syntax of this field?
TA> Will remove this definition. [AI=TA]
10.4. Security of Accounting Sessions
Replace accounting data with new valid or garbage which prevents
to provide distraction
"prevents to provide distraction" doesn't read well.
TA> Agreed, will attempt to translate into readable language! [AI=TA]
Specifcially:
"Section 10.4., paragraph 2:
OLD:
Replace accounting data with new valid or garbage which prevents
to provide distraction or hide information related to their
authentication and/or authorization attack attempts.
NEW:
Replace accounting data with new valid or garbage which can
confuse auditors or hide information related to their
authentication and/or authorization attack attempts.
"
or hide information related to their
authentication and/or authorization attack attempts.
In 10.5.1:
TACACS+ server administrators SHOULD change secret keys at regular
intervals.
Humans are very bad at this. So I think it would be better if this is
changed
to add a requirement on management UIs.
TA> That is sensible. Will discuss options with WG. [AI=TA]
Generlised the advise for the section, i.e. added: "Vendors SHOULD provide
mechanisms to assist the administrator to achieve these best
practices."
10.5.3. Authentication
To help TACACS+ administraots select the stronger authentication
Typo: administrators.
TA> Thanks, will correct. [AI=TA]
Specifically:
"Section 10.5.3., paragraph 1:
OLD:
To help TACACS+ administraots select the stronger authentication
options, TACACS+ servers MUST allow the administrator to configure
the server to only accept challenge/response options for
authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type).
NEW:
To help TACACS+ administrators select less weak authentication
options, TACACS+ servers MUST allow the administrator to configure
the server to only accept challenge/response options for
authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or
TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for
authen_type)."
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
