More comments...
4.4. Description of Authentication Process
Authentications are classified by the action, authen_type and service
fields in the START packet of the authentication Session. The user,
priv_lvl, service, port and rem_addr in the START packet are all
provided to help identify the conditions on the client
What is meant by "conditions on the client"? It would be best to describe
what those fields mean instead.
... The information necessary to transact the authentication is passed ...
What is "information necessary to transact the authentication"? This sounds
unclear to me.
... A set of standard authentication classifications is defined in this
document.
What is meant by "authentication classifications" ? It's not clear from the
context or the rest of the document. Perhaps it means "authentication
protocols" ? i.e. one exchange is done for PAP, another for MS-CHAP, another
for OTP, etc.
... When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA,
TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS,
then authentication continues and the server_msg may be used by the
client to prompt the user for more information.
"may be used"? What happens when the client doesn't use server_msg to prompt
the user?
... All three cause the same action to be performed, but in the case of
TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the
information that the user responds with is a username, and for
TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a
password.
I'm wary of statements such as "the client can know..." Is that a
philosophical statement?
It's generally best to describe actions instead of knowledge. e..g. "for
prompts using TAC_PLUS_AUTHEN_STATUS_GETUSER, the users response is interpreted
by the client as a username, for use in subsequent exchanges".
... TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a
password.
Similar comments apply here.
... TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for
more information.
And what happens then with the data? When is this message used?
4.4.1. Version Behaviour
... in the table below:
LOGIN CHPASS SENDAUTH
ASCII v0 v0 NA
PAP v1 NA v1
CHAP v1 NA v1
MS-CHAP v1 NA v1
What does "NA" mean? I suspect I know, but it's good to be explicit instead
of assuming that the reader knows the authors intent.
... The removal of SENDPASS
was prompted by security concerns, and is no longer considered part
of the TACACS+ protocol.
It may be worth considering the removal of all documentation of SENDPASS. If
it's not just deprecated by removed entirely, then it should probably be just
removed entirely.
4.4.2. Common Authentication Flows
This section describes the authentication flows that should be
supported.
What is meant by "should be supported"? Is this an RFC 2119 statement? Or
are these examples of authentication flows which are in common use, and that
all clients && servers are expected to support?
... A PAP authentication only consists of a username and password
RFC 1334 [RFC1334] .
I think referencing a later RFC is preferable.
(chap)
... The length of the challenge value can be determined from the length
of the data field minus the length of the id (always 1 octet) and the
length of the response field (always 16 octets).
This would seem to impose limits on the "date len" field. It would be good
to state these explicitly.
Also, to indicate that the challenges MUST have a minimal length, which
should probably be no less than 8, though 16 is suggested. The alternative is
to allow zero-length challenges, which is not good.
And how are the challenge, ID, and response fields packed into the data
field? i.e. in what order are they packed? ASCII art would be *very* helpful
here.
Similar comments apply for MS-CHAPv1 and MS-CHAPv2 authentication.
4.4.3
... When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet
indicates that the TACACS+ server requests that authentication should
be performed with an alternate server. The data field MUST contain
ASCII text describing one or more servers. A server description
appears like this:
[@<protocol>@]<host>>[@<key>]
Examples would help here. The above text isn't ABNF, or any other
machine-readable definition of a text string.
Perhaps the text could be updated to say that "@" is a delimiter. for text
strings:
0 @ = host
1 @ = host@key
2 @ = @protocol@host
3 @ = @protocol@host@key
... If a key is supplied, the client MAY use the key in order to
authenticate to that host. If more than one host is specified, they
MUST be separated by an ASCII Carriage Return (0x0D).
Some questions here. What happens if the client doesn't want to use that
key? What happens if the client is pre-provisioned with a different key than
what is supplied here? If there are multiple hosts, does the client use the
supplied key for all of them? What if the client has a disparate set of keys
for the list of hosts?
... This packet is
only currently intended for PPP authentication when multiple
authentication mechanisms are available and can be negotiated between
the client and the remote peer. This also requires future PPP
authentication extensions which have not yet been passed through the
IETF.
Are users performing device administration over PPP? If that isn't the 99%
case, then I suggest re-wording the paragraph.
Also, updating it to clarify what it means for "future PPP extensions".
Perhaps just removing that sentence would be best.
5. Authorization
... The authorization REQUEST message contains a fixed set of fields that
describe the authenticity of the user or process,
What is "authenticity" of a user?
... priv_lvl
This field matches the priv_lvl field in authentication request a
What does this statement mean? Does the field (length and value) have to be
identical to the field in the authentication request? If not, why not, and
what happens? If so, it would be better to just say that it MUST be identical.
Similar comments apply for the other fields. "match" is a word which should
be used in the context of "A must match B", instead of "is used for matching".
The first is concrete and implementable. The second is more philosophical than
protocol oriented.
... Attribute-value strings are not NULL terminated, rather their length
value indicates their end. The maximum length of an attribute-value
string is 255 characters.
Are zero-length strings allowed? I presume not, but it would be good to say
so.
7. Attribute-Value Pairs
... A value of NULL means an attribute with a zero length string for its
value i.e. cmd=NULL is actually transmitted as the string of 4
characters "cmd=".
That seems contradictory.. NULL is encoded by not encoding it.. Perhaps the
text could instead say:
Attributes which have no value are transmitted as the attribute name,
followed by the mandatory or optional flag. The value is elided. For example,
the attribute "cmd" which has no value is transmitted as a string of 4
characters "cmd="
... acl
US-ASCII number representing a connection access list. Used only
when service=shell and cmd=NULL
I would suggest eliding the NULL here, too. The temptation for naive
implementors would be to encode an actual string "NULL".
There should be a separate "Security Considerations" section as Section 9.
It should explain all of the issues with the protocol, such as the use of
"encryption", etc.
Alan DeKok.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
