Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-07.txt
Some comments on the latest draft: 2.1. Obfuscation ... The algorithm is categorized as Obfuscation in Section 10.5.2 of [RFC8907]. The term should be interpreted to mean "plaintext" I wouldn't call it "plaintext", as it's not. Perhaps instead just drop the "interpreted to mean plaintext" portion. 2.2 ... using unsecure TACACS+ authentication and obfuscation "insecure" instead of "unsecure". 3.1 ... All data exchanged by TACACS+ peers MUST be encrypted, Perhaps explicitly say that TLS cipher suites with NULL encryption are banned. This is a little more quantitative. ... they will be deployed on different ports. Due to the widespread use of default port number settings in numerous existing TACACS+ client configurations, a well-known system TCP/IP port number will be requested from IANA. Perhaps just say "uses port TBD", and leave the IANA instructions in a separate IANA section. i.e. the final RFC doesn't need to contain text on "port will be requested from IANA" 3.2 ... Why it closed has no bearing on TLS resumption, unless closed by a TLS error, in which case the ticket might be invalidated. "might" seems wrong here. If there is a TLS error, the server generally should discard any session tickets. While RFC 8446 doesn't say this, I'm not clear if there are any use-cases for resuming sessions which (for example) had previously failed with fatal TLS errors. 3.2.2. Are there any considerations for which CA to use, or what kind of CA to use? 4 [RFC8907] describes the obfuscation mechanism, documented in Section 5.2 of [RFC5425]. The reference to 5425 seems wrong. 5.1.1.1 ... Non-TLS connections should not be used for new TACACS+ deployments. Maybe SHOULD NOT? ... It is NOT RECOMMENDED to deploy TACACS+ wi I think this should be a MUST NOT 5.1.5 ... If TLS Encrypted Client Hello becomes standardized and applicable to TLS 1.3, then it SHOULD be included in Secure TACACS+ implementation. I think it's safe to leave that for any TLS spec. I'm not sure why it would be added to an application specification. 5.3 This is all good text, but I think the general attitude has been to avoid STARTTLS for many years. This document could just define TLS, and ignore any issues of STARTTLS. i..e. is it important to an implementor to explain why STARTTLS is not used? If not, then the text is not necessary. ... perhaps using separate servers for Non-TLS connections and TLS. "separate servers" means different IPs? Different ports? They're already using different ports. 6. ... it is useful for the impatient to direct particular attention to Sec perhaps use text of "short summary" instead of "impatient" Perhaps also discuss issues of IP address filtering? If the client has 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
Re: [OPSAWG] [Technical Errata Reported] RFC2865 (6915)
On Jan 15, 2024, at 7:14 AM, Rob Wilton (rwilton) wrote: > Hi RFC 2865 authors, OPSAWG, I've CC'd RADEXT, as that WG is currently active. I've also removed the 2865 authors email addresses. I believe those became inactive decades ago. > I think that this errata may be valid, but given the age of the RADIUS > protocol, and the fact that I'm not familiar with it and this is a change to > the protocol, then I'm somewhat concerned with verifying this errata, and > hence I propose to move it to "Held for Document Update". > > Does anyone have any comments on this proposed resolution? I think "hold for document update" is best. We've covered these issues in RFC 8044, which defines data types for RADIUS (octets, printable text, IPs, integers, etc). There are no data types which permit zero-length values. The variable-length data types defined in Section 3.4 (printable strings) and 3.5 (binary data) both say: Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. There is no _general_ prohibition on attributes having zero length values. But it is not currently permitted to define an 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
Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
On Dec 29, 2023, at 1:58 PM, Michael Richardson wrote: > Are port numbers really that precious (particularly if we can allow for a >> 1024 port allocation) that we have to force Deep Packet Inspection on > systems that want to disallow non-TLS traffic, or at least, to identify it so > 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@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
perators. I'd suggest reading the RADEXT TLS-PSK and ALPN documents linked above. 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
Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute
On Oct 9, 2023, at 3:06 AM, mohamed.boucad...@orange.com wrote: > We prepared a PR to address these at: > https://github.com/boucadair/policy-based-network-acl/pull/18/files That looks good, thanks. > I think that it is better to refer to a RADEXT doc (e.g., Section 7.3 of > 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute
On Sep 26, 2023, at 8:00 AM, mohamed.boucad...@orange.com wrote: > > Hi RADEXT, > > FWIW, the document specifies the following new RADIUS attribute: > https://boucadair.github.io/policy-based-network-acl/draft-ietf-opsawg-ucl-acl.html#name-user-access-control-group-i > > Your review of that part of the spec is appreciated. My $0.02 as someone jumping on these kinds of things. Mostly nits. > The value fields of the Attribute are encoded in clear and not encrypted as, > for example, Tunnel- Password Attribute [RFC2868]. This text isn't necessary and can be omitted. > The User-Access-Group-ID Attribute MAY appear in a RADIUS Accounting- Request > packet. What is the interpretation of the attribute there? i.e. in Access-Request, it's a hint / request. In Accounting-Request, it means... ? I think the requirement here is that if the User-Access-Group-ID attribute appears in an Accounting-Request packets, it MUST have the same value as given in the Access-Accept. That is, the value in Accounting-Request is an acknowledgment by the NAS that it has received the attribute in the Access-Request, and is enforcing that policy. > The User-Access-Group-ID Attribute is structured as follows: I would suggest following the attribute definition format suggested in 8044: https://www.rfc-editor.org/rfc/rfc8044#section-2.1.3 It's only a minor change from what is there now. Add a "data type" field, and remove the "extended type" field. > The User-Access-Group-ID Attribute is associated with the following > identifier: 241.TBA1. This text isn't necessary and can be omitted. Just leave a "TBD" in the Type field as recommended by 8044. > The following table provides a guide as what type of RADIUS packets that may > contain User-Access-Group-ID Attribute, and in what quantity. It's not necessary to list the attribute number here. Just omit that column. Identifying the attribute by name is enough I'll also note that this table allows for multiple copies of the attribute to exist (i.e. "0+"). The rest of the text in the section doesn't mention that more than one attribute are allowed. The text should be updated to explain what that means. Perhaps something like "If more than one copy of the User-Access-Group-ID attribute appears in an Access-Accept packet, it means that the user is a member of all of those groups." I haven't taken a detailed look at the rest of the document, but this text in Section 4.1 jumped out at me: > Step 3: The authentication request is then relayed to the AAA server using a > protocol such as RADIUS [RFC2865]. It is assumed that the AAA server has been > appropriately configured to store user credentials, e.g., user name, > password, group information and other user attributes. It may be good to give an example packet, but that may also be too restrictive. What should be discussed is what format is used by the credentials. i.e. User-Password or CHAP-Password. Given other discussions and research in RADEXT, it would be good to suggest here that User-Password is strongly preferred to the alternatives. For anyone interested in the underlying reasons, 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
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
On Jul 5, 2023, at 3:25 PM, Marc Huber wrote: > I still unsure whether the > > Obsolescence of TACACS+ Obfuscation > > section could hinder implementations and migrations using TLS wrappers (load > balancers, e.g.). I'd still suggest to change the "MUST" clauses regarding > obufuscation to "SHALL". There's no gain to change the protocol at this > point, it's sufficient to wrap it in TLS. If a client insists in using > obfuscation-over-TLS, that should be fine, even if it's of no use. We did that for RADIUS. i.e. leave in MD5-based "crypto" when we did RADIUS/TLS 10 years ago. We're now ripping it out. I would suggest that using obfuscation over TLS is a bad idea. While it's tempting to just say "wrap it in TLS", leaving MD5 in has other costs. Most notably FIPS, where insecure digests like MD5 are banned. Reading the fine print of FIPS suggests that using MD5 in this way is allowed for a protocol like TACACS+TLS. But few people read the fine print, and taking out the MD5-based captor is likely best. > Regarding a dedicated TCP port: Is there really a need for that, or would > 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
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
On Jul 10, 2023, at 10:09 PM, Peter Marrinon wrote: > This feedback is based on my own review and some comments from people in my > team who will be implementing this in our internal TACACS+ system. Our issues > are relatively minor; we generally believe we could take most of this > standard and implement it as intended. I have some related comments. Rather than start a new thread, I'll reply here. > > ISSUES THAT CAUSED CONFUSION > > 3.2 Based on some questions from a developer in my team, it may be beneficial > to explicitly state that earlier versions of TLS MUST NOT be supported. I > think the text implies it but explicitly stating it may stop someone also > adding support for earlier versions. Agreed. > 3.2.1 Cipher Requirements: "The cipher suites offered or accepted SHOULD be > configurable so that operators can adapt." It is slightly unclear what the > operators are adapting. Is this meant to be "The cipher suites offered or > accepted SHOULD be configurable by operators" or is there a subtlety I'm > missing? The implementation should expose enough TLS configuration that the administrator can change the cipher list if necessary. For example: https://github.com/FreeRADIUS/freeradius-server/blob/release_3_2_3/raddb/mods-available/eap#L407 That just takes configuration: cipher_list = "..." and hands the string over to OpenSSL, which does it's magic. This lets the admin use "DEFAULT" in most cases. But if the admin needs to change that, it's simple to do so. > 3.3 TLS identification: There does not appear to be any network location > based validation methods in section 5.2 of RFC5425. Is it meant to be a > reference to the using a wildcard with a domain? I would agree that implementations should support IP-layer filtering by network. The TACACS+ server may be accessible on a management network, but perhaps only part of that network contains edge devices which will connect via TACACS+. As a result, 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
Re: [OPSAWG] [dhcwg] Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-dns-11: (with COMMENT)
On Mar 15, 2023, at 3:57 PM, Paul Wouters wrote: > > Yes it is superior but because you say you are targeting that, it makes the > radius setups without TLS or IPsec out of scope and I think that’s wrong. Perhaps it's best to just delete that sentence? These options should be 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. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [dhcwg] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)
On Mar 14, 2023, at 7:10 AM, Bernie Volz wrote: > Of course if the data is malformed, then following existing policies > (rfc6929) is prudent. Though even there it isn’t 100% clear what to do if the > attribute is well formatted but the option data is bad - mostly the length of > the last DHCP option exceeds the remaining data in the RADIUS attribute. I > doubt we expect RADIUS or DHCP servers to assure that each individual option > is valid (such as the length is a multiple of 4 or 16 if data is list of > addresses). If a RADIUS server implements this specification, we pretty much do expect that. RADIUS servers which don't support this specification can have administrators define the options as opaque strings: 0xabcdef... In that case, the RADIUS server has no idea what the data is, and doesn't validate the options. RADIUS servers which do support this specification have some way to expose the DHCP data as something other than opaque strings. In which case the RADIUS server takes those humanly readable values, and packs them into DHCP options, and then into RADIUS attributes. This packing not only must be done correctly, it should automatically create correctly-formed attributes. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-add-encrypted-dns-09
On Feb 17, 2023, at 3:29 PM, Robert Sparks via Datatracker wrote: > Nit: The discussion in paragraph 3 of section 3 and the note that follows are > currently ambiguous. When it calls out that 2865 limits the size of DHCP > options and that 7499 and 7930 relaxes the limit, is it only trying to inform > where the recommendation of supporting 65535 bytes came from? Or is it trying > to constrain the size of any DHCP option added to the the attributes defined > here to 4096? The goal is to say that the default limit for RADIUS packets is 4096 octets, and that limit can 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
Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
On Feb 8, 2023, at 2:38 PM, Rob Wilton (rwilton) wrote: > To give a regular configuration example, if you were to enable the Ethernet > auto-negotiation protocol but also explicitly configure an 10/100/1000 > Ethernet interface to run at 100 Mb/s then I would expect the explicit client > provided configuration to take precedence over negotiating the speed value. > > It sounds like, in what you describe, the configuration is effectively > hierarchical. I.e., it is really because the RADIUS supplied configuration > is more-specific that it takes precedence over the local configuration. If > so, that is expected, but I think that it would be helpful to clarify the > description to make that clear. OK, thanks. >> It's a limitation of RADIUS. Everything RADIUS has to support 4K packets. >> Later RFCs allow for 64K packets. > [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 be obvious to everyone implementing RADIUS. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-add-encrypted-dns-07
On Dec 19, 2022, at 11:53 AM, Rob Wilton (rwilton) wrote: > It isn't really clear to me why some of the registries are needed, > specifically the ones in 8.4.1 and 8.4.2. Why not allow any v4 or v6 DHCP > attribute to be carried within the DHCPv6-Options or DHCPv4-Options field? The original intent of the document was to define a limited set of DHCP options which could be carried in RADIUS. i.e. option X would map to RADIUS attribute Y. After some discussion, this was deemed to be unworkable, and changed to the current method. The previous limitations were still kept, however. While it is useful, I could see issues with allowing any DHCP option to be transported in RADIUS. I'll have to dig deeper to get into details. > > (2) p 4, sec 3. DHCP Options RADIUS Attributes > > Absent any explicit configuration on the DHCP server, RADIUS supplied > data by means of DHCP*-Options Attributes take precedence over any > local configuration. > > This point may be worth discussing. Naturally, I would explicit > configuration to a network device to generally take precedent over implicitly > learned configuration from the network. I'm not sure which options are "implicitly learned" from the network. One set is configured in the device, and another is configured on a per-user / per-session basis. This allows for sane defaults, with specific over-rides where those are needed. If the options configured on the device always take precedence over the per-session options (via RADIUS), then there isn't much point in sending per-session options. > (3) p 6, sec 3.2. DHCPv4-Options Attribute > > Permitted DHCPv4 options in the DHCPv4-Options Attribute are > maintained by IANA in the registry created in Section 8.4.2. > > Comparing this text to the description for v6, this description is silent on > whether multiple instances of the same DHCPv4 option MAY be included. Should > that be specified here? Likely, yes. The RADIUS attributes are simply carrying DHCP options, as if they were in a DHCP packet. So all of the DHCP rules about option handling should apply here. > > (4) p 10, sec 7. Table of Attributes > > The following table provides a guide as what type of RADIUS packets > that may contain these attributes, and in what quantity. > > Am I right that this is just a duplication of what is described in section 3? > If so, perhaps change "guide" to "informative guide" and include text to > refer back to the canonical definition in section 3. Sure. This table is traditional in RADIUS RFCs, so the text here mirrors previous RADIUS RFCs. > (8) p 3, sec 3. DHCP Options RADIUS Attributes > > These attributes use the "Long Extended Type" format in order to > permit the transport of attributes encapsulating more than 253 octets > of data. DHCP options that can be included in the DHCP*-Options > RADIUS attributes are limited by the maximum packet size of 4096 > bytes. In order to accommodate deployments with large options, > implementations are RECOMMENDED to support a packet size up to 65535 > bytes. > > I didn't find this text clear. E.g., limit is 4k but should support up to > 64K. Which implementations should support larger packet sizes? Is this > RADIUS implementations? It's a limitation of RADIUS. Everything RADIUS has to support 4K packets. Later RFCs allow for 64K packets. > > (9) p 5, sec 3.1. DHCPv6-Options Attribute > > This field contains a list of DHCPv6 options. Multiple instances > of the same DHCPv6 option MAY be included. Consistent with > Section 17 of [RFC7227], this document does not impose any option > order when multiple options are present. > > Is there any requirement to merge multiple instances of options together, > presumably they are logically just concatenated today. The rules for DHCP options processing should apply. > (12) p 8, sec 5. Applicability to Encrypted DNS Provisioning > > Figure 1: An Example of RADIUS IPv6 Encrypted DNS Exchange > > As a minor comment, I wonder whether it would be helpful to also include > RADIUS client in the NAS box description? Yes. > > (13) p 12, sec 8.4.1. DHCPv6 > > IANA is requested 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 need to define the definition of columns for this (and the v4 > equivalent) registries. E.g., do the values need to match another registry? Perhaps just names? It would be good to avoid duplicating multiple columns, as they could get out of sync. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-01.txt
On Dec 1, 2022, at 1:14 PM, Marc Huber wrote: > I've the gut feeling that > >Peers MUST NOT use Obfuscation with TLS. > ... > isn't the best approach. This would break the transition process > compatibility for devices that don't encrypt on their own which move TLS to > an intermediate system (a reverse proxy, essentially). We're just going through this with RADIUS. We defined RADIUS over TLS 10 years ago, and left the MD5 obfuscation in. We're now updating it to remove MD5. In hindsight, it was a mistake. Among other things, leaving MD5 in means that it's difficult to run implementations in a FIPS environment. Plus, what key do you use for the MD5 obfuscation? Do you leave the old one in the admin interfaces? And add TLS? I think that the current approach is best. Drop the 20+ year-old obfuscation. Just use modern crypto. I'd suggest requiring TLS-PSK. It's likely easy to update implementations / interfaces to add a PSK. In contrast, certificates are more complex. Plus, operational experience with RADIUS shows that certificate management is a big problem. There are many issues with certificates: * do the client / server use Web CAs for certificate valdation? Are these web CAs shipped with the product? How are they updated? * If a private CA is used, then the implementations have to be updated to allow for configuration of CAs in addition to client certs * certificate expiry is rare enough that people forget how to renew them, but often enough that they have to be renewed regularly * web CAs won't issue certs for non-web use. So to get a cert, you have to claim you're putting it on a web server, and add id-kp-serverAuth in order to pass web CA validation * How are the certificates validated? There is a long list of things which can be done to validate the certificate. Some RFCs have guidance, but implementation experience shows that those aren't enough. I'd suggest checking the certificate validation rules in RFC 5216 and RFC 9190 (EAP-TLS), and RFC 6614 (RADIUS/TLS). The operational issues are similar. It may also be useful to look at RFC 7585 (dynamic server discovery via DNS). I'd suggest also looking at the TLS configuration in FreeRADIUS here: https://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/eap#L177 It's for EAP-TLS, 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-add-encrypted-dns
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. > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If you are aware of IPR, indicate whether or not this has been disclosed per > IETF IPR rules (see RFCs 3669, 5378, and 8179). > > Joe > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [dhcwg] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 17, 2022, at 7:41 AM, Bernie Volz wrote: > I was thinking more to put this restriction on the dhcp server, when it makes > use of the Radius attribute to respond to a client. I have no issue with it > being limited at configuration too, but the dhcp server should also make sure > only a limited set of options are sent to client. > > Leaving this wide open causes issues as it may be miss used to inject things > that really shouldn’t be. I agree. There should be a limited set of options which are allowed, perhaps via a registry. > Looking at it again, it is also unclear how a dhcp server is to use > information. For example, does the server use options from this information > before its own configuration or only if it has no configuration (I suspect > the former, as this is more client/request specific). That should be made explicit in the draft. I don't have opinions either way, but your point makes sense. > And from RFC7037, there is > > 169DNS-Server-IPv6-Address [RFC6911] > > Does this mean someone could now place the DNS server option into your new > Radius attribute instead of using this attribute to have the server map it to > the DHCP option? If it's allowed by the registry, presumably, yes. RFFC 6911 says that those RADIUS attributes can appear multiple times. So presumably it doesn't matter much if the DNS server information appears once in a RADIUS attribute, and 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 arguably doesn't have a lot of extra value. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 14, 2022, at 5:47 AM, wrote: > Let's try to exercise this approach and see if there are not hidden > complications vs. current design with known limitation. A drafty text (not > yet in the main draft) can be seen at: > https://github.com/boucadair/draft-ietf-opsawg-add-encrypted-dns/blob/main/draft-ietf-opsawg-add-encrypted-dns-encap.txt Nits: Section 3: just drop the ASCII art. RFC 8044 makes it no longer necessary. Section 3.1, 3.2, and 7.1: the data type should be "string" for "opaque data" Other than that, it looks good on first read-through. > The attributes should not be seen as opaque data by the RADIUS server but it > should understand the encoding of the enclosed options. The intended behavior > should be called out, IMO. I would suggest saying something like "for ease of administrator configuration, 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
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 4:19 PM, Michael Richardson wrote: > If I understand you correctly, the DHCPv6 option bytes would just be sliced > up into 253 byte fragments, and then reassembled into DHCPv6 options. Largely, yes. > The radius part need not respect the DHCPv6 option boundaries, but can fill > each DHCPv6-Options with as much as the fragment as fits. Yes. Similar things happen already with EAP packets. These are ~1K or more. RADIUS is just a transport, so "EAP goes in" and "EAP comes out". The EAP contents are unmodified. > Does Radius over TCP relax any of the 4K issue? No. But it avoids fragmentation of UDP packets. Which is positive. And RADIUS/UDP needs to die anyways, so Taking a quick look, nothing else in RADIUS mandates support for longer than 4K packets. However, I believe that many implementations 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 10:50 AM, Ben Schwartz wrote: > Even if longer SvcParams aren't useful in DNR, creating an encoding that > can't carry them introduces a serious compatibility problem for systems that > copy between SVCB, DNR, and RADIUS. What is such a tool supposed to do when > a valid SVCB record or DNR option is unrepresentable in RADIUS? What is a > naive operator to do, faced with this error message? The traditional RADIUS solution for encoding data which can't fit into an attribute is one of (a) truncation, or (b) dropping the attribute entirely. The standards are silent on this issue, so the behavior is entirely implementation-defined. As for this issue, it may be best to avoid it entirely with careful design, so that it's not possible for implementations to run into the problem. The only solution which entirely avoids the 253 octet limit is to just define a DHCPv6-Options attribute in RADIUS. It can carry a blob of DHCPv6 options, encoded as DHCPv6 options. This is behavior is permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4: Another exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. So just define a DHCPv6-Options attribute from the 245.X space. Allow it to contain any DHCPv6 option. Suggest that the switch / RADIUS client send the options in a DHCPv6 packet. And then it can carry the options needed here. Since the encoding is now DHCPv6 options, all limitations other than the 4K RADIUS "maximum packet size" limitation disappear. And many RADIUS implementations support packets larger than 4K, so that limit is not concrete either. The specification defining DHCPv6-Options could suggest that implementations SHOULD support 64K RADIUS packets. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote: > > Hi Alan, all, > > FYI, we do already have the following in the draft to pass RADIUS attributes > in DHCPv6: > > In deployments where the NAS behaves as a DHCPv6 relay agent, the > procedure discussed in Section 3 of [RFC7037] can be followed. To > that aim, Section 6.3 updates the "RADIUS Attributes Permitted in > DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]). I was thinking of the other way around: allowing DHCPv6 options inside of a RADIUS attribute. > For the typical target deployment in the draft, I don' think we have a valid > case for long data. That's said, we may include a provision to allow for > multiple TLVs; each carrying self-contained key=value data. If that's the target deployment, then that works. I'd suggest updating the draft to explicitly mention this limitation, and describe why it's acceptable. I'd also suggest changing the RADIUS attribute space from 241.X to 245.X. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 With 241.X, the maximum amount of data which can be carried is 252 octets. This space has to encapsulate all child attributes, including headers and contents. Which means that each individual child attribute can carry much less than 253 octets. With 245.X, the maximum amount of data which can be carried is limited only by the RADIUS packet length. Each child attribute 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
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 12, 2022, at 1:53 PM, Ben Schwartz wrote: > > A practical limit of around 4000 octets for SvcParams seems likely to be > fine. A hard limit of 250 octets has a real chance of becoming a practical > problem. I would encourage you to reconsider the format. There are a number of limitations which all have to be addressed in order for any solution to work. :( This specification requires "grouped" data, which generally means TLVs in RADIUS. However, it also requires "long" data, which is forbidden to be used in TLVs by https://www.rfc-editor.org/rfc/rfc8044#section-3.16 As the author of RFC 8044, I can say that there are good reasons for that prohibition. I can also say that there are good reasons why the prohibited functionality is needed by this standard. I'm not sure there are any perfect solutions. There's only varying amounts of holding your nose, and going with something which is the lesser of two evils. Off of the top of my head, one approach is to simply give up on transporting the DHCPv6 data as RADIUS attributes, and instead just define a DHCPv6-Options attribute in RADIUS, which carries raw DHCPv6 options. This attribute could carry ~4K of data, and be in a format which complies with RFC 8044. That would solve the problem not only for this use-case, but for any future one, too. Just define the DHCPv6 option, and then say "carry it in RADIUS attribute DHCPv6-Options" That makes it difficult for administrators to configure, as the RADIUS configuration now has to carry "raw" DHCPv6 data. But... it's RADIUS. That's the least of its ugliness. There's already something similar in DHCPv4: https://datatracker.ietf.org/doc/html/rfc4014 i.e. DHCPv4 carries RADIUS attributes. So there's reasonable precedent. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Add] WG LC: RADIUS Extensions for Encrypted DNS
On Oct 12, 2022, at 1:32 PM, Ben Schwartz wrote: > > The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets. This is a > problem, since it is meant to hold a SvcParams object that is allowed to be > much larger (up to ~65000 octets in principle). The length is less than 253 octets, as it is encapsulated inside of another attribute "wrapper". So the practical limit is probably 250 or less. RADIUS provides for encoding more than 253 octets in an attribute. See https://www.rfc-editor.org/rfc/rfc8044#section-3.16 However, this capability exists 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt
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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt
On Oct 5, 2022, at 10:21 AM, mohamed.boucad...@orange.com wrote: > > Re-, > > This version fixes the type for the ADN TLV. I would suggest also adding text on how to map RADIUS attributes to DHCPv6 options. Right now it's just Any implementors have to read multiple 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
Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS
On Oct 5, 2022, at 9:52 AM, wrote: > [Med] FWIW, https://www.iana.org/assignments/radius-types/radius-types.xhtml > lists the following: > > 144 DS-Lite-Tunnel-Name text[RFC6519] > > but RFC6519 itself says the following: > > The data type of the DS-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
Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS
On Oct 5, 2022, at 8:37 AM, Bernie Volz wrote: > One minor item you may want to look at is whether “text” is the best way to > label the following data type in Table 2: > > TBA3 | Encrypted-DNS-ADN | text | This-Document, | > | || | > Section 3.3.1 > > Perhaps “dns wire encoding” might be better? If it's encoded as a sequence of DNS labels (length + data, length + data, 00), then the correct RADIUS data type is "string" [RFC8044] Section 3.5: The "string" data type encodes binary data as a sequence of undistinguished octets. ... > Someone that just uses this table may get it wrong? While perhaps there is > some definition of “text” for Radius attributes, a quick check of some seems > to show that it is mostly used for textual values. RFC 8044 Section 3.4 says this: The "text" data type encodes UTF-8 text ... > But perhaps you have limited choices here and other dns encoded attributes > already use text? There are other attributes in RADIUS which encode host names, but those are all printable / UTF-8. I think this is the first RFC which uses the "dns encoding" format for DNS names. RFC 8044 allows the transport of non-RADIUS data types when that data is simply carried in RADIUS, and is not supposed to be interpreted or used by a RADIUS client or server. In this case, I think it's a wash. Everything else in RADIUS uses printable strings. But if this attribute is simply sent to a another system which copies it into a DHCPv6 packet as-is, then that's fine. i.e. "this attribute is then copied verbatim into a DHCPv6 attribute " Such text is missing from the document. The Introduction does imply that the RADIUS attributes can be copied to DHCPv5: However, there are no RADIUS attributes that can be used to populate the discovery messages discussed in [I-D.ietf-add-dnr]. But there is nothing which says "RADIUS attribute FOO is copied to DHCPv6 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 mapping. As an implementor, I would strongly prefer that the document gives explicit direction. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS
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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS
On Sep 15, 2022, at 9:39 AM, Qin Wu wrote: > Is relying on specific RADIUS attributes mandatory? Can we rely on other AAA > message, e.g., Diameter message protocol to populate DHCP messages, no? All RADIUS attributes can be carried inside of Diameter. This capability is part of Diameter, 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
Re: [OPSAWG] CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS
On Sep 14, 2022, at 10:28 AM, Joe Clarke (jclarke) wrote: > > Hello, WG. I like Henk’s subject icon. Makes for some attention-grabbing. > > This work has been discussed previously in opsawg, going back over a year. > The authors have continued to progress the work and would like to gauge WG > interest in adopting it. > > One might ask, why opsawg? The radext WG has been concluded, but, like > IPFIX, there is interest in continuing to produce extensions for RADIUS. It > was suggested by Benjamin Kaduk that opsawg was a potential fit for this work. > > 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 RADEXT if that ever restarts. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ SSH Enhancements Document
On Sep 8, 2022, at 6:47 AM, Douglas Gash (dcmgash) wrote: > The alternative approach is to utilise the authentication packet data field. > This field is used for all exchange of authentication materials in the > current T+ protocol for applications such as CHAP based authentication flows. > > The exchange of artefacts required for the SSH authentication can similarly > be embedded within the data field: the elements of the exchange would be > wrapped in an existing av-pair format. That seems like a reasonable compromise. > Our definition of the SSH authentication flow would then require us to cover > the needed av-pairs, and the behaviour/error conditions etc, required for the > SSH authentication flow. The formatting of the artefacts in the data field > would be left to the existing encoding format that is selected. I'm not clear what that means, but OK. The TACACS data fields are binary safe. So TACACS should be little more than an encapsulation layer for the SSH data. Ideally, the TACACS documents should specify how that data is encapsulated (named av-pairs, exchanges, etc). But the SSH data itself should be defined by a reference to an existing SSH document. > The potential advantage, from implementation perspective, is that the T+ > stack can remain largely as-is. The changes are limited to a couple of new > enum values for already existing enum ranges that and a bump is needed for > the version. > Currently devices and servers will have business logic for each > authentication type that they support, which use the data field (CHAP, > MS-CHAP etc). The SSH may become plugged into this same level in the stack, > which we can consider, is the appropriate place for 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
Re: [OPSAWG] TACACS+ SSH Enhancements Document
On Aug 31, 2022, at 2:35 PM, Marc Huber wrote: > This "new format" you think you're seeing isn't new, it's a slight > variation of the current implementations, with portions copied from > authorization/accounting to authentication, with wider argument lengths. > It perfectly suits the current code and implementations. It's new, but likely less new code than implementing CBOR, even if a CBOR library is used. > Nobody here is asking for TACACS+ 2.0, which would perhaps warant a new > format -- this is 1.2. There's absolutely no need to ask for CBOR or > any other over-engineered standard, the only thing needed here is common > sense. Nobody involved (as I hope and assume) wants a radical protocol > change. I think that's the strongest argument here. Much as TACACS+ is horrible, and patching it is horrible... doing TACACS+ 2.0 is a serious 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ SSH Enhancements Document
On Aug 30, 2022, at 3:48 PM, John Heasly wrote:
> It is not a new format, it is the format currently used in the
> authorization and accounting parts of tacacs, except with no fixed
> fields. AVPs are its own version of TLVs that have existed since the
> beginning of tacacs, so that code has existed as long.
It's changing the existing format for authentication packets. So it's a
change.. but to something which likely already has code support in TACACS+
implementations.
> We are not eager to remove the fixed fields that exist or make any
> drastic changes. Douglas assembled an example to ensure that we
> understood by example what Alan's comment was about - existence of fixed
> fields at all or that we'd originally proposed adding a fixed field (to
> make Authen consistent with Author/Acct) or something else entirely.
My concern was with adding a new header which was different from existing
ones, and which used yet more fixed fields,
>> Please consider RFC8949: CBOR.
>
> If you want the authentication part changed to CBOR or whatever the
> flavour of the month is, then you also want authorization and accounting
> to change? IE: you want a complete restructure of all of the packet
> formats used in tacacs.
>
> I do not see how that is less likely to result in bugs in areas unrelated
> to (de)serialization and will impede implementation.
There is no good solution here. There are strong reasons to just "patch"
existing implementations with minimal changes. That enables quick
implementation and deployment.
There are also strong reasons to use a modern format which has extensive
implementations: https://cbor.io/impls.html
If we stick with the current TACACS+ format, then we still need to serialize
/ deserialize the data. There are likely issues related to encoding binary
data in textual format. And perhaps multiple representation formats of the
same data.
If there is an argument against CBOR, it would be "CBOR doesn't match what we
need to do in TACACS+". As reference, the CBOR data types are:
• an integer in the range -264..264-1 inclusive
• a simple value, identified by a number between 0 and 255, but
distinct from that number itself
• a floating-point value, distinct from an integer, out of the set
representable by IEEE 754 binary64 (including non-finites) [IEEE754]
• a sequence of zero or more bytes ("byte string")
• a sequence of zero or more Unicode code points ("text string")
• a sequence of zero or more data items ("array")
• a mapping (mathematical function) from zero or more data items
("keys") each to a data item ("values"), ("map")
• a tagged data item ("tag"), comprising a tag number (an integer in
the range 0..264-1) and the tag content (a data item)
Does this meet the expected 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".
Using a standard format such as CBOR means that the initial cost to
implementations is large. But any further extensions are likely to be trivial.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-dahm-tacacs-tls13
On Jul 8, 2022, at 10:16 AM, Joe Clarke (jclarke) wrote: > > Hello, WG. The chairs are starting a three week call for adoption for the > TACACS+ TLS work that has been recently submitted. This work was initially > proposed at the same time the broader TACACS+ protocol was also brought the > working group. The consensus then was to create an informational draft > describing the as-is TACACS+ protocol (with all of its security shortcomings) > and to focus on more robust security later. > > This call for adoption is only for the > https://www.ietf.org/id/draft-dahm-tacacs-tls13-00.html draft and will go > three weeks to take into account the IETF 114 meeting in Philadelphia. > > Please reply on-list if you want the working group to adopt this work, as > well as with comments on the work as it stands currently. The CfA will end > 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
Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt
On Jul 8, 2022, at 11:49 AM, heasley wrote: > There are no other additions in dahm-tacacs-tls13, only deprecations > related to adding TLS. Perhaps you are thinking of the original composite > draft, which we split by request, or the second draft from that split > (dahm-opsawg-tacacs-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's good. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt
On Jul 8, 2022, at 10:06 AM, Joe Clarke (jclarke) wrote: > > I was saying that when I read Alan’s comments it seemed like he wanted for T+ > protocol changes and extensibility added to the tacacs-tls13 draft I would prefer that the tls13 draft is just "TACACS+ over TLS". I also reviewed the proposed additions to TACACS+ which is currently in the tls13 draft. But I believe that they belong elsewhere. > whereas my understanding of the original intent of this work (from when the > informational T+ draft was brought to this WG) was in line with 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
Re: [OPSAWG] I-D Action: draft-dahm-tacacs-tls13-00.txt
On Jun 30, 2022, at 3:09 PM, heasley wrote: > Speaking for myself only; I might have misunderstood this point of Alan's > and will have to review that email. I think that the approach is > straight-forward; start tls, once established, start tacacs, tacacs, end > tacacs, end tls. How much easier could it be. Yes. That's the hope. > We did specify a few TLS constraints, that Alan questioned. We're open to > discussing those details, but I think we need input from more tls experts > and believe this can occur after adoption. IIRC, that was our response at > the 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
Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt
On Jun 29, 2022, at 2:26 PM, heasley wrote: > We have received no comments about this draft, which I presume means no > technical objections exist. So, I would like to ask the Chairs for an > adoption call. I would suggest that ~3 weeks is a little too short a time frame to claim that there are no objections. I'll point to the previous TACACS+ document, where there were multiple reviews which got addressed by the authors many months later. I'll also point to my earlier review of draft-dahm-tacacs-tls13-00.txt, where I had concerns with extending the 1990s style TACACS+ packet format. The same concerns apply 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. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]
On May 3, 2022, at 12:23 AM, heasley wrote: >> It may be good to have a note that the existing TACACS+ port can be used >> for TLS, if both ends are configured to require TLS. That means systems can >> use existing firewall rules, etc. for TACACS+TLS. > > We discussed this and question whether this needs to be discussed in > the (any) document, because it is not unlike any other service, which may > be configured by the admin to use any port they wish. The point is to suggest that it can be done. i.e. It's acceptable for people to manually configure both client and server as both (a) TLS, and (b) using port 49. i.e. just drop the use of legacy TACACS+ entirely. > We also question if suggesting the use of 49/tcp will incite its use and > therefore the pitfalls described in S8.2?. Allowing a new port just for TLS is fine, too. But I do agree that STARTTLS is not useful. >> I'm not sure what a "zero-seconds lifetime" would mean. It may be better >> to just omit the ticket in that case. > > It means discard the ticket. See rfc 8446 S4.6.1. If I (not speaking > for the other authors) understand the TLS 1.3 spec correctly, it might not > be possible to omit the ticket. It's possible for tickets to be omitted. We checked this in EMU with EAP updates for TLS 1.3. > Also, IIRC, we discussed resumption in the context of an anycast or > load-balanced deployment, where there is no guarantee that the same physical > server would answer a request and there is no standard mechanism to > distribute tickets among servers, so both client and server likely want the > option to disable tickets. An attempt by a client to resume with a server > that does not have the given ticket can recover, but it takes time. TLS allows for session tickets with opaque data, under the control of the server. So the session ticket can be encrypted with a key shared by multiple servers. Which means load balancing, etc. works just fine with session resumption. This was checked when we did the updates for EMU. > We also had a concern about 0-RTT, which we mention in S8.1.2. I think > that 0-RTT is only possible with resumption - no ticket, no resumption, > and either side could enforce that. OK. > Tell me if I'm wrong. Else, if adopted, we would ask one of the TLS experts > to review and expect that they can help address resumption tickets and 0-RTT. > Russ Housley had made many helpful comments prior to adding these text to > the draft, but we have not yet asked that he review it again. That's likely not necessary. EMU checked that. >> It would be good to mention that TLS Server Name Indication (SNI) SHOULD be >> supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3). That >> way one server can act as the TACACS+ host for multiple domains, and switch >> between them using SNI. > > We had discussed this in the same context prior to submission. We concluded > it was not necessary, and that less (text) is more. I believe that data in > tacacs itself can be used to achieve this too. > > We are not opposed to adding it and suspect there is some utility we 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
Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]
On May 1, 2022, at 9:32 AM, Douglas Gash (dcmgash) wrote: > To this end, we have split your comments into 4 main issues, and I’ll be > making a response (your other points will be responded to shortly by the > other authors.) to the following points from your mail > .. > The purpose of Section 4 is to introduce arguments handling into > Authentication phase of the T+ protocol, to align it with the with the > authorization and accounting phases. To recap: authorization and accounting > phases have extensible arguments handling, authentication does not. Section 4 > intends to bring the same patterns we have in authorization and accounting > into authentication. That's useful, but my concern here is "feature creep". The original discussions were to (a) document historical TACACS+, and (b) add TLS transport for security. We're now well past that into extending the protocol with new features. > Regarding the Proxy Flow specifically: in the experience of the authors this > is not a new flow for T+: it is an established practice in the field. Which wasn't mentioned in the previous document, I don't recall seeing much discussion of it in relation to that document. The text in this document is clear that proxying is new, and requires a change to the TACACS+ version. Is this established practice? So what is the purpose of this document? TACACS+ and TLS? Or TACACS+ extensions? Or documenting TACACS+ 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
Re: [OPSAWG] [internet-dra...@ietf.org: I-D Action: draft-dahm-tacacs-security-00.txt]
This is a quick review based on first impressions.
It may be good to have a note that the existing TACACS+ port can be used for
TLS, if both ends are configured to require TLS. That means systems can use
existing firewall rules, etc. for TACACS+TLS.
Section 3.2 says:
the resumption ticket_lifetime SHOULD be configurable, including a zero seconds
lifetime.
I'm not sure what a "zero-seconds lifetime" would mean. It may be better to
just omit the ticket in that case.
It would be good to mention that TLS Server Name Indication (SNI) SHOULD be
supported (https://datatracker.ietf.org/doc/html/rfc6066#section-3). That way
one server can act as the TACACS+ host for multiple domains, and switch between
them using SNI.
Section 4 concerns me. This is not just adding TLS to TACACS+, it's adding
an entirely new flow: TACACS+ proxying. This is a major change to TACACS+, and
I would strongly suggest moving it to another document.
I would also recommend not defining a new packet type which extends the
horrific TACACS+ packet format. We've come a long way in protocol design since
the mid 1990s. The packet format is awkward, at best. It is difficult to
create and/or parse correctly.
Plus, what if the proxy wishes to forward information about the client
certificate, or server certificate which was used? The current format makes
this impossible.
My recommendation would be to take a page from DHCPv6, and just add an
encapsulation layer. e.g. a TACACS+ header with minor version 2, and a new
type signifying "proxied packet". That packet could simply be a container for
encapsulating the original packet.
i.e. instead of re-encoding the entire packet (with all of the issues and
errors that entails), just take the original packet, add a proxy header, and
send that essentially verbatim. This is much simpler, and has much less room
for errors.
i.e. a proxied packet could look like:
TACACS+ header (minor = 2, type = proxied)
proxy header {
length of proxy header
flag for is next header a proxied packet.
original src / dst ip / port
... potentially other data ..
}
length of original packet
verbatim copy of original packet
That format is simpler to encode/decode, simpler to understand, 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
Re: [OPSAWG] I-D Action: draft-vishwakarma-opsawg-ssh-cert-radius-02.txt
On Dec 31, 2021, at 11:34 AM, tom petch wrote: > > With one Normative Reference for RADIUS, one Normative Reference for TLS, one > Normative Reference for EAP and two for SSH, I wonder which WG is best > equipped to review this; curdle? Previous discussion from November 2020: https://www.mail-archive.com/search?q=ssh-cert=opsawg%40ietf.org On a quick scan, it looks like many of the issues raised for the -00 version aren't addressed in the -02 version. This proposal is really "EAP over SSH", and is not strictly tied to certificates. We also have an existing 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
Re: [OPSAWG] RADIUS Extensions for Encrypted DNS
On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote: > (sending the message to opsawg as I understood that radext is dormant and > related matters should be here) Officially alive, but in limbo. > We published this new draft as a companion document to some of the work we > are doing in ADD WG about discovery/provisioning of encrypted DNS servers > (DNS over TLS, DNS over HTTP, etc.): > https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/ On quick inspection it looks reasonable. The one thing I noted was Encrypted-DNS-ADN TLV, which is in the DNS "compressed label" format. Pretty much every other DNS name in RADIUS is in string format, not the compressed label. I understand why it's done that way, but it should be called out a little more clearly, I think. "note, this is not a humanly readable DNS name". The Encrypted-DNS names can be a little misleading. It might be worth reiterating that these attributes are not encrypted as with User-Password or Tunnel-Password. It's not that the text is wrong, it's that I've seen too many implementors do the "obvious" thing, and 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
Re: [OPSAWG] FYI- Executive Order on SBOMs- draft-ietf-opsawg-sbom-access
On May 17, 2021, at 9:09 AM, Michael Richardson wrote: > If MAC addresses become regularly randomized, then what is the unique handle > for each device? While some devices might not randomize their MAC address, > the fact that some do forces management systems to adapt. > I think that the answer is in the shape of hash of public (IDevID) key. The answer in much of the AAA space is "client cert", which is partially the same thing. For people who want actual MAC addresses, they can leverage the ID in the client cert to look up a server-side table of ID to MAC. 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 recommended. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)
On Apr 20, 2021, at 1:56 PM, Joe Clarke (jclarke) wrote:
> ... That is, while
> the "choice" is mandatory, you must make a choice and cannot use both
> shared-secret and whatever else may be added to this choice.
When we did this for RADIUS over TLS, we made the "legacy" RADIUS portion use
a fixed key for backwards compatibility. The TLS portion was then new, and
completely different from the legacy obfuscation.
i.e. when using RADIUS over TLS, there isn't even a choice of using a "shared
secret". Any GUI / config option must either omit it, or ignore it. Instead,
it uses the pre-defined fixed key.
> Except that when encryption is added to T+, one would want to
> rev/augment this module. To do so in a backwards compatible way, one
> might deprecate this choice altogether, but it would still be
> "mandatory". So the logical thing to do is still add an augmentation to
> offer an alternative to shared-secret (maybe called "leaf tls" or
> "container tls { ...}"). Now you have a value for the "obfuscation"
> choice as "tls", which is not obfuscation and could lead to its own set
> of confusion (i.e., am I really configuring true encryption?).
Not being overly familiar with YANG, I won't disagree with anything on how
YANG should or should not work.
If there's a choice about what to do, perhaps it could instead just use a
generic "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 "encryption type" setting being an "enum" style field of
obfuscation OR encryption would resolve my concerns.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)
On Apr 20, 2021, at 1:39 PM, Benjamin Kaduk wrote: > Reference? > External PSK is still a thing, and we even published RFC 8773 to expand its > use cases. That was my understanding from discussion on EMU about EAP-TLS. If that's wrong for TLS in general, OK. I don't think it substantially 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
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)
On Apr 20, 2021, at 12:02 PM, Joe Clarke (jclarke) wrote: > Agreed on the point that the current payload is obfuscated. The choice > element in the YANG module seems to want to be future-proof, too, such > that when true encryption is added, it could be augmented in as another > choice (instead of shared-secret obfuscation). We can't use this field for TLS, as TLS PSK has been deprecated in TLS 1.3 (outside of resumption). Would we want to use the same "key" field for a 1997-era ad hoc obfuscation as for (say) AES? That suggests to me that failure modes are (a) using simple ASCII words for AES keys, or (b) using AES keys with 1997-era obfuscation. Either failure mode is worrying. > If a single term was used for the choice and obfuscation was called out > in the description of the shared-secret leaf, would that be sufficient? I would 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
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS and COMMENT)
On Apr 20, 2021, at 9:29 AM, Joe Clarke (jclarke) wrote: > >> ** Section 4. choice encryption. Per the name of this YANG item and the >> description (“Encryption mechanism between TACACS+ client and server”), >> please follow the convention of Section 4.5 of RFC8907 of calling this >> “obfuscation”. >> [Bo]: The reason we define this "encryption" choice is that shared-secret >> leaf is mandatory per RFC8907, but future TACACS+ protocol may define >> encryption node to replace the shared-secret leaf. Therefore, is it clearer >> to change "encryption" to " obfuscation-encryption"? >> > > Today, we only have the obfuscation-by-shared-secret. In the future, we > may have TLS or some other stronger encryption. If we insist on making > the module forward-looking, should we rename this something like privacy > (similar to how SNMPv3 names this)? I agree with Roman that encryption > is a bit strong of an umbrella under which to put shared-secret. There was a long discussion in OPSAWF about this for the main TACACS document (RFC 8907). That document says: 4.5. Data Obfuscation The body of packets may be obfuscated. The following sections describe the obfuscation method that is supported in the protocol. In "The Draft", this process was actually referred to as Encryption, but the algorithm would not meet modern standards and so will 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
Re: [OPSAWG] draft-vishwakarma-opsawg-ssh-cert-radius-00
I didn't see the original notification go by, so I'll respond to Stefan's post. In short, I agree with Stefan. :) Nits: Section 2.1, I suggest just deleting the mention of a particular product. Everyone knows what a RADIUS server is. The typical IETF draft doesn't mention _any_ product unless it's in the context of what it gets wrong (to fix) or right (to standardize) I'd echo Stefan's comments about just using EAP, instead of mentioning certificates. The benefits are even more than using certs, as EAP provides for many more kinds of authentication types. There should be much more detail on exactly how the EAP packets are transported in SSH, and how the SSH negotiation decides to use EAP. Finally, there should be a discussion of how certificates are managed on the SSH client. There will likely be need for a *separate* certificate store for use with SSH, as with 802.1X. There should be a hard requirement to not trust the default root CAs used for web traffic. Instead, each CA MUST be configured separately for use with SSH. The draft should also discuss how the client certificate is chosen. Section 3.2 has some text, but it is insufficient: The SSH client MUST choose a client certificate installed in the operating system as described in the section 2.1 Basic Setup. If there are multiple client certificates then the SSH client SHOULD choose a client certificate. If there is no certificate installed on the SSH client, then the client MAY choose another authentication methods defined in [RFC4251]. Except Section 2.1 does not say how to choose the client certificate. And the text above repeatedly says "choose", but doesn't say *how*. The document also needs to say how the *server* certificate is validated. The good news is that SSH can know the hostname of the server it's connecting to, unlike 802.1X. So all of the typical Web checks for "cert matches hostname" should apply. and should be discussed here. Which then means that the client certificate (if used) should be chosen based on the hostname being connected to: use the "user@hostname" field to find a matching client certificate. Then, verify that the server certificate comes from the same root CA, and that the server certificate CN field matches the hostname being connected to. I suggest 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 decrease deployment complexity. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Red: RFC8907 (was: Re: Can we please adopt draft-tuexen-opsawg-pcapng?)
On Nov 12, 2020, at 5:02 PM, Toerless Eckert wrote: > > Interesting document (RFC8907). > > Several problems i see that would be good to avoid (althoigh not all are > applicable to subject draft): > > - The RFC It does not mention who developed the protocol. It may be clear to > the ones in the know > (or who read THEDRAFT), but i remember older RFCs that clearly state when a > protocol > is a proprietary vendor protocol not developed by the IETF. I think this RFC > should > have done it too for clarity. BY not writing it clearly, it looks like a > particular > vendor endorsement by IETF in an inappropriate fashion. That's a reasonable point. But the doc is "Informational", and the protocol has a 20+ year history. So it's pretty clear where it came from. And, that documentation does not imply endorsement. > - This RFC does not not explain who has change control over the protocol. I > would guess > that Cisco wants to maintain change control, but the fact alone that i have > to guess > and that this is not written out makes this a problematic IETF product. Which is why the specification is Informational. It documents existing practices. Updates to the protocol (if any) will be under IETF change control. > - This RFC does seem to mix the solely vendor defined and controlled protocol > with > a profile subset of what the IETF WG deemed to be important enough for > todays use, > but it merges both into a single document. It would have IMHO be a lot > better to > have had a separate document just for the proprietary protocol (in whatever > form, > independent submissions seems good), and then a small RFC solely with the > profile. > That profile RFC could then even have been a BCP. There was a very long discussion about this topic. The document describes WG consensus. In short, there was significant objection (including at the IESG level) to documenting insecure parts of the protocol, even if it was just historical practices. The decision was to document what "worked", while deprecating the worst parts. The remaining bits were acceptable under the "holding your nose" kind of thing. > - Of course, if change control would have been given up by Cisco and passed > to IETF > and this was written into the document, then merging the proprietary > protocol with > the IETF WG defined profile would be ok. Still not my preference. The WG discussion was that any next step was to write a spec which pretty much wraps TACACS+ in TLS, and call it secure. There are additional details, but that's the basic idea. Given the larger implementation deployment of the legacy TACACS+ protocol, it's simply impossible to make substantive changes to it. i.e. any "clean room" redesign is just not going to be supported by _any_ vendor who currently implements TACACS+. > - I don't understand how that RFC can have BCP14 language. I thought that was > reserved to > standards track IETF documents ? That's a question for the IETF process as a whole, not for this WG. There are many other Informational documents which use RFC 2119 language, including 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
[OPSAWG] draft-ietf-opsawg-tacacs-18.txt
One minor comment on reading the latest draft. Section 4.1 defines the packet header, and defines a 32-bit length field: length The total length of the packet body (not including the header). It would be good to state limits on the values of this field. i.e. lengths larger than 2^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
Re: [OPSAWG] RADIUS Extension, Getting Started
On Jul 10, 2020, at 8:08 AM, Massameno, Dan wrote: > Thank you for your thorough review. I am completely new to the IETF process > (I don't even know what a "nit" is) and I'm looking forward to the process. "nitpick". i.e. minor point which should be fix, but isn't very important. The IETF process is long, but generally worth it. > I did want to dive into one of the last comments you made. > >Even if the various nits and and issues above were fixed, this > proposal would 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 balancing more properly belongs in the server. > > If I have N number of RADIUS servers, how are the servers supposed to load > balance if the load balancing function "belongs in the server"? You run a load-balancer. This is either a hardware device which does UDP load balancing, or a dedicated RADIUS server which does nothing more than load balancing. > Won't the NAS need to know about all the RADIUS servers? If yes, how does > it decided on which one to user for any one particular session? The NAS knows about one server: the load balancing one. Typically the load balancer can be set up in an HA pair, using VRRP to share an IP address. My experience is that this scenario is robust, stable, and gives the admin a great amount of control over the system. My experience also has been that you just can't rely on the NAS to do anything sane with RADIUS. The implementations are terrible, naive, simplistic, etc. Just give up on fixing them, and patch over the problem with a RADIUS server that's under your control. It's easier for me to say, of course, having written a RADIUS server. That does bias me a bit, I think. But practical experience validates this approach. A different explanation for the NAS behaviour is that the NAS vendors are incentivized to make the core functionality work well. e.g. switching, WiFi, etc. Features such as RADIUS are an after-thought. Issues with RADIUS are only fixed if a sufficient number of customers demand changes. In contrast, a RADIUS server vendor is strongly incentivized to implement RADIUS correctly. And, to do load balancing correctly. With many parameters that can be tweaked for your exact situation. So independent of anything else, NAS vendors simply aren't motivated to implement complex RADIUS load balancing. Whereas RADIUS server vendors have been shipping it for decades. > My experience with Cisco devices indicates that if multiple RADIUS servers > are listed it simply uses the first one exclusively until it fails. So, > there is failover, but no load balancing. The list of RADIUS servers are > also statically configured via CLI, which is cumbersome when there is a large > fleet of devices to configure. These two overly sophomoric features were the > ones I was endeavoring to fix. Most RADIUS clients behave the same way. My recommendation for a long time has been to just punt on the problem of fixing the NAS. Instead, run a RADIUS server that you control. One benefit is that you can upgrade the NAS, or change vendors without changing the way that load balancing works. And to re-iterate... RFC 5080 Section 2.1 defines retransmission behaviour for RADIUS clients. Implementing this would make customers lives easier. It would make RADIUS systems better and more stable. But the incremental benefit is simply not high enough for NAS vendors to implement it. So instead, they use fixed-count and 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 "buy a load balancer", or "download FreeRADIUS and run it in a VM". Problem solved. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] RADIUS Extension, Getting Started
You should just reference that. * Section 5.3 defines a table of attributes, including attributes not previously seen in the document. I suggest moving the table of attributes to later in the document, *after* the relevant attributes have been defined. * Section 6 There's no need for ASCII art. RFC 8044 Section 2.1.2 makes this clear. Just reference the data types. * Section 7.1 The document says: ... Under these Status-Server-LB rules the NAS MUST send all RADIUS messages relative to a particular session to the same RADIUS server to maximize the probability of a cache-hit. What then, is the utility of land balancing? If one RADIUS server goes down, cannot the NAS send packets for a session to a different, but *equivalent* RADIUS server? This recommendation seems to drastically increase the likelihood of losing accounting packets, which seems bad. In addition, the discussion of "caching" seems odd, and uncommon. Databases do user replication, not RADIUS servers. We should not expose implementation details in a standard document. i.e. the RADIUS servers should be treated as identical, and local balancing should be done on a packet by packet basis. * Section 7.2 The document says: The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being used for AAA services. Ok, *how* is this to be done? Specifying this behaviour seems important. Perhaps adding up all weights of a similar priority, and choosing a "W_i" at random, with probability W_i / Sum(W_0. ... W_n) * Missing: discussion of shared secrets, authentication vs accounting, ports, TLS, TCP, etc. What shared secret is used for these different RADIUS servers? The same one as used in the original Status-Server? What ports should the NAS send packets to? Does this load balancing work for all packet types? What about TCP, UDP, TLS, etc.? How does this proposal interact with dynamic discovery? (RFC 7585) * Section 8 The document says: RADIUS Server Load Balancing has many of the same security implications as the base RADIUS protocol. There are many additional security issues opened up by this new capability. They should be discussed. * Section 10 The document says: The Vendor Specified Attribute 26 may be used to encapsulate the LB- Request and LB-Response PDU where no vendor interoperability is required. It is very odd to put standards text inside of an "IANA considerations" section. Further, this text appears to be confused about the purpose of the RADIUS attribute numbers. These numbers are location-sensitive. i.e. vendor attribute "191" has no relation whatsoever to attribute "191" in the main RADIUS space. Similarly, it has no relation to an attribute "191" from another vendor. This text is wrong and should be deleted. Summary: Even if the various nits and and issues above were fixed, this proposal would 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 balancing more properly belongs in the server. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09
On Jan 6, 2020, at 9:29 PM, Haoyu Song wrote: > [HS] Indeed I tried to describe some practical problems on applying a > specific set of techniques and then to propose an architecture (we call it a > framework). A solution can be based on it, but itself cannot be used as a > solution directly. Then this document describes an architecture, not a solution. Which is fine. There are many IETF architecture documents. But they are rather less enthusiastic. > [HS] What I want to express here is that, as far as I know, no other OAM > technique provides the same capability as this new type of technique such as > IOAM. I can change the word if it sounds improper. Then say "no existing technology solves this problem". That is a statement of fact. Engineering is done on facts, not on enthusiasm, > [HS] I'm fully aware of the existence of ForCES, I just didn't see its wide > application in real products. Irrelevant. The programmable data plane was being standardized going back to 2000. So this document is entirely wrong when it says "with the advent of the programmable data plane". What would be factual would be to say "existing technologies do not fix this problem". > [HS] Fair enough. I would use simple words instead. After reading the > document, I hope the reader can recognize the issues and agree that our > proposed framework or architecture makes sense for practical deployments, 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09
On Jan 5, 2020, at 3:04 PM, Warren Kumari wrote:
> I've just (re)read this, and have some concerns -- I found it somewhat
> hard to dig into the actual technical "meat" of the document
> (channeling Randy Bush "Where's the protein?") - it feels like it
> describes a bunch of benefits and features of a solution, but without
> actually describing the solution itself.
The document appears to be largely philosophic, not practical. At no point
does the document describe how anyone can implement anything.
From the abstract:
iFIT
provides several essential components that can be assembled to
achieve a complete and efficient solution for on-path telemetry.
The components described in the document cannot be described as "complete",
or "efficient", or a "solution".
> The Abstract says that in the
> document "a high-level framework, In-situ Flow Information Telemetry
> (iFIT), is outlined.", but I couldn't really find it. Section 2 ("iFIT
> Framework Overview") is so very level that it doesn't really seem to
> say much at all.
The abstract is surprisingly long, while saying surprisingly little.
> This, and the general tone of the document, feels like a marketing
> driven exercise - the document describes a bunch of features and
> benefits of a solution, but without the detail needed to implement it.
It is impossible to implement anything based on this document.
As an example of odd text:
In addition to efficient export data encoding (e.g., IPFIX [RFC7011]
or protobuf [1]), iFIT nodes have several other ways to reduce the
export data by taking advantage of network device's capability and
programmability.
That statement is simply content-free. It might as well say "nodes are
capable of communicating via a variety of communications methods".
To me, the document reads largely likely a patent application, but with no
supporting details. It claims the widest possible applicability for the
"solution". 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
Re: [OPSAWG] New Version Notification for draft-zheng-opsawg-tacacs-yang-01.txt
On Mar 17, 2019, at 5:30 PM, Alex Campbell wrote: > > Are you sure about that? I don't see anything specific to TACACS+ in > ietf-system-aaa.yang. That's not the point. Is this a TACACS+ YANG model, or is this a AAA YANG model? If it's a AAA YANG data model, then there are already two AAA working groups which haven't been consulted about this work. The aaa-doctors group hasn't been consulted, either. There are still people working in this space who might have input here. There is already a RADIUS YANG module, which seems relevant. It was done without consulting the RADEXT WG, either, or the aaa-doctors list. It also doesn't match RFC 5080 for retransmissions, and doesn't allow for non-UDP transports, despite RFC 6613 (TCP), RFC 6614 (TLS), and RFC 7630 (DTLS). But that's a separate point. IMHO, this document should focus on the TACACS+ needs, and define a YANG data model for TACACS+. It should *not* define a generic AAA YANG data model. It should *especially* not define a generic IETF AAA YANG data model in a document that's mixed up with a non-AAA protocol. As for "nothing specific to TACACS+", please see the text in the abstract: The data model of Terminal Access Controller Access Control System Plus (TACACS+) client allows the configuration of TACACS+ servers for centralized Authentication, Authorization and Accouting. TACACS+ is not an AAA protocol. We're had this discussion going back years. If we look at the document further, we see: 4. AAA Model Augmentation This document augments the system model with authorization model and accouting model to support full AAA feature. So it's not augmenting the AAA model as the title suggests. It's adding an entirely new AAA model to the ietf-system model. So that's confusing. It continues with the next paragraph: For the authentication model, if the NETCONF server advertises the "tacacs" feature, the device also supports user authentication using TACACSPLUS. For NETCONF transport protocols that support password authentication, the leaf-list "user-authentication-order" is used to control if TACACSPLUS password authentication should be used. So the only *example* of the ietf-aaa model is TACACS+. The document continues with: For the authorization model and accouting model, the extended AAA data model has the following structure: OK, so there's nothing *specifically* about TACACS+ in the YANG diagram. That part is at least true. But to address your first sentence quoted way above, the next section is: 4.1. User Authorization Model Following authentication, a user must gain authorization for doing certain tasks. For instance, the user may try to issue commands. The authorization process determines whether the user has the authority to issue such commands. This document defines two optional authorization YANG features: "local-users" and "tacacs", Which entirely contradicts the claim that there's nothing TACACS+ specific in the model. In fact, the model *explicitly discusses* "ietf-aaa" as being (a) local users, or (b) TACACS+. There are *zero* provisions for the the model more generic, e.g. to include RADIUS. I don't even know why we're having this argument. The document is absolutely clear that "ietf-aaa" is for TACACS+, and not for any of the *actual* AAA protocols that we've been using for 30 years. The document goes so far as to omit those other protocols entirely from consideration. Again, if this document is for TACACS+, it should define a TACACS+ YANG model and let it be. If there's a need for a more generic ietf-system-aaa YANG model, then perhaps we should discuss that with the AAA people. And if we 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
Re: [OPSAWG] New Version Notification for draft-zheng-opsawg-tacacs-yang-01.txt
On Mar 15, 2019, at 4:48 AM, Wubo (lana) wrote: > > Dear WG, > > We uploaded the 01 version of draft-zheng-opsawg-tacacs-yang-01 to address > some comments since last meeting. > https://tools.ietf.org/html/draft-zheng-opsawg-tacacs-yang-01 > > Here are some major changes in this version: > - Align the tacacs YANG structure to system(RFC 7317) Radius client YANG > naming. > - Change major tacacs properties to be configurable for each tacacs-server. > - Add the authorization and accounting model as a system augmentation to > support the full AAA configuration. Please don't refer to TACACS+ as an AAA protocol. It's really not. It's a management protocol, and doesn't do generic user AAA. Using "AAA" here is just confusing, IMHO. e.g.: Additionally, to support full AAA feature, the "ietf-aaa" YANG module The document later refers to "ietf-aaa-tacacs", not "ietf-aaa". I would strongly suggest changing the name of the model to "ietf-tacacs". Similarly: module: ietf-system-aaa Please change this to ietf-system-tacacs. I don't see it as at all useful to re-define "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
Re: [OPSAWG] TACACS+ IMPLEMENTORS: Does your implementation match draft-ietf-opsawg-tacacs?
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 _or_ if it is known _not_ to be compliant. We've implemented it in FreeRADIUS. (Perhaps mis-named...) * we support the TAC_PLUS_UNENCRYPTED_FLAG, tho that may change. * Does treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL (follows recommendation in 9.5) * Does not take any steps to ensure the channel is secure (this is left up to the network administrator) * it supports PAP, with CHAP and MS-CHAP in the works > If the latter, and your implementation is known not to be compliant, > what does your implementation do differently? > > If the former, an explicit acknowledgement that your implementation is > compliant (and the name/vendor of said implementation) will be helpful > as this document moves to the IESG. > > If you know of T+ implementors that may not be on the opsawg@ list, > please forward this to them, and ask them to comment on list. > > Thank you. > > Joe (on behalf of the opsawg co-chairs) > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
ementations. > TACACS+ server deployment administrators SHOULD use "configure". Not "use". I "use" a pencil. I "configure" an implementation. TBH, you should audit the document for instances of "use", and replace them with something more appropriate. > the option mentioned in the previous paragraph. TACACS+ Server deployments > SHOULD ONLY use other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or > TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of > identity/password systems. > > TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in > the original draft SHOULD not be used, That's one instance where "used" is appropriate. > due to their security implications. TACACS+ server implementations SHOULD > deprecate them, if they are not deprecated, the implementations MUST default > to the options being disabled and MUST warn the user of their security impact > if they are enabled. That's good. > 9.5.4 Authorization > > The authorization and accounting features are intended to provide > extensibility and flexibility. There is a base dictionary defined in this > document, but is may be extended in deployments by using new attribute names. > The cost of the flexibility is that administrators and implementors MUST > ensure that the attribute and value pairs shared between the clients and > servers have consistent interpretation. And how is that done? The appropriate IETF answer here is "run away screaming". :( i.e. not a subject you want to touch in this draft. > If a client implementation receives receiving a mandatory authorization > attribute that its implementation does not define, then it SHOULD behave as > if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. I'm wary of the word "behave" here. It seems philosophical again. I can't offer much better here tho. > TACACS+ server deployment administrators SHOULD mandate that TACACS+ > authentication was used when processing authorization requests (i.e. > authen_method value is set to TAC_PLUS_AUTHEN_METH_TACACSPLUS). Again, "mandate". Why not "administrators SHOULD configure TACACS+ authentication for processing authorization requests..." > 9.5.5 Redirection Mechanism > > The original draft described a redirection mechanism > (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The the > option to send secret keys in the server list is particularly problematic. nit: "the the". And why is it problematic? Perhaps "insecure", with an explanation as to why. > TACACS+ server implementations 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 implications if the option to send the secret keys in the server > list is configured. Security implications which are...? The draft doesn't say. Perhaps just "MUST warn administrators that the option is insecure and should only be used inside of a trusted environment" > TACACS+ client implementations SHOULD deprecate this feature by treating > TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 13, 2018, at 11:39 AM, Randy Bush wrote: >> >> Also, we have *no idea* if the document matches current implementations or >> deployments. The proponents of TACACS+ have been surprisingly silent on >> this topic. > > i am missig the example of where it does 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 was a recent implementation. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 13, 2018, at 11:30 AM, Joe Clarke wrote: > > I am hoping to start a WGLC at the Tuesday meeting, and cary it over to > the list to make it official. There are still unaddressed comments. Do we do WG last calls for unfinished documents? Also, we have *no idea* if the 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. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 13, 2018, at 10:29 AM, Randy Bush wrote: > i do not think we are gonna 'fix' the security model. this is a widely > deployed antique we are just trying to document so new victims can > interoperate. That has been the goal all along. Along with the goal of documenting security issues. > i am a little slow, so would appreciate if someone could make a simple > enumertion of the substantive issues so we can tick them off, instead of > ticking me off, and get this puppy the heck out the door? I think the current proposals are pretty close, at least from my end. 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
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 13, 2018, at 1:00 AM, Douglas Gash (dcmgash) wrote: > 9.5 Deployment Best Practices > > With respect to the observations about the security issues described above, a > network administrator MUST NOT rely on the obfuscation of the TACACS+ > protocol and TACACS+ MUST be deployed over networks which ensure privacy and > integrity of the communication. TACACS+ MUST be used within a secure > deployment. Failure to do so may impact overall network security. "may"? It's much stronger than that. Secrets will leak, people will be able to spoof credentials, etc. It *will* impact network security. Severely. > The following recommendations are not part of the definition of the protocol. > Rather, they impose restrictions on how the protocol is applied. Specific > requirements of the TACACS+ server and TACACS+ client implementations are > mandated to make it easier for the administrators who deploy TACACS+ to adopt > the restrictions. That last sentence is unclear to me. And mandates don't make it easier, they make it harder. But the mandates are necessary for security. > Some of the specific requirements mandated for TACACS+ servers and TACACS+ > clients may not be present in currently deployed implementations. This is > accepted as situational fact, and these implementations may still be regarded > as correctly implementing the TACACS+ protocol as long as they conform to the > details in other sections of this document. The spec doesn't need to say "yes, all existing implementations are OK". This list has had long discussions on that topic, which I suspect was due to general unfamiliarity with the IETF process. I don't think it's necessary to put that statement in the document. There have been many, many, historical protocols documented in the IETF. None that I recall have a statement explicitly blessing existing implementations. The document *should* say that it documents TACACS+ as per existing implementation and practice. BUT for security reasons, certain parts of the protocol and/or deployment practices are deprecated for security reasons. > New implementations, and upgrades of current implementations, SHOULD > implement the recommendations. And that SHOULD means "you don't really need to adopt the recommendations". 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
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 11:42 AM, Andrej Ota wrote: > Agreed. We (authors) were trying to put in more of the background as to what > are the threats for this reason - empowering those who need to deploy the > protocol to make the correct call. > > Though I'd flip this and put emphasis on what behaviours are secure and > declare others explicitly insecure. Sure. It would be useful to explain why they're insecure. But that's largely a nit, not a serious disagreement. >> The alternative is to leave the reader to fend for himself. "Hmm... the >> authors didn't say this was bad, so let's do it!" > > No, that would be really bad outcome and I agree we must avoid it. > > Let us (authors) take this recent feedback on board and reword things along > the lines: > - Use MUST where we want programmers to do the right thing, but be careful > not to distort the actual protocol as currently implemented. I agree that we shouldn't *change* the protocol. But *deprecating* portions is entirely appropriate. Given the insecure nature of it, I would say it's *required* that we deprecate insecure portions of the protocol. > Handling secrets, passwords seem like good targets for this. > - Keep and improve verbiage documenting known risks. > - Give either MUST verbiage where there's only one thing to do (e.g. secured > transport is a MUST). > - Give SHOULD where there's multiple things (e.g. 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
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 10:11 AM, Andrej Ota wrote: > Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a > position to intercept TACACS+ traffic, she can flip a single bit in the > authentication response and that will ensure that the device (client) will > consider authentication to have succeeded. Obfuscation doesn't help, only > secured transport does. Yes. > Thus it's irrelevant to specifically mention any particular currently used > authentication method as all of them fail in exactly the same way *and* it's > irrelevant to distinguish between obfuscated and non-obfuscated variety as > MitM will succeed regardless. Yes and no. It's still bad to send clear-text passwords over a clear channel. That can be called out and explained. > Since this makes secured transport a minimal necessary requirement for any > secure deployment, what benefit is there to try and find further examples of > what can be mandated if none of the mandates would meaningfully change the > end result? It's useful to explain *what* behaviours are insecure, and *why* they are insecure. The alternative is to leave 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
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 10, 2018, at 3:52 AM, Andrej Ota wrote: > > Could it be that we misunderstood each other as to what b) pertains to? a) is > obviously wrong as we certainly don't have to stop at documenting current > practices or even care about current practices if they result in an insecure > deployment. > > For b) I don't find it controversial as long as we can agree that > "implementation" means "how clients and servers implement documented > protocol" and not "how do operators deploy clients and servers". I.e. > "implementation" and "practice" refer to two different things. The draft should document how to implement *and* deploy TACACS+ as securely as we know how. If that "invalidates" current implementations and practices, too bad. Again, vendors and administrators are free to ignore the recommendations of the draft. But they need to *know*. If the draft permits deployments we know to be insecure, then that's wrong. And yes, such practice *would be* "rubber stamping" existing practices. While the requirement is to document the historical protocol, that does *not* mean endorsing 20 year-old insecure practices. The IETF has a responsibility to secure the Internet, among other things. Where that responsibility conflicts with vendor / operator desire to do insecure things, then the larger Internet security will prevail. > Then we can comb for ambiguous statements like "server MUST implement CHAP in > exclusion to PAP" and reword them to say "operators MUST use servers and > clients configured to disallow authentication methods other that CHAP". PAP is fine so long as (a) it's in a management network, 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 mechanism." Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 9, 2018, at 5:17 PM, Andrej Ota wrote: > I think that forbidding some parts with MUST would go against the original > mandate for this draft which I understood to be documenting what's used and > specifically not working to do a revision of protocol (which I would love to > hide behind TLS). The IETF is not about rubber-stamping existing implementations or practices. As a case in point, in 1993, the original RADIUS implementations had provisions for "change user password". That was remove (in *1993*), because it was insecure. I doubt very much that the security requirements have been *relaxed* in the subsequent 25 years. > The problem with the protocol as it's implemented today is that it's "unsafe > at any speed". There is nothing that either servers or clients can do to > change that on a protocol level. The only sensible normative text would be > MUST NOT implement. This in my mind shifts the focus from implementation > constraints to operational requirements. I disagree. There are portions of the protocol which are vaguely "OK", such as insecured names/passwords being sent in the clear over a management network. Ugly, but somewhat acceptable. There are portions of the protocol which *no one* would agree is a good idea today. e.g. sending secrets to a client. That's just... bad. > If we there isn't even one sensible implementation band aid (and I certainly > don't see one), we can only apply deployment band aids. There are many sensible implementation suggestions. > Net sum of both is that the document veered away from normative and into > realm of "here are the facts about insecurity of the protocol, use your best > judgement when deploying". > > We can certainly turn the draft back into more normative but I don't think > that we can do anything to the protocol itself that would salvage it in any > useful form whatsoever. The point (again) is that we should document the protocol, *and* recommended best practices. 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 all of the non-TACACS+ people read it, and go "OMFG you can't *do* this in 2018." Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 9, 2018, at 5:36 PM, Joe Clarke wrote: > I hear and understand what you're saying. And if this were a net new > protocol, I'd agree with you 100%. But the mandate for this document is > to describe how T+ is implemented today[1]. So... a) we rubber-stamp existing practices and implementations, no matter how insecure or b) we describe the protocol, along with recommendations for how best to secure it. I think that (b) is the best approach. I don't understand why we would ever choose (a). > Today, people are deploying > it with all sorts of security issues because that's how the protocol works. Perhaps the IETF could give guidance on best practices? Along with what parts of the protocol are insecure, and should be avoided? > On top of that, new implementations that change behavior could be > incompatible with existing clients. If those existing clients are insecure and allow people to pwn your network, then I don't really have any sympathy. And as always, vendors are free to ignore the recommendations of the specification. But at least after the admin gets pwned, he can point to the spec and say "YOU KNEW. IT'S YOUR FAULT." The alternative is to tell the admins "We knew, but we didn't care." That's not acceptable. > As a new _implementor_ of a server, I'd rather not repeat the protocol > flaws of the past if a new security model is coming (i.e., within a new > draft). So my thinking is that we recommend what we can for deployment. > Will Sec AD accept this? I don't know. I don't know that they've been > asked. I've been on secdir for a long time now, and have seen hundreds of reviews. If the WG punts on security, secdir will punt the draft back to the WG with a comment of "you can do better." I'm here *as* the early secdir review. Look, I can go away and stop fighting this issue. You'll spend 2 years updating the draft. Which will then get punted by secdir. And you'll be back in the same place you are today. Again, it looks VERY 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
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 9, 2018, at 4:54 PM, Joe Clarke wrote: > Below are some of my comments. They mainly revolve around the strength > of the normative language with respect to the fact that this draft is > supported to document the protocol as it is today. To me, the security > considerations should reflect best common practices without > over-enforcing things that would invalidate current implementations. I think that the security considerations section *should* invalidate insecure implementations. > But I want the WG's thoughts on this. How do we handle the case where > we have existing deployments that we want to document while at the same > time recommending new _implementations_ do better things? We recommend that *all* implementations do the Right Thing. If an admin installs a product released before the recommendations, then it clearly won't comply. That's life, and there isn't much we can do about it. But there's just no reason to allow new releases to ignore modern security practices. > And if new > implementations should be using a new security paradigm to be described > in a new document, do we need strong normative language in this draft? Yes. >> TACACS+ servers MUST NOT accept any new sessions on any connection where an >> invalid shared secret is detected. TACACS+ servers MUST terminate the >> connection on completion of any sessions that were previously established >> with a valid shared secret on that connection. > > The MUST here seems too strong given that some implementations that are > working today may not/may do these things. These don't seem to be > things completely within the operator's control as they deploy T+. These implementations are written before modern security practices. We can't invalidate software that's already written and running in the wild. We *can* recommend that vendors && admins have the best possible security in the products they ship and use. >> TACACS+ server and client implementations MUST treat shared secrets as >> sensitive data to be managed securely. > > How is this done? "implementation specific". :( > This seems like it could be handled in different > ways, and making this a mandatory requirement could invalidate current > implementations. One word: upgrade. >> TACACS+ client implementations SHOULD deprecate this feature by treating >> TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. > > So, again, strong normative language makes sense if I'm building a new > implementation, but this is a doc to define the protocol as-is. And, to describe how to *use* the protocol as securely as possible, given it's limitations. > In > light of that, I am asking the WG if we need to go down this path or > should we try and focus on recommendations, especially for operators, > that can better secure the T+ they have today. I think that if the WG punts on security, the security area directorate will punt the document back to the WG. And say "fix it". This isn't about invalidating current implementations. It's about telling people that *new* implementations, or new *releases*, 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
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
On Jul 9, 2018, at 4:54 PM, Joe Clarke wrote: > Broadly, given that we want an informational draft that describes the > protocol as it is implemented today, I feel there should be a balance > struck with respect to normative language so that we don't make existing > clients "out of spec." It's an informational draft, so from a bureaucratic point of view, it doesn't really define a standard. That being said, the spec should require that implementations be as secure as possible given the protocol limits. If this means forbidding things that are widely used... well... that's progress. If the spec is as strong as possible, then implementors will still be free to ignore it. Just as they ignore the specs for most other protocols. :( But users of those implementations can ask pointed questions of "Why are you shipping me something that is insecure by design?" Which is a Good Thing. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Action Items on TACACS+ informational draft v 10
> On Jun 28, 2018, at 3:00 PM, Joe Clarke > wrote: > > I would ask that people like Alan (that have been very vocal) make sure > that any points have been addressed and if specific changes require more > thorough explanation. I would prefer that the document approach publication quality before doing significantly more work. Despite many, many, reviews and both editorial and technical feedback, the new text in the document isn't much better than text from 3 years ago. It's still vague, not prescriptive, doesn't use normative text, etc. I've done do a quick 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://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
allow the > administrator to mandate that only these challenge/response options will be > accepted for authentication. > > It is recommended that administrators use this option. Administrators should > allow other options only when unavoidable due to requirements of > identity/password systems. Is there prescriptive text here instead of "it is recommended"? Maybe SHOULD ? > Due to their security implications, the TAC_PLUS_AUTHEN_SENDAUTH and > TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft should not > be used. Maybe "MUST NOT be used" ? > 9.5.4 Authorization Options > > The authorization and accounting features are intended to provide extensible > flexibility. There is a base dictionary defined in this document, but is may > be extended in deployments by using new attribute names. The cost of the > flexibility is that administrators MUST ensure that the attribute and value > pairs shared between the clients and servers have consistent interpretation. > > If a client receives receiving a mandatory authorization attribute that its > implementation does not define, then it should, behave as if it had received > TAC_PLUS_AUTHOR_STATUS_FAIL. > > Require TACACS+ authentication for authorization requests (i.e. > TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). That last sentence seems unfinished. > 9.5.5 The Redirection Mechanism > > The redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW) that was defined in > the original draft is difficult to secure. It is recommended to disable the > feature, and so to avoid its use altogether. It is recommended that clients > treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. Is there prescriptive text here instead of "it is recommended"? Earlier 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 look at the rest of Section 9, and it's similar. As an implementor, this text gives me only vague guidance as to what to do. With less clarity and fewer prescriptions than earlier text. I've said before that the text is philosophical and conversational instead of technical. This style is continuing with new text. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year
On Apr 20, 2018, at 7:26 AM, Andrej Ota <and...@ota.si> wrote: > On the topic of the current authorship acknowledgment: > > We have added the acknowledgment in -08 in section 10 which currently > (revision -10) reads: That's nice, thanks. > I'm providing an explanation here. Please do not take it as an excuse but > rather as what we see to be an honest and certainly not a flattering sequence > of our choices. I hope to save others from repeating our mistakes in future. > > We (the authors) have made a series of decisions immediately preceding -06 > and following -06 which lead to breakdown in communication and generated > significant frustration in others. The ones I'm aware of are: > 1) We used the text you suggested verbatim in -06 without adding an > attribution at the same time. This was a big negligence on our part. We > thought this would show responsiveness by aggregating verbiage of others, but > in this we neglected that any significant addition requires and equally > significant acknowledgment. What I saw was no response by the authors to my message. It doesn't really matter what else is going on, a simple message of "oops, we're sorry" shouldn't take a year to write. As for showing responsiveness, a simple 5-minute email would be best. Ignoring multiple messages for a year demonstrates total unresponsiveness to the issue. > 2) By the time of Scott's mail, we already committed ourselves to do more > research into vulnerabilities to expand on what you already provided and for > that reason we left the mail unanswered at the time. That's not a valid reason for failing to respond to my message. I'm surprised that this would be presented as an excuse, to be honest. As for additional research, you have resources that have been ignored: the working group. Perhaps there could be a *discussion* on the WG mailing list about the security issues? A discussion that many people were requesting? After all, that's what the WG is for. This attitude again shows a closed attitude towards the document. The authors go off in private, do work, and update the document. All without significant WG interaction. The worst part is that it's still clear you don't know *why* WG interaction is important. Many years into the process, and after multiple messages telling you what to do, you still show a lack of awareness about it. > 3) The work proved to be more time consuming than we expected and this was > reflected in barely keeping up with expiration deadlines. There was only -07 > in August and -08, the first version which included 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 been growing as months were passing while we were completely > unresponsive and acknowledgment nowhere to be seen. This was another big > negligence on our part. It comes across like the document is a private document, and that the WG opinions and reviews are completely unimportant. If you can spend time researching things, you can spend time interacting with the WG. Which is the whole purpose of a WG. The IETF doesn't (or shouldn't) rubber-stamp documents written in privacy. Yet that has been the process so far. > 6) In the meantime we neglected to update the WG with information on: > 6.a) What work we were doing. This robbed the WG of the chance to set us on > a better course of action. > 6.b) What were the intermediate results of the work even if not yet > captured in a draft update. > 6.c) Overall progress of the work related to the draft between the sparse > updates. > > Even for this list I do not claim a perfect hindsight. If I missed more > mistakes that we've made along the way, it would be good to repeat what it > was even if it's probably frustrating to repeat what was already said or > written. You were CC'd two days ago on my message saying I was OK with using the text, but wanted attribution. Your response to that message apologized for misunderstanding my intent, that I didn't want the text used. That message could not have been more clear. The charitable conclusion is that my message was simply not read. Which again shows the problem. There have been many promises over the years to "interact more with the WG". It hasn't really happened. I welcome it, if it happens. But you've given me no reason to believe what you say. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year
On Apr 18, 2018, at 2:49 PM, Andrej Ota <and...@ota.si> wrote: > > TACACS+ draft had undergone a number of changes since revision -06 back in > the February 2017 and we, the "collective of authors" have been less than > satisfactory on keeping the WG updated. This is an attempt to start fixing > the problem by going through changes, enumerating them and explaining the > reason for each significant change. That's good. > A year's worth of changes is a round number and -06 was also the version > where we misread Alan's intention and made the mistake of including his text > verbatim. The message I sent yesterday said *explicitly* that including the text verbatim was fine, so long as attribution was given. The message from Scott Bradner to the list last year also said this: https://www.ietf.org/mail-archive/web/opsawg/current/msg04835.html The issue is *not* including the text verbatim. The issue is the failure to acknowledge authorship. I fail to understand how this point has been misunderstood. > I will skip the minor changes that deal with things like > 's/Connect/Connection/' or updates to author's contact details. I will also > be sending the overview over multiple e-mails, each dealing with a specific > section of the draft, so nobody will have to read through a single huge tome > if you only care or wonder about specific parts of the draft. I understand > this is far from ideal, but the damage had been done and this split into > smaller and more manageable chunks should go a long way towards getting > changes reviewed and understood, one by one. That's good. > I do not wish to ignore the metaphorical elephant in the room. However, I > wish to split technical and organizational conversations into their separate > threads to avoid confusing the two. While I'll be describing changes in the > "technical" conversation, I and the rest of the authors will continue > listening and responding to Alan's organizational criticism, past 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 not have been more clear for the past year, and they are *still* being misunderstood. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt
On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > Initially (up to around version 5) we included just a very simple security > section admitting that T+ was insecure and that the second document would > address the issue. This was deemed to be insufficient, and instead the WG > collectively determined that more detail should be added to enumerate some of > the issues, you kindly catalogued some of these, providing a proposed text > which we took to be a genuine suggestion for text for the document. Which it was. The point I've been trying to make for over a year is apparently still unclear. There was no excuse for plagiarizing the text in the first place. Using it verbatim was fine, so long as attribution was given. There was no excuse for ignoring every single email I made to the list asking about this issue. There was no excuse for *continuing* to plagiarize the text for over a year, across four separate revisions of the document. > Subsequently we interpreted your proposal more accurately (as just a > suggestion of the points to cover), and so we made sure that these were > covered, but without verbatim reuse of the text. We hope that we have > covered the thrust of your issues (and others), but without the plagiarism. I have no idea. Because at this point, I'm pretty much done reviewing the document. > 2) Reactivity of the Authors. > > As far as I know, we have responded to most posts regarding the content of > the document, with point-by-point replies, No. See the list archives, especially May 2017. There are multiple people suggesting that you have *not* done this, and that you *should* do this. See line-by-line reviews done by me, which were generally ignored. Despite that, I did *multiple* such reviews, until such time as it became clear that such reviews were entirely unproductive. > but there has been, for various logistic reasons, long delays in submitting > the resulting new documents. Hopefully this has been addresses in last > versions and we will continue with more rapid uploads until process completes > one way or other. The issue isn't rapid uploads. The issue is engagement. It's not productive to ignore the messages on the mailing list for 6 months, and then to issue a new release saying "we fixed stuff". > We have not generally responded to posts regarding procedural matters, and > would leave such discussions to more knowledgeable stewards of the lists > where possible, You haven't responded to posts where I ask about the plagiarism. A simple reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write. > 3) Change Tracking > > The uploads have generally had extensive changes relating to comments (which > should generally have been summarized by previous email responses to > comments). Which I admit did happen sometimes, but not nearly as often as it should have. Again, see mailing list archives from May 2017. I'm not the only person who holds this opinion. I'm just the main one pushing the point. > Because of this, unless the updates have been for specific purposes (such as > the recent update of the security section) then I would leave the changes to > the diff tool which works pretty effectively. The diff tool lets us know what changed in the document. It doesn't let us know if those changes addressed issues raise on the mailing list. To summarize: * we have 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-10.txt
nteract with the WG. And, to respond to WG reviews and comments. See the many comments in the OPSAWG archives in May 2017 for broad WG support of this position. As the authors have largely ignored the WG comments, the chairs and ADs should have taken steps to address this issue. As of this writing, it appears to be the same "status quo" of the past few years. I don't think these comments are unreasonable. If we truly don't care about the WG opinion, then the chairs and AD can: * make a public statement saying that WG feedback can be ignored * state that that the document can be published in whatever form the authors choose * publish the document even if it does not describe the protocol in sufficient detail to create inter-operable implementations. I don't think that's the right approach, of course. But it's largely what's been happening due to silence and/or inaction of the parties involved. I see no point in further reviewing the document. I again oppose publication of this document until such time as all of the WG issues have been addressed. If we do actually care about what's in the document, then I suggest finally the following steps be taken to address the ongoing concerns: * the document should not be published until such time as multiple implementors have agreed that the specification matches their implementation. * the chairs and ADs should insist that the authors address the outstanding WG concerns about this document * the chairs and ADs should insist that authors follow established practice of *interacting* with the WG, including responding to future reviews and comments. * the chairs and ADs should insist that new revisions of the document are accompanied by an explanation of what changed, and why * that if the authors do not follow these steps (as they have not so far), that the chairs and ADs should replace 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
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-08.txt
> On Mar 19, 2018, at 3:37 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > > Apologies for delay Alan, I have goofed with mail forwarding. > > We still have some work to do on the security section. I will check to see > which items we missed outside the security section, as I thought we had them > all covered. The point is to *engage* with the working group. Simply throwing a new draft "over the wall" periodically does not inspire confidence. On top of that, the Security Considerations still contains substantial amounts of my text, 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, feedback, or updates. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-08.txt
A quick review shows that many of my comments have been addressed, thanks. This significantly clarifies the document. Some comments are still unaddressed. And, the Security Considerations section contains substantial portions of my text as I pointed out earlier, with no acknowledgement that this is the case. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII
On Sep 16, 2017, at 11:41 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > > We¹re preparing the next revision. Regarding attribute value encoding, > we¹re proposing to add the following, then to assign a type to each > attribute. As always with T+, the issue is getting the right balance in > adding some order without changing too much the draft spec. The right balance is to document the protocol. If documenting the spec means tossing the draft and starting from scratch, then so be it. > Proposed content is as below, please share any views: It 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 mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
nt that "this exists, but we have no idea what it is, what it does, and we don't recommend that people use it". Leaving portions of the protocol entirely undefined and implementation-defined is bad. In RADIUS, I've authored or co-authored about 4 RFCs fixing things which were missed or undefined, and which cause interoperability issues. And I'm still finding things which are broken in the specs. Two in the last month, in fact... If TACACS is to be a standard, it should be clear what portions are well defined, and what portions are "I dunno...". That gives guidance for future drafts as to what works, and what needs fixing. >>> * how often do the updates get sent? Saying "implementation defined" is >>> OK, but some recommendations would be good. i.e. not more than 100x per >>> second, and not less than 1 day apart (as extreme examples) >>> [so lets stick with implementation defined, the range of 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 >> RECOMMENDED". >> >> The goal is to guide implementors to choosing values which won't cause >> problems for everyone else. > > Sure, will recommend minimum of 5 seconds, but I¹m not sure we can specify > an upper limit as it is not mandatory. It's always good to recommend best practices, even if the behaviour isn't mandatory. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
er. Saying "treat it like an ERROR" condition" is OK. Also "implementations may fail-over to implementation-defined backup methods". It's bad to have the draft be silent on the topic. > * nit: what's a "dialstring" ? > > * what's a callback? How does that work? > [These two are rather legacy, and really related to an old form of Network > Access, so propose we can exclude] Sounds good. > * how big is the task_id? Since values can be omitted, is it OK to have a > zero-length task_id? or 1 octet? > > * are 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 can clearly > encode a number), but it is widely enough used that I think restricting its > validity would be difficult.] It's fine to say that task_id SHOULD be in all packets. > > * which attributes are allowed in which packets? I presume it's not > recommended to have a START which contains "stop_time" > [other than task_id, there are no accepted standards for this mapping] The draft should say so, then. >bytes_in > >The number of input bytes transferred by this action > > * input to where? This was poorly specified in RADIUS, and some > implementations got it wrong... > [Proposed text: The number of input bytes transferred by this action to the > port] from the users system to the port... Pedanticism helps here. :( We weren't pedantic in RADIUS, and multiple implementors screwed it up. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
On May 16, 2017, at 11:35 AM, Ignas Bagdonas <ibagdona.i...@gmail.com> wrote: > >>I don't see how reviews (which were ignored) can be construed as "no >> evidence" that the authors were ignoring reviews. >> >> Which was my point. If document authors issue new revs irrespective of >> what the WG suggests, the chairs should replace the authors with ones who >> work towards WG consensus. > > No-one has seen the -07 revision yet, therefore it seems to be too early to > make judgement whether comments and suggestions were or were not addressed. > Authors have promised to address the raised comments discussing them on the > list and responding to previous reviews. My comments (again) were that there was a history of ignoring the reviews. At the time I made that comment, it was true. I find it troubling to see a response saying there's "no evidence" of such a problem. >> The alternative is to accept a draft as a WG document, and then to allow >> the authors to do pretty much whatever they want, and then to rubber-stamp >> the final document as an RFC. > > 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
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
On May 14, 2017, at 8:11 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > We will work through this list, and reply with an item-by item response, > (In place of previous mode of updating the doc to make v6) and then > hopefully move towards a consensus for the content for version 7. Thanks. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
On May 15, 2017, at 12:00 PM, Ignas Bagdonas <ibagd...@gmail.com> wrote: > WG chairs can appoint or change authors if needed under the process described > in RFC7221 and its referenced documents. Referencing the rules is nice. Addressing my comments would be nicer. > ... Otherwise unless there is clear evidence that current authors cannot > make progress with the document, My issue isn't "progress". My issue is addressing reviews raised on the list. > WG chairs do not have intentions of changing the author list. This decision > may be revisited if evidence of author/co-author/editor duties not being > performed to the expected level surfaces, but at this time there is no such > evidence. I don't see how reviews (which were ignored) can be construed as "no evidence" that the authors were ignoring reviews. Which was my point. If document authors issue new revs irrespective of what the WG suggests, the chairs should replace the authors with ones who work towards WG consensus. The alternative is to accept a draft as a WG document, and then to allow the authors to do pretty much whatever they want, and then to rubber-stamp the final document as an RFC. > The process of progressing the document is slow, slower than it could have > been, but it is not stalled. I never claimed it was stalled. I claimed that the authors had ignored reviews. I just don't understand what point you were 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
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
On May 13, 2017, at 2:19 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > > So our response to your reviews has been to incorporate, where feasible, > and where we can apply then, to the doc. > > Would you have a preferred method that we responded? I told you my preferred method. Others have agreed that it's the preferred method. If you're reading messages on this list, that question has already been answered. You've been given detailed reviews of the draft. Instead of responding to the reviews, you've issued a new revision. Then, you want the reviewers to verify that the new draft addresses their concerns. That's not the right approach.. The approach in the IETF is to have authors move towards WG consensus. i.e. to prove to to the WG that the draft is ready for publication. If you're not going to work towards WG consensus, 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
Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans
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 provided numerous > proposed textual suggestions,. We would be very happy to acknowledge > Alan¹s contribution to the document by adding wording that is agreeable to > Alan, in the next draft. In fact not having this acknowledgement for > Alan¹s contribution so far was an oversight, for which we apologise to > Alan. Thank you. > However at this time we do not have plans to change the list of authors. I will note that document authors serve at the discretion of the WG / chairs / AD. > Alan: if you feel that we have exploited your suggestions too fully, such > that an acknowledgement in the document would be unsatisfactory > recompense, then we are happy to consider removing all text that you > identify, that you feel is derived too closely from your work. It would generally seem to be better to acknowledge people who have contributed substantially to the draft, instead of removing and re-writing their text. The point of the draft is to have a documented protocol, not to artificially limit the set of authors. > 2) Definition of Done > > We note that there is still comments along the lines that the document is > not ready, in that the protocol is still not adequately described. We > would like to make sure that the next version does adequately describe the > protocol. > > Rather than to chase a cycle of comment/response, we¹d like to see if we > can determine what the ³Definition of Done² checklist and metrics would > be, by which we can measure that the content is be acceptable for the WG > for such a protocol as TACACS+. As I've suggested and others have agreed, what people want is a response to reviews. > For example, as a start point for this, I think we can define: Since drafts proceed to RFC via WG consensus, I would suggest that not responding to reviews is a de facto admission that the draft does not have WG consensus. > 1. The packet formats: defining fields and their constraints > 2. Identification of fields whose values have meaning for protocol flow. > This will include error and fail fields. The way that these fields > influence the flow must be documented. > 3. Identification of the fields which have a common meaning, but are not > intended to direct protocol flow. > 4. Identification of fields whose values have meaning in terms of the > deployment, which would simply be listed. All of these topics and more are addressed in my reviews. > If there are other aspects of the protocol, whose absence would mean that > the protocol is not fully described, we would welcome input to help us. I've given you input, which has largely been ignored. > 3) Next Steps: > > We have two next steps: > > 3.1) We will produce a new revision correcting the issues such as the > email address of Lol Grant and the above mentioned acknowledgement of > Alan, and incorporate lessons from 2) above. > 3.2) We will provide a summary of the changes between the original draft > spec from 1998 and the new draft. i.e. you won't bother to respond to reviews, you want the WG to read the draft again to see if the comments have been addressed. Again, drafts get published based on WG consensus. Ignoring WG consensus is just bad practice, and unproductive. At this point, I'm done. I oppose any and all publication of this draft until such time as the authors can demonstrate that they've addressed concerns raised here. I will continue to respond to Q about my reviews, but I see no benefit in reviewing new versions of the draft. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Serious concerns with draft-ietf-opsawg-tacacs-06
On May 9, 2017, at 2:43 PM, Ignas Bagdonas <ibagdona.i...@gmail.com> wrote:, > > > Based on the information received from authors while tracking the progress of > the draft, they intend to publish a revised version covering the comments > received during the previous WGLC timeframe. I made no statements about my comments and their inclusion in the draft. But since you brought it up, I think the document is still nowhere near ready for publication. Many comments have been addressed, but many have not been addressed. I question the utility of having a WGLC when the draft *still* doesn't adequately describe the protocol. > WG chairs are not for waving a stick at the WG in trying to tell what a > document needs to do to progress. The draft must document the protocol. > While the WG document is formally owned by the WG, it is for the authors to > do the actual text editing work and track and credit the changes in the text. I find it surprising that text was copied without attribution. This just shouldn't happen. > Please initiate a discussion with authors, ideally on the list, on how your > comments were or were not resolved. As the list archive shows, I've done that. It also shows little in the way of responses. The last response to my review was "Many thanks Alan for the thorough review. We¹ll collate all your comments and respond shortly." That was six months ago, and there has been no further response. Given the extensive nature of my reviews, I would suggest it's not *my* responsibility to double-check each rev of the document to see if my comments are addressed. What I've seen in other WGs is that the authors respond to comments with clarifications, suggested replacement text, etc. That pretty much hasn't happened here. > Quite many of past instances of such discussions were happening before, and > they eventually have moved the document forward. Continuing with that > discussion would be the right approach to take. That's what I'm asking for. That's not what's happening. Instead, new revs of the draft come out, with minimal interaction with the WG. > Looking further, there will be a new WG last call coming out after the > revised version is posted. Usual WG LC discussion and commenting procedures > will be followed. 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 to demonstrate that the comments have been addressed. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Serious concerns with draft-ietf-opsawg-tacacs-06
I've taken a look at the latest draft, and have some serious concerns. Specifically, large chunks of the Security Considerations sections appear to have been lifted from my post to the list: https://mailarchive.ietf.org/arch/msg/opsawg/tU2wBFIV4MkpKChWn6EvrqeZtXU There are minor edits, but multiple sentences are copied word for word. Sentences which don't occur in the -05 draft, but do appear in my review, and subsequently are copied to the -06 draft with minor edits. Multiple paragraphs are copied with only minor edits. The total amounts to about a page of text. While I 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/opsawg
Re: [OPSAWG] Start of WGLC for TACACS+ document.
On Oct 6, 2016, at 1:34 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > Regarding the security concern, the approach we have with the current > document is: > > 1) A statement that the protocol does not provide security in a modern > environment. I'm happy with that. > 2) The two common approaches to support T+ so that it may be used. OK... > 3) An indication that a version with built-in security is to follow, which > will not require the mitigations in 2) (actually I suspect it may precede > the info document ;-)) Except that the current document doesn't even document CHAP securely. RFC 1994 (published in 1996) says: Each challenge value SHOULD be unique, since repetition of a challenge value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the challenge SHOULD exhibit global and temporal uniqueness. Tho I'll also note that RFC 1994 also doesn't specify a minimum length for the challenge. That is, the document doesn't even meet the security requirements in place in 1994. > We need to make sure there is no ambiguity for 1) for any security review. > No soft-peddalling. T+ provides the function, not the security. I'm fine with that. I want to document historical TACACS+. This means the document needs to answer the following questions: a) can people implement it? b) can people gain the maximum amount of security available in the historical protocol? c) can people be aware of the security concerns and trade-offs with using the historical protocol? The push-back so far shows that the answers are: a) no b) no c) no I suggest these are the wrong answers. *All* of them are the wrong answers. > My question would be: would this dissection of vulnerabilities and > exploration of the attack vectors would help anyone from a security > perspective, when we have established that the approaches 2) are required? Yes. See any of the RADIUS RFCs in the last 5 years. The SAAG reviews require discussion not only of the issues with the new standards, but also of the problems with the historical protocol. > I suspect that we¹d probably miss some, and that may give implementors > more comfort than is afforded by the clear and simple statement. The argument that we can't be perfect isn't a reason to give up entirely. If the statement is anything other than "no one should use this protocol for anything", we might as well *try* to document security issues. > Therefore, for security review, I¹d suggest we keep the statement simple, > as defined above. However, if this statement is not clear enough/correct > in the document, then certainly, it should be clarified. Then the introduction and/or abstract should say: "This document attempts to specify the historical TACACS+ protocol. However, there are many portions of the protocol which are under-specified or unspecified. We cannot second-guess twenty years of practice here. As a result, this specification is incomplete, under-specified, insecure, and should not 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Start of WGLC for TACACS+ document.
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 comments have been added. -- 3.3. Single Connect Mode The packet header (see below) contains a flag to allow sessions to be multiplexed on a connection. * it would be good to name the flag here. If the server sets this flag in the first reply packet in response to the first packet from a client, this indicates its willingness to support single-connection over the current connection. The server may set this flag even if the client does not set it, but the client is under no obligation to honor it. * what happens if the client does not honour the flag? The flag is only relevant for the first two packets on a connection, to allow the client and server to establish single connection mode. The flag MUST be ignored after these two packets since the single- connect status of a connection, once established, must not be changed. The connection must instead be closed and a new connection opened, if required. Why would it be required to change the mode? It would be good to explain the use-cases, and why (or not) they make sense. TAC_PLUS_UNENCRYPTED_FLAG := 0x01 If this flag is set, then body encryption is not used. If this flag is cleared, the packet is encrypted. Unencrypted packets are intended for testing, and are not recommended for normal use. * it would be good to have a pointer to the security considerations, with a discussion of the implications. * Also, it's odd that a completely insecure mode is just "not recommended for normal use". I would suggest more panic-inducing phrasing. e.g. ."Unencrypted packets offer a complete compromise of all security related to the protocol and MUST NOT be used outside of a testing environment" TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 This flag is ussequernt, ed to allow a client and server to agree whether multiple sessions may be multiplexed onto a single connection. * I find the "agree" phrasing odd. I've mentioned before that the tone of the document is often philosophical. Perhaps saying instead "this flag signals whether the client and server are capable of performing session multiplexing" * i.e. the flag is a signal, not a capability for the systems to agree. session_id The Id for this TACACS+ session. The session id is to be selected randomly. This field does not change for the duration of the TACACS+ session. (If this value is not a cryptographically strong random number, it will compromise the protocol's security, see RFC 1750 * it would be good to update the paragraph to be more prescriptive. i.e. The Id for this TACACS+ session. The session id MUST be taken fro a cryptographically strong random number generation. If not, the protocol's security will be compromised. See RFC 1750 for further information ... length The total length of the packet body (not including the header). This value is in network byte order. Packets are never padded beyond this length. * Why is the text on "padding" there? The TACACS+ packets are sent over TCP, not UDP. So any "padding" would be outside of the scope of the current packet, and be seen by the other end as a subsequent, but invalid, TACACS+ packet. 3.5 ... - Unused fixed length fields SHOULD have values of zero. * what happens when they don't? I suggest adding text saying that the fields are ignored. - There will be no padding in any of the fields or at the end of a packet. * I wonder again what "padding" means here. 3.6. Encryption The body of packets may be encrypted. ... * Which is not a standard encryption method. Security people will complain here. I suggest (as before) using the term "obfuscated". With a note that for historical reasons, the flags / fields / etc. refer to TACACS+ "encryption". ... This document does not discuss the management and storage of those keys. ... * there should be some discussion in the Security Considerations section about this. Otherwise, this subject will be brought up in the security review. ... It is an implementation detail of the server and client, as to whether they will maintain only one key, or a different key for each client or server with which they communicate. For security reasons, the latter options MUST be available, but it is a site dependent decision as to whether the use of separate keys is appropriate. * those sentences seem to disagree with each other. It's an "implementation detail", but it MUST be supported. I suggest requiring the capability of per-server and per-client keys. ... The session id is used in network byte order. * nit: if the session
Re: [OPSAWG] New Version of T+ informational note has been uploaded
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 minimal. It should describe > operational issues with the protocol, and comments as to what the security > implications are for network management traffic to be sent in the clear. For example: Security Considerations This specification describes a protocol as originally designed in 199X, and as such does not use modern security practices. A later document will update TACACS+ to meet modern security standards. There are a number of issues with the protocol design and common use-cases. The most significant are issues related to privacy and authentication. The protocol includes an obfuscation mechanism referred to in the original draft as Body Encryption. This obfuscation method has not had security analysis, and should be assumed to be broken. Portions of the protocol are sent clear-text, while others are sent obfuscated. An attacker may be able to modify the clear-text portions without detection. When the obfuscation mechanism is not used, the protocol is entirely unauthenticated. Anyone capable of spoofing or intercepting traffic for the source or destination of the TCP connection can masqeurade as the client or server without detection. This attack would allow a malicious after unrestricted access to the management devices allegedly "protected" by this protocol. When the obfuscation mechanism is not used, the protocol is also completely open. All traffic is visible to an eavesdropper, which can leak information about the network. An eavesdropper may also be able to intercept, and modify, packets without detection. etc. The section should list the possible attacks, and how to defend against them. Alan DeKok ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version of T+ informational note has been uploaded
On Jul 14, 2016, at 2:30 PM, Douglas Gash (dcmgash) <dcmg...@cisco.com> wrote: > > Hello > For information: > > Version 3 loaded last week has many revisions from the last round of > comments. > Version 4 loaded this week has some minor mods/clarifications on US-ASCII > vs UTF-8. > > Would appreciate any further reviews. Many of my review comments have been addressed, which is good. There still remains a number of issues. 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 minimal. It should describe operational issues with the protocol, and comments as to what the security implications are for network management traffic to be sent in the clear. The issue with the field names remains. I *suspect* the "user len" field contains the length of the "user" field... but there is nothing in the document which says so. The text still seems philosophical to me, instead of prescriptive. For example in Section 3.6: After a packet body is decrypted, the lengths of the component values in the packet should be summed and checked against the cleartext datalength value from the header. Any packets which fail this check should be discarded and an error signalled. The values "should" be summed? Is that an RFC 2119 statement? Or just a suggestion? What happens if an implementation chooses to ignore this suggestion? And bad packets "should" be discarded? Why not MUST? How does an error get signalled? What kind of error packet gets sent back? Perhaps something like this would be better: After a packet body is decrypted, the lengths of the component values in the packet are summed. If the sum is not identical to the cleartext datalength value from the header, the packet MUST be discarded, and an error signalled. The underlying TCP connection SHOULD also be closed. Which (for me) clarifies 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ informational document.
A short summary: - many fields are named but not defined - structures with multiple fields are described, but field order is not defined - terms are used inconsistently - the document is silent on critical points - how do user logins map to TCP connections? 1-1? 1-N? N-M? - can the same session_id be used in multiple TCP connections? - the general tone seems philosophical: systems "know" things, not prescriptive: systems "do" things. - edge cases are not discussed - what happens with zero-length fields? - common use-cases aren't described (e.g. inter-site use of the protocol) - the security considerations section is minimal - how do the edge cases affect security? - is the TCP connection closed when the key is found to be wrong? If not, why not? - what are best practice recommendations for deployment? - what impact does inter-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 present. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ informational document.
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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ informational document.
Perhaps what is meant here is that the data following "length" octets MUST be another valid TACACS+ header. And the corollary (from a security perspective) is that any time the data is *not* a valid TACACS+ header, the TCP connection MUST be dropped. The alternative is to read through streams of random garbage, hoping that perhaps something will decode as a correct TACACS+ packet. Section 3.5; - There should be no padding in any of the fields or at the end of a packet. This is another way of saying that the "length" field isn't lying to you. I'm not opposed to this statement, I'm just wondering why it's necessary. 3.6. Encryption 3.6.1. Body Encryption In general it's bad form to have 2 section headers immediately following one another. I would suggest adding a sentence after the 3.6 header which re-iterates the earlier comments saying "yes, this isn't really encryption, but it was designed 20 years ago, and this is the terminology used in the protocol." ... NOTE: Implementations should take care not to skip decryption simply because an incoming packet indicates that it is not encrypted. If the unencrypted flag is not set, and the packet is not encrypted, it must be dropped. That isn't very clear to me. Double negatives tend to be hard understand. The use of encryption should be an administrative decision, and enforced on the wire. e.g. If the configuration has a shared secret and/or says that encryption is required, then packets received without encryption MUST be dropped, and the TCP connection MUST be closed. Similarly, if the configuration has no shared secret or says that encryption is not used, then packets received with encryption MUST be dropped, and the TCP connection MUST be closed. ...After a packet body is decrypted, the lengths of the component values in the packet should be summed and checked against the cleartext datalength value from the header. Any packets which fail this check should be discarded and an error signalled. And also the TCP connection should be dropped. If the packet is malformed, and the shared secret doesn't match, there is no point in keeping the TCP connection open. The only thing that can be exchanged is garbage data, which isn't useful to anyone. If an error must be declared but the type of the incoming packet cannot be determined, a packet with the identical cleartext header but with a sequence number incremented by one and the length set to zero MUST be returned to indicate an error. And then the TCP connection should be dropped. Section 4.1 It would be good to explain what the various "len" fields mean. It's implied from context, but as a protocol specification, explicit description is preferred to implicit understanding. Similar comments apply for the rest of the packet bodies. The 'len" fields are given in the ASCII diagram, but not further explained or referred to. ... user The username. It is encoded in [UTF-8]. It is optional in 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 note that the maximum "user" name which can be exchanged is 255 octets. Similar text should be added to the other fields. That's it for now. I'll post more later. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?
> 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 largely used *within* the enterprise, the issue of > securing it is less relevant than (say) RADIUS, which is used across the > wider internet. > > This is flat wrong. Tac+ is used across the wide-area, both within a single > routing administrative domain (Autonomous system, single company network) As I said. > and without. That which is asserted without evidence can be dismissed without evidence. I'll note that the existing document doesn't describe this scenario at all. So you're asserting (again) that we should be standardizing TACACS+ because of use-cases which are so important that they're not even mentioned in the document. Or on this mailing list, so far as I've been able to find. I find blind assertions entirely unconvincing. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] leaf device network configuration format (was draft-winter-opsawg-eap-metadata)
On Mar 17, 2016, at 7:49 AM, Stefan Winter <stefan.win...@restena.lu> wrote: > In a nutshell: end users get EAP configuration wrong because it's too > complex, and as a result they are vulnerable to many badnesses out there > in the Wi-Fi world. A common config format would settle all the complex > pieces automatically for them, and make the internet a safer place for them. I'll have a short presentation at the end of RADEXT which addresses this problem directly. And shows how easy it is for bad actors to confuse naive users. I'll post a link to the presentation here 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?
On Feb 22, 2016, at 10:02 AM, Robert Drake <rdr...@direcpath.com> wrote: > That seems like something you need to worry about no matter what the protocol > is or where it originally came from. If a company wants to torpedo the > standards process then they've always got lawyers. It doesn't matter how > silly their claim is, they can tie it up in lawsuits for years. True. > The flip side to this is, if the IETF drags out this fight for too long, I > could see major vendors making their own efforts to secure the protocol prior > to anyone making a standard (possibly because a large customer demands the > protocol be secured for whatever reason). If that happens, we might be stuck > with TACACS+TLS from one vendor that doesn't interoperate with > TACACS+blowfish from another (hopefully all with the ability to fallback to > the defacto standard if needed.. or perhaps we just run 3 separate servers > with different extensions to support multiple vendors..) > > Maybe not. It's been 20 years. It's possible it's just too obscure to worry > about, but we won't know until it happens. I think since TACACS+ has waited 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. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?
On Feb 19, 2016, at 12:40 PM, Eliot Lear <l...@cisco.com> wrote: > My suggestion is that working group consensus (not any particular > individual's or company's point of view) determine what is in a proposed > standard. Operational experience with what is running is going to dictate > what many people believe should and should not be in in that doc. Whether > there is an informational document won't change this. That's a good thing. > If someone said we should rewrite TACACS+ to use EBCDIC encoding, for > instance, I'm pretty sure you'd see a lot of people complain. If the WG > diverges substantially from what is running code, then two documents seem > called for. But I don't see that we've crossed that bridge yet. Adding TLS is a substantial divergence, IMHO. There are no TACACS+ servers I'm aware of which implement TLS. Why not document TACACS+ as a historical protocol, and then "TLS transport for legacy network admin protocols"? If the changes are minor, then the TLS document is minor. If the work to add TLS is not minor, then I think that would fall under the rubric of it "diverges substantially from what is running code, then two documents seem called for." I'd like to just pick one path forward, and be done with it. But the reasons for doing things change, depending on who's answering, and what the question is. To me, this indicates that not only we don't have WG consensus 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
Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?
On Feb 15, 2016, at 3:16 PM, Warren Kumari <war...@kumari.net> wrote: > > This is the third of 3 messages to determine what the OpsAWG should do with > TACACS+. > > If the answer to the previous question is yes, should the RFC describing the > protocol itself (as opposed to any other document that might describe > appropriate use) be published as a standards track RFC? I would say "No". I'll repeat my reasoning here. I support publishing "historical TACACS+" as an informational RFC. That makes it clear the protocol was developed outside of the IETF, and not under IETF change control. Despite external people not differentiating between "informational" and "standards track", the IETF process does make that differentiation. If we are to follow the process, we should follow the process. I believe any discussion of TACACS+ MUST remove all discussion of it as an "AAA protocol". If it's an AAA protocol, then the requirements for AAA protocols should apply. If (as many proponents claim), it's not an AAA protocol, then the requirements for AAA protocols shouldn't apply. But the document then MUST NOT describe itself as an AAA protocol. I support publishing the "future TACACS+" as a standards track RFC. But I think this work should be done outside of OPSAWG. New management protocols are not a "small, highly focused projects that don't merit a WG of their own". They require special adoption processes due to the enormous costs they impose on the industry. If, on the other hand, OPSAWG published a standards track document titled "TLS transport profile for legacy network management protocols", that would fall within the 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 be under IETF change control, and at the same time, 100% historical TACACS+ and nothing more. Alan DeKok. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?
On Feb 15, 2016, at 3:14 PM, Warren Kumari <war...@kumari.net> wrote: > > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG should > do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as one or > more RFCs? I'll say a guarded yes. I have previously explained my preferences for how this work should go forward. I won't repeat them here. I'll also echo t.petch's concerns. There has been no discussion about TACACS+ implementations. i.e. does the draft accurately document the 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 mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
