correct TLS credentials, does it really matter what IP it comes from?
i.e. will the move to TLS still have servers identify clients by IP address?
Servers could also be configured to limit connections by source IP, as an
additional layer of security.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
attribute which has a
zero-length value.
As such, "hold for document update" is the reasonable conclusion.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
o
> that mis-configured clients can be fixed?
Not really.
If the authors believe that there is significant operational benefit to
re-using the port, then the document should explain that in detail.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG
e. They go into exhaustive detail about how every little bit is supposed
to work. I've found that documenting the protocol in such detail greatly
improves the quality of the implementations, and is more likely to result in
interoperation between the implementations.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
draft-dekok-radext-deprecating-radius) rather than duplicating the reco in
> the doc.
Sure. That reference should informative, as the deprecation doc may take a
while to be published. That way it doesn't block your document.
Alan DeKok.
___
OPSA
easons, there is a long discussion
of this topic in
https://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius-03#section-7.3
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> this rather be an convenience option? A specific port number limits the
> attack surface to a single port, and I don't see any need for that.
I think a dedicated port for TACACS+TLS would be good.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
esult, it is useful to have a configuration which can say "allow
network FOO, forbid network BAR". This would be in addition to any TLS layer
filtering.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
e secured by RADIUS, and used in environments where
RADIUS is (allegedly) secure. This means IPSec / TLS / management networks.
If RADIUS administrators want to send insecure UDP packets over the wider
Internet, then there's a lot more information than this which will get leaked.
A
automatically create correctly-formed attributes.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
n only be extended by implementing the negotiation discussed
in the other specifications.
So we would like to suggest 64K packets here, but we can't mandate them,
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ckets.
> [Rob Wilton (rwilton)]
>
> Okay. If this will be obvious to everyone implementing/deploying RADIUS then
> fine, otherwise it might be worth including an informative reference to the
> RFC that increases the limit to 64K.
This is RFC 7930. Packet size limitations will b
to create a new sub-registry entitled "DHCPv6
> Options Permitted in the RADIUS DHCPv6-Options Attribute" in the
> "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
> [DHCP-RADIUS].
>
> Do we nee
but the requirements for TACACS+ with TLS would be similar.
There are a large number of options for configuring certificates, validation
methods, CAs, PSKs, etc. Nearly all of these would be required when TACACS+ is
used with TLS.
Alan DeKok.
__
Having been just added as co-author, No, I'm not aware of any IPR that
applies to this draft"
> On Oct 12, 2022, at 12:46 PM, Joe Clarke (jclarke) wrote:
>
> Authors and contributors, please respond on-list as to whether or not you are
> aware of any IPR that pertains to this work.
>
>
d
separately in a DHCPv6-Options attribute. They can all be added to the packets.
i.e. if the administrator of the system configures something weird, the
systems should just do what's asked.
Anything past basic filtering is complex to define, and complex to implement.
And arg
tion, the RADIUS server SHOULD expose the DHCP options and allow
administrators to configure them, instead of requiring them to be entered as
opaque data".
That gets the best of both worlds.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
are happy to accept
longer packets.
i.e. it's 2022, I think that software can easily handle 64K buffers for
network protocols.
There's also RFC 7499 which supports fragmentation of CoA packets. Perhaps a
similar method could be used here, if required?
Alan DeKok.
___
t
implementations SHOULD support 64K RADIUS packets.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
tribute can then carry a full 253
octets of data. And there are no limits on the number of child attributes
which ca be carried.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
RADIUS
attributes. So there's reasonable precedent.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ts only for "top level" attributes, and cannot
be used here.
Further, RADIUS packets are generally limited to 4K octets total. So even if
the limits on this attribute are removed, then there's still a practical limit
of around 4000 octets.
Alan DeKok.
__
On Oct 6, 2022, at 9:32 AM,
wrote:
> I added an appendix for this as you can see at:
> https://tinyurl.com/opsawg-add-latest.
I missed that, sorry.
> Do we need to sway more?
No, I think this looks good.
Alan DeKok.
___
OPSAW
le documents, and then "read between the
lines" to see what's implied. This is hard.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
-Lite-Tunnel-Name RADIUS attribute is a string
> with opaque encapsulation, according to Section 5 of [RFC2865].
That appears to be an error. I'll file an errata with IANA.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
HCPv6
option BAR". There should probably either be an explicit mapping table given,
or each attribute definition should be extended with "this attribute is copied
to DHCPv6 attribute BAR"
Without such direction, an implementor has to guess as to the ma
On Sep 15, 2022, at 10:04 AM, Qin Wu wrote:
>
> Thank for clarification, so Diameter protocol doesn't need to define any new
> attributes with similar functionality as Radius attributes, right?
That is what I said.
Alan DeKok.
_
ameter, and does not need to be mentioned in any RADIUS specification.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
k.
>
> Therefore, this kicks off a two-week CfA for
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/.
> Please comment on-list with support and/or discussion of the work.
I believe it should be adopted.
We can worry about R
it.
>
> We believe this option will enable an effective encapsulated upgrade approach
> for implementors, and welcome feedback.
I think it's a good approach.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
s undertaking.
My related question is what *else* do people envision doing with TACACS+? If
it's 1-2 things and then done, a small change can be acceptable. If there's a
long list of new things to do, then it's time to do TACACS+ 2.0.
Alan DeKok.
_
use-case?
As an implementor, I can sympathize with the approach of "minimal changes".
But 15 years of minimal changes can result in a horrible mess. There's also a
good argument for saying "Look, we're going to do a bunch of stuff with
TACACS+, so we might as well fix it now
> on July 29, 2022.
I support adoption of this work.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
acs-security).
Yes. I've checked the tls13 draft, and it has addressed my concerns, thanks.
> The next version -f dahm-tacacs-tls13 *will* add one thing, a status code
> that is necessary to fulfill Joe's request about handling the deprecation
> of the unencrypted flag.
That'
your proposal
> (i.e., T+ as it is over TLS).
That's how I recall the document being described: "no changes to TACACS+,
just adding TLS transport".
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
he beginning of May when the composite draft was submitted.
EMU spent a lot of time with TLS recently. I'm hoping that experience will
help here.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
s instead to define an extensible format, in which
case new extensions become trivial.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
are
> missing. We'd like more input and if there is interest, add it after
> adoption.
I would say that adding SNI has large value, and only small downsides.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ACS+ proxying? Why has the scope changed from
the original discussion from a few years ago?
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
stand, and is easily
extensible to add new fields. It also allows for multiple layers of proxying,
which the current draft doesn't.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
xisting spec, and code, to do pretty much this:
https://datatracker.ietf.org/doc/html/rfc7055 and
https://moonshot-wiki.atlassian.net/wiki/spaces/HOME/overview?mode=global
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
not what the draft says. So it's worth talking about
the "obvious" thing, and explaining why it's wrong.
But overall, I think it's a good approach.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Or they can use RFCC
6677 channel bindings. https://datatracker.ietf.org/doc/html/rfc6677
This presumes that the devices are using TLS-based EAP methods in order to
authenticate to the network. As time goes on, this seems to be not only more
widely true, but also more widely reco
"key" to describe the shared secret / key field. And then another
field which describes what kind of encryption or obfuscation to use. For now,
only one value could be defined: obfuscation. Future standards could add other
methods.
Having an &
tantially changes my argument against using the same
"key" field for "obfuscation" and real "encryption" is perhaps not ideal.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ould lean towards to leaving this as "obfuscation". And, suggesting that
any newer security methods use entirely different fields in the YANG model.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ill not be
termed as encryption in this document.
...
It would be prudent for the Yang model document to use the same terminology
as RFC 8907.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
gest referencing RFC 7542 (NAI) for a discussion of "user@hostname"
issues.
Over all, I think this proposal is useful. My team has struggled with the
exact issues outlined here, when using SSH in a distributed environment. Being
able to use EAP would significantly decre
ncluding
RFC 2866 for one.
> - I am worried about the shepherd writeup:
That's a question for the IETF process. The document has been published.
It's a _little_ late to be asking many of these questions.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
^24 are forbidden, and lengths larger than 2^16 are
suspicious.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
nd fixed-time retransmission behaviours which were first
implemented in 1993.
In order for your proposal to gain traction, the NAS vendors MUST have strong
incentive to implement it. And I'm not sure what that incentive is. Right
now, they can just say
uld
have serious security issues. Even if those security issues were addressed, I
believe that load balancing is simply not appropriate for the NAS. Even if it
was appropriate for the NAS, the vendors have spoken: NAS implementations are
simple, and server implementations are complex.
As such, load bal
and
> start to think about how to fill the standard gaps to make it happen. I think
> this is the core value of this draft.
I reiterate my objection that this draft says essentially nothing. And as
such, does not belong in the IETF.
Alan DeKok.
tion". While at the same time giving next to no information about the
solution.
IMHO the WG should ignore this document entirely.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
want
to really push the envelope, provide for those AAA protocols in the
ietf-system-aaa YANG model.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
fine "AAA" to mean "TACACS" here.
AAA has a well-defined meaning, which doesn't include TACACS.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Aug 13, 2018, at 3:19 PM, Joe Clarke
wrote:
> As this document progresses towards ratification, the opsawg chairs are
> soliciting people that have implemented TACACS+ clients and/or servers
> to read the draft and comment as to whether or not their implementation
> is known to be compliant
tations SHOULD deprecate the redirection mechanism.
"implementations" is fine here. Perhaps also "SHOULD deprecate the
redirection mechanism, and disable it by default."
> TACACS+ server implementations MUST warn deployment administrators of the
> security im
oes not.
There are probably dozens of implementations of TACACS+ around. From my
recollection, there may have been two implementors who said "yes the draft
matches the implementation".
And one of those was from my team. Which wa
document matches current implementations or
deployments. The proponents of TACACS+ have been surprisingly silent on this
topic.
So everyone wants the document published, but they're unwilling to state if
it actually documents TACACS+.
That's a pretty large red flag *against* publication, IMHO
nd. I
think it's just word smithing from now on.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ns".
The spec needs to say "you MUST implement and deploy it in a secure manner".
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
PAP vs. CHAP is closely
> related to password management on the server side).
>
> Would this be the right way or not really?
Yes.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
e the reader to fend for himself. "Hmm... the
authors didn't say this was bad, so let's do it!"
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
k, or (b) it's
"protected" by the obfuscation mechanism.
The spec should just describe the requirements. How the implementors and
administrators deploy it is up to them.
e.g. "PAP MUST NOT be used outside of management networks, unless the packets
are protected by the obfuscation mecha
ractices.
If you don't think that the protocol is salvageable at all, then please
withdraw the draft.
If you think we *can* document best practices, then we should do so.
If you think documenting best practices isn't productive, then you will get
roundly trounced when al
much to me like the goal is to publish an "IETF stamped"
version of TACACS+. And that the content of the document is almost irrelevant.
That's just not how this works.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
, have to be as secure as
possible.
If the WG punts on security then we might as well add a note to the document
saying "using this protocol will ensure that hackers will pwn your equipment".
Because it will be absolutely true.
And then *no one* will want to implement it.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
secure by design?"
Which is a Good Thing.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ick check recently, and there are still major issues with
the document. So there isn't much point in doing more detailed reviews. Having
done that lots, I'm disinclined to do it again.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://ww
text
had such prescriptive text.
> If the option must be used for legacy application reasons, then it is
> recommended to avoid the option to send secret keys in the server list.
Again, "it is recommended"
The new text is a step backwards from earlier drafts. I've taken a loo
luded an attribution, last
> February.
That's not true. It acknowledged I had *reviewed* the document. There was
*no* acknowledgement that "Sections X through Y were written by Alan DeKok.
> Almost a full year after -06. I can only imagine how your frustration must
> have
and future,
> in what we believe is the most constructive way: improving in the areas where
> we were found wanting.
The goal *is* to have a specification after all.
I am, however, deeply concerned at the miscommunication. The messages could
no
ve no idea if this revision of the document addresses multiple WG reviews
* we have no idea if the document even describes TACACS+ as currently
implemented
As such, it should not be put into working group last call, or much less
published until such time as those issues are addressed.
Alan DeKok.
lace them with other WG
member(s) who will follow the IETF process.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
t, verbatim. With no acknowledgement that this is the case.
It would be good for the authors to engage with the WG to demonstrate that
the document is ready. The document has been shown repeatedly to be not ready
for publication, with minimal engagement
that this is the case.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
definitely seems better that the previous ad-hoc definitions.
> Boolean
>
> All boolean attributes are encoded with values "true" or "false".
Nit: encoded as US-ASCII strings with values...
Alan DeKok.
___
OPSAWG mail
T+ devices we
>>> see is so diverse and use cases are such that I would not like to
>>> constrain.]
>>
>> It would be good to have recommendations. e.g. "updates more than once
>> per second are NOT RECOMMEND, updates more than an hour apart are NOT
>>
there recommendations for the content of task_id? e.g. incrementing
> numbers, strings, etc.
>
> * is task_id mandatory to occur in accounting packets?
> [task_id is best practice, and I think we can promote it to mandatory,
> however this would be a change to spec. It is a text value
That is not how the IETF works. I fail to see what else could be commented
> here.
I'm saying until I complained, that *was* largely the process being used in
this WG.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
t for version 7.
Thanks.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
e trying to make here. The only
subjects you addressed were ones I hadn't raised.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
I suggest the chairs
replace you with authors who will.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On May 12, 2017, at 2:40 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote:
> 1) Regarding the use of uncredited text from Alan DeKok:
>
> It is certainly the case that Alan has spent time actively engaged in the
> process of critiquing this document to improve it, and
I would suggest that it's too early to have a WGLC, as the authors simply
haven't responded to reviews of the draft.
i.e. I have no idea what state the draft is in. After doing multiple
detailed reviews that largely get ignored, I'm not inclined to do more. It's
up to the authors
appreciate that the document is improving, blatant copying of my text
without attribution is entirely inappropriate.
What are the chairs recommendations?
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo
be used by anyone to implement anything. Please wait for the Standards
track document to get the actual TACACS+ specification that people can
implement".
It shouldn't be a contentious issue. Either document the protocol, or admit
we're not going to document the protocol.
Alan DeKok.
Some comments. Mostly little nits and clarifications.
The major points for me are related to security. The "Security
Considerations" section is almost empty, and will certainly not pass a review
from the security area. They will in all likelihood block publication until
substantive
On Jul 15, 2016, at 11:24 AM, Alan DeKok <al...@deployingradius.com> wrote:
> The Security Considerations section is in the middle of the document, where
> it's typically at the end. That's a minor nit. The larger one is that the
> Security Considerations section is pretty mini
s the operation, makes the checks normative, and adds
a suggestion to close the TCP connection. After all, if they key is wrong and
packets can't be decrypted, there's no reason to keep the TCP connection open.
You can't decrypt any data in the connection, so it will all be garbage.
Alan DeKok.
site deployment have on security?
As an implementor, I would have to guess at large portions of the protocol,
or I would have to read the source to existing implementations. The draft as
is stands today can get me ~90% of the way to implementing the protocol, but
critical portions are not pr
ors 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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
this
packet, depending upon the class of authentication.
What does it mean to be "optional"? Perhaps the "user_len" field is equal to
zero, which means that the "user" field does not exist.
Also, since "user_len" is 8 bits, it would be good to not
> On Apr 6, 2016, at 12:46 PM, Christopher Morrow
> <christopher.mor...@gmail.com> wrote:
>
> (I hate to resurrect an old thread. but)
>
> On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok <al...@deployingradius.com>
> wrote:
> And since TACACS+ is
re when it's ready.
In short, there is no practical way to onboard users securely via the method
of "connect to an SSID, and click through the prompts". The configuration MUST
be provided to the user signed, and/or via an out of band method.
Alan DeKok.
__
20+ years for standardization, it's worth
waiting a few more months to be sure we get it right.
And since TACACS+ is largely used *within* the enterprise, the issue of
securing it is less relevant than (say) RADIUS, which is used across the wider
internet.
Alan DeKok.
s on the
document(s), but that the people *proposing* the document(s) can't even reach
consensus among themselves as to what they're proposing.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
charter.
But defining a new (to the IETF and the world) network management protocol is
entirely outside of the scope of OPSAWG.
Or, if (as many people say) the protocol isn't new, then OPSAWG won't be
making any changes to TACACS+. It can't both b
he protocol as it exists today? We don't know.
It would be good to get feedback from implementors as to whether or not the
document is correct on it's technical content. I see that information as
critical to have.
Alan DeKok.
___
OPSAWG mail
1 - 100 of 124 matches
Mail list logo
