【每日文稿】2025-01-15
今日共有15篇文稿更新，涉及4个area里的10个WG
ART
emailcore
- Title: Simple Mail Transfer Protocol
- Authors: Dr. John C. Klensin(john-ietf@jck.com)
- Summary: 本文是关于简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)的最新版本。该文档提供了一个标准的电子邮件传输协议，用于在互联网上进行电子邮箱传输。它将以前的文档进行了更新和整合，并删除了历史注释和术语注解。此外，它还提供了对使用SMTP之外的其他协议的情况的概述，以及与安全相关的考虑。最后，它还包含了对于IANA注册表的建议修改。 总的来说，本文是一个详细的文档，总结了最新的SMTP版本，并提供了对其重要性的说明。它保留了一些历史信息，但主要关注于当前的功能实现和改进。
- Diff: 新版本的英文标准文稿（SMTP）是对简单邮件传输协议（SMTP）的基本协议进行了更新和扩展，使其更加符合当前互联网通信环境和技术发展需求。 主要有以下几方面区别： 1. 收集了从RFC 821到最新版本RFC 5321的所有相关文档资料，并对其中的部分历史信息进行了整理和简化，以便更清晰地展示SMTP的发展历程。 2. 提供了关于SMTP的定义、术语等基础知识，以及一些关于使用SMTP传输电子邮件的信息。 3. 深入讨论了SMTP在现代互联网环境中所面临的安全挑战，并提出了相应的解决方案和对策。 4. 对IANA注册表中的某些内容进行了调整和更新，以与当前实践和思想保持一致。 总的来说，新版文档通过整合各个来源信息，提供了一套更为全面、系统且易于理解的SMTP协议规范，为实现可靠高效地传输电子邮件提供了新的思路和指导。
mailmaint
- Title: SMTPUTF8 address syntax
- Authors: Arnt Gulbrandsen(arnt@gulbrandsen.priv.no), Jiankang Yao(yaojk@cnnic.cn)
- Summary: 本文讨论了在支持非ASCII的同时，如何避免让用户和实施者意外使用的元素。为了实现这些目标，作者提出了五条规则： 1. 不允许包含"a-label"(例如"xn--dmi-0na")。 2. 仅使用预览标识符类中的代码点。 3. 一个地址只能由一系列复合字符组成，包括ZWJ和ZWNJ（"c"后面跟着"组合钩"）。 4. 不能包含多个脚本，不考虑ASCII字符的存在。 5. 允许一些代码点来创建难以复制粘贴的部分。 虽然这些规则可能会使用户感到安全，但它们可能需要进一步的研究和测试以确保它们是可接受的。同时，文稿还提到了可能的安全威胁，并指出应警惕其他可能的攻击途径。最后，文稿建议将这些规则作为参考文献的一部分，以便未来可以进行更新或改进。
- Title: Interoperable Email Addresses for SMTPUTF8
- Authors: Arnt Gulbrandsen(arnt@gulbrandsen.priv.no), Jiankang Yao(yaojk@cnnic.cn)
- Summary: 本文提出了一个关于电子邮件地址规范的新标准，旨在避免可能对人类与人之间的交互产生负面影响的元素，并确保兼容性。主要规则包括： 1. 不得包含 a 标签。 2. 如果符合RFC5322语法，则必须匹配WHATWG [TYPE_EMAIL]规范。 3. 地址中的所有字符都必须是预定义的IdentifierClass的一部分。 4. 地址应由一系列复合字符组成（ZWJ和ZWNJ）。 此外，文稿还讨论了当前SMTPUTF8邮箱地址使用的一些限制，并提出了一些推荐的做法来解决这些问题。最后，给出了几个测试案例以展示这些规则的有效性。总体来说，本文的目标是在提供安全的同时保持兼容性和可读性。
regext
- Title: An RDAP Extension for RPKI Registration Data
- Authors: Jasdip Singh(jasdips@arin.net), Andy Newton(andy@hxr.us)
- Summary: 是一份关于资源公钥基础设施(RPKI)注册数据访问协议（RDAP）扩展的文档。文中定义了一个新的RDAP扩展“rpki1”，用于通过RDAP访问互联网数字注册系统(INRS)的注册数据，从而补充现有RPKI诊断工具的信息。主要功能包括：提供对注册信息的直接查询、简化了网络操作员使用RDAP进行故障排查；方便地提供从注册系统数据库以外获得的信息。另外，该文档还引入了IP网络对象和自治系统号码对象的关联搜索路径，以及与之相关的认证信息。 总结来说，《Internet-Draft》为网络运营者提供了便捷的RDAP查询服务，并有助于提升网络故障排除效率，同时也丰富了RDAP的功能性。
- Diff: 新的版本文档定义了一个名为rpki1的新注册数据访问协议（RDAP）扩展，用于通过RDAP访问互联网数字资源系统（INRS）中的资源公共密钥基础设施（RPKI）注册数据。 主要区别： 1. 新文档引入了全新的对象类，包括Route Origin Authorization（ROA）、Autonomous System Provider Authorization（ASPA）和X.509证书资源文件等。 2. 新文档扩展了查询路径段，如rpki1/roa、rpki1/roas、rpki1/aspas等，以更方便地进行搜索和定位。 3. 新文档增加了更多的查询和搜索功能，例如逆向查找、关系与IP网络对象的关系等等。 4. 对于关系到自治系统编号的对象，增加了更多属性，如起始地址、前缀长度等。 总的来说，新的文档提供了更加丰富和全面的功能来支持网络操作者对RPKI注册信息的快速查询和分析。
OPS
anima
- Title: JWS signed Voucher Artifacts for Bootstrapping Protocols
- Authors: Thomas Werner(thomas-werner@siemens.com), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: 本文介绍了在不使用证书的情况下，通过使用JSON Web签名和加密（JOSE）机制来签署凭证数据。这种技术可以与现有的基于CMS（Cryptographic Message Syntax）的验证协议相兼容，并允许用户选择使用哪种类型的凭证格式（如JWT）。此外，它还提供了媒体类型注册，用于识别这些凭证格式。 该技术的安全性和隐私特性没有显著变化，但其认证过程被更改为使用JOSE而不是CMS。主要关注点在于安全性和灵活性方面，例如如何处理不同的验证流程以及如何存储和传输这些凭证。 总的来说，本文扩展了现有协议并提供了一种新的方式来实现零接触零信任策略。
- Diff: 新版本的英文标准文稿提供了两种方式来处理在不支持或不能使用传统密码系统的情况下进行数字签名的情况： 1. 使用JSON Web Token（JWT）技术，它基于JWS协议和JWT标准，可以提供比传统的CMS更安全的方式来对数据进行加密和签名。 2. 通过注册新的媒体类型“application/voucher-jws+json”，允许使用这种JWS-JWT格式的凭证作为凭据。 这使得不同类型的证书能够被合并在一起形成一个完整的签名，从而提高了安全性。此外，这种媒体类型也可以用于识别不同的数字签名格式，方便应用开发者在不同场景下选择合适的签名方式。
- Title: BRSKI with Pledge in Responder Mode (BRSKI-PRM)
- Authors: Steffen Fries(steffen.fries@siemens.com), Thomas Werner(thomas-werner@siemens.com), Eliot Lear(lear@lear.ch), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: 这篇文稿主要讨论了Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) 的解决方案，使其能够在没有或有限的连接的情况下进行远程键基础设施的初始化。它定义了一个新的角色——Registrar-Agent，用于促进BRSKI与Domain Registrar之间的通信。此外，还介绍了新的验证方式和交换对象来支持这种环境。这篇文稿总结了目标环境、使用案例以及可能遇到的一些限制。同时，也指出了在现有技术框架下实现这些要求的方法。总的来说，这篇文稿提供了一种新的解决方案来满足在受限环境下实施BRSKI的需求。
- Diff: 该文档定义了增强后的BRSKI（Bootstrapping a Remote Secure Key Infrastructure）协议，以支持在没有或仅有限连接到客户域登记处的承诺和域登记处之间的远程零接触式设备认证和证书授予。与原始BRSKI方案不同的是，BRSKI-PRM引入了新的组件——注册代理（Registrar-Agent），它充当登记处的角色来触发承诺生成Voucher和Enrollment请求，并将这些请求传递给登记处。此外，还定义了一个新的声明类型——proximity，用于区分MASA向承诺发出的验证声明。 解决方案架构包括以下关键部分： 1. 新增了端点（endpoint）概念，允许从域名登记处和服务器发起者到承诺之间的数据交换。 2. 增加了对两种不同的通信技术的支持：BTLE和NFC，使得承诺可以使用非TLS连接与登记处进行交互。 3. 为确保跨传输层安全性和安全性栈挑战提供了基于身份验证的数据源认证POI（Proof-of-Identity）和证明拥有私钥的存在性POP（Proof-of-Possession）。这两种机制独立于选择的运输方式。 这些变化使BRSKI-PRM能够更好地满足客户在特定环境中的需求，同时保持现有系统的可移植性和扩展性。
RTG
bfd
- Title: BFD Encapsulated in Large Packets
- Authors: Jeffrey Haas(jhaas@pfrc.org), Albert Fu(afu14@bloomberg.net)
- Summary: （J. Haas）等著的《使用大包封装的双向前向检测（BFD）协议》一文，提出了在多跳BFD（IPv4和IPv6单跳）链路上通过增加BFD控制包大小来验证路径MTU的机制。文中详细介绍了该机制的工作原理、实现方法以及相关的安全性考虑。 文稿首先介绍了BFD的基本概念及其在多跳链路中的应用。然后阐述了BFD支持BFD包大包的目的，并说明了如何通过修改BFD包大小来提高验证效果。 接下来讨论了实现这一功能时可能遇到的问题，包括BFD客户端之间的配置差异和负载均衡技术对测试的影响。最后指出，为了更好地测试多个端点的连接情况，需要在所有参与方之间统一设置合适的包大小参数。 总之，《使用大包封装的双向前向检测（BFD）协议》提出了一种基于BFD的大包封装机制，旨在提高验证效率并减少系统间不一致性的影响。
- Diff: 该文档是关于使用大包封装进行双向前向检测（BFD）的一个新的建议。主要内容有： 1. 增加了一个名为“padding”的变量，用于配置BFD在大包中的大小。 2. 提供了对多个BFD会话类型（单跳、多跳、LAG和MPLS）的支持，这些会话类型可以使用不同的大包大小参数。 3. 提供了统一管理的组块“bfd-large-common”，它允许客户机通过客户端参数配置来均匀地支持此功能。 4. 定义了一个包含所有数据节点的命名空间，并提供了一些敏感或脆弱的数据节点。 5. 定义了两个安全考虑：数据节点敏感性及读写操作限制。 6. 定义了一个注册表，在其中提供了两个URI：一个用于IETF XML子域的URI，另一个用于YANG模块名称子域。 与旧版不同的是，增加了对多跳和MPLS等其他形式BFD的扩展。同时，新增了bfd-large-common这一通用组件，使得客户端能够一致地应用这个特性。此外，还定义了对可读数据节点的访问控制，以及一些敏感且可能受到攻击的安全措施。
idr
- Title: BGP Extension for 5G Edge Service Metadata
- Authors: Linda Dunbar(dunbar.ll@gmail.com), Kausik Majumdar(kausik.majumdar@oracle.com), Cheng Li(c.l@huawei.com), Gyan Mishra(gyan.s.mishra@verizon.com), Zongpeng Du(duzongpeng@foxmail.com)
- Summary: 该文档描述了一个新的Metadata Path Attribute在边缘路由器上广播以影响进网节点的行为。这个特性允许边缘服务提供商（ESPs）将特定边缘站点的服务能力信息、状态和资源信息等指标通告给进网路由器，以便这些路由器可以根据服务质量来选择最佳路径。它还可以扩展到包括GPU可用性、功率或其他计算密集型服务的相关信息。 文档详细介绍了如何利用这个特性改善边缘服务的延迟性能，并强调了其适用于低延时服务而非一般互联网服务的情况。同时，也讨论了如何通过本地政策来决定是否使用这个特性以及如何处理降级的指标。最后，还提供了实现过程的一些示例，如如何根据权重综合考虑传统BGP属性与边缘服务指标。
- Diff: 这个新版本的文档主要描述了在BGP协议中添加一个新的路径属性——边缘服务元数据路径属性（Metadata Path Attribute），用于标识边缘服务所在的站点、边路由器以及它们的运行环境。这一扩展可以为低延迟边缘服务提供更优的路由选择。 相比旧版本，主要区别在于： 1. 新版本增加了更多关于元数据的信息，包括站点偏好指数子路径、物理可用性索引等，使信息传递更加全面。 2. 元数据处理能力可以在BGPOPEN消息中指定，使得支持者能够更好地管理元数据。 3. 修改和删除元数据的能力得到了限制，以防止潜在的路由环路问题。 4. 采用了统一的方法来处理不同AF/SAFI类型的元数据，确保所有参与者都有一致的理解。 总的来说，该扩展增强了5G边缘服务的路由选择策略，提供了更多元化的数据资源，提高了网络性能和用户体验。
- Title: BGP UPDATE for SD-WAN Edge Discovery
- Authors: Linda Dunbar(dunbar.ll@gmail.com), Susan Hares(skh@ndzh.com), Kausik Majumdar(kausikm.ietf@gmail.com), Robert Raszuk(robert@raszuk.net), Venkit Kasiviswanathan(venkit@arista.com)
- Summary: 本文主要讨论了BGP协议在软件定义广域网（SD-WAN）中的应用，特别是其在提供可靠连接和信息传递方面的功能。文稿指出，BGP协议可以用于实现安全的虚拟私有网络（VPN），并提供了新的封装属性来支持这些隧道。此外，它还介绍了如何使用BGP传递关于SD-WAN网络的信息，例如边缘节点的授权、属性以及SD-WAN网络下层信息。 文稿强调，BGP是SD-WAN网络管理的关键组成部分，并且需要与边缘控制器建立安全连接。同时，该文档详细描述了BGP支持的功能，包括传递客户路由、端口属性以及通过BGP转发的信息。文稿指出，BGP协议在SD-WAN网络中的应用为构建可靠的连接和信息交换提供了基础。
- Diff: 该文档主要描述了BGP（边界网关协议）在软件定义广域网络（Software Defined Wide Area Network，SD-WAN）中的使用方式，用于支持加密、混合隧道以及虚拟化等特性。它还提供了两种不同的拓扑结构：SD-WAN安全隧道和SD-WAN安全链接，并详细介绍了这两种拓扑的具体实现方法。 相较于旧版本，新的文档引入了一些关键点： 1. 描述了新的BGP隧道类型和子标签（Tunnel-Encapsulation Attribute [RFC9012]），并为SD-WAN边缘节点提供了一个新的封装属性来支持这些隧道。 2. 提供了新的多播路径可达信息（Multi-Protocol Network Layer Reachability Information，MP-NLRI）作为SD-WAN隧道更新的NLRI。 3. 增加了对IPSec安全协会（IPSec Security Association，IPsec-SA）属性的处理，包括重新命名的IPSec SA标识（IPsec-SA-ID）、重试计数器（IPsec SA Rekey Counter）和公钥（IPsec Public Key）。 4. 引入了一种简化版的IPsec SA属性子标签，以便更简洁地传递IPSEC SA信息。 5. 模块化的BGP SD-WAN边缘发现机制，可以单独处理不同类型的SD-WAN边缘发现需求。 总的来说，新的文档增加了对SD-WAN边缘节点的功能描述，扩展了SD-WAN的安全性和可管理性，同时也改进了错误处理机制。
lisp
- Title: LISP Geo-Coordinate Use-Cases
- Authors: Dino Farinacci(farinacci@gmail.com)
- Summary: 本文主要讨论了LISP架构和协议中的地理坐标使用场景。它提出了一个新的LCAF编码格式，用于表示地理坐标信息。这种新格式与已有的其他路由协议（如OSPF、IS-IS和BGP）兼容，并且可以用于EID记录和RLOC记录中。文稿还提到了一些相关的应用场景和考虑因素。 总的来说，本文提出了一种新的LCAF编码格式，用于表示地理坐标信息，以满足LISP架构和协议的需求。同时，也讨论了一些安全性、隐私性和IANA注册的问题。
- Diff: 本文档提供了关于地理坐标在LISP架构和协议中的使用方法。主要内容包括： 1. 提出了新的LCAF编码格式用于表示地理坐标，与之前使用的GPS等路由协议中的编码格式兼容。 2. 对旧版文档进行了更新，例如将Geo-Location类型的描述从5修改为17，并更新了相关引用信息。 3. 增加了一些相关的定义、应用场景、安全性考虑等内容。 总的来说，新版文档更加规范和统一，能够更好地支持地理坐标的应用场景，同时也保留了原有功能的兼容性。
SEC
ace
- Title: Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
- Authors: Marco Tiloca(marco.tiloca@ri.se), John Preuß Mattsson(john.mattsson@gmail.com)
- Summary: 本文主要更新了DTLS协议中的RPK模式和证书模式，使得认证和授权机制能够支持更多格式的公钥。特别是引入了新的认证模式“证书模式”，允许使用X.509或C509类型的公钥作为认证凭据。此外，还对RPK模式进行了扩展，使其能同时支持COSE Key对象和CS的组合。 总结来说，本文扩展了DTLS协议的认证方式，为不同场景提供了更多的选择，有助于提高系统的安全性。
acme
- Title: Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names
- Authors: Q Misell(q@as207960.net)
- Summary: 本文主要讨论了如何使用自动证书管理环境（ACME）来为隐藏服务（".onion" 特殊用途域名）颁发证书。它定义了一种新的验证方法，名为 "onion-csr-01"，用于在ACME中发行野蛮证书。此外，还详细介绍了ACME服务器如何处理CAA记录，以及如何防止未授权CA对隐藏服务进行认证。 总的来说，本文提供了关于如何利用ACME和".onion"特殊用途域名的新见解，并提出了一个新挑战和解决办法来满足这一需求。
- Diff: 本文档的主要区别在于引入了新的ACME挑战“onion-csr-01”，该挑战允许使用特殊域名的证书进行自动颁发，同时定义了一个在ACME服务器与隐藏服务之间交互的新方法。另外，ACME认证过程中的安全性问题得到了加强，包括对DNS标识符验证方法进行了更新和扩展，以及提出了一个在ACME服务器与隐藏服务之间的安全机制。 此外，文档还增加了对ACME与隐藏服务之间的通信的支持，并详细描述了如何实现这种通信。同时，它还包括了一部分关于在不同隐藏服务间传递证书信息的安全措施，以确保这些服务能够有效利用ACME技术来获取证书。 总的来说，这个新版本的文档不仅提供了更详细的ACME与隐藏服务交互方式，而且也提供了更多的信息安全保护和改进措施，有助于提高隐藏服务的安全性。
oauth
- Title: JSON Web Token Best Current Practices
- Authors: Yaron Sheffer(yaronf.ietf@gmail.com), Dick Hardt(dick.hardt@gmail.com), Michael B. Jones(michael_b_jones@hotmail.com)
- Summary: 这篇文档主要讨论了关于如何使用JSON Web Tokens（JWT）来增强安全性的最佳实践。它提出了一些具体的建议，包括进行算法验证、选择适当的加密和签名算法、确保所有密钥有足够的熵、避免压缩数据等。同时，它也指出了可能存在的威胁，如弱签名、多样的JSON编码、密码存储等问题，并提出了相应的解决措施。 总的来说，该文档强调了在实施和部署JWT时应遵循的最佳实践，以提高其安全性。通过这些最佳实践，可以有效地防止各种攻击，例如弱签名、密码破解、跨域混淆等。
Unknown
Unknown
- Title: RADIUS attributes for National Security and Emergency Preparedness Service
- Authors: Sri Gundavelli(sgundave@cisco.com), Subir Das(sdas@peratonlabs.com), Mark Grayson(mgrayson@cisco.com), Martin Dolly(mdolly@att.com), An Nguyen(an.p.nguyen@cisa.dhs.gov)
- Summary: 本文提出了一种新的标准来支持国家安全紧急准备服务(NS/EP)通信。该服务允许优先访问无线网络资源以应对拥堵情况，如紧急服务（ES）。新标准定义了用于支持这些服务的RSVP协议扩展。在新的协议中，一个NAS将能够指示其是否支持EPCS功能，并通过发送一个特定的EPCS能力指示来表明其支持。 文稿还描述了如何使用现有协议来支持优先服务，包括EPC、EPC用户和无线接入点等实体之间的交互。此外，还讨论了安全性方面的考虑以及可能的IANA注册。最后，总结了本篇文稿的主要内容，即提出了新的RSVP协议扩展，定义了支持NS/EP优先服务的方法。
- Title: Trust and security considerations for Structured Email
- Authors: Hans-Jörg Happel(happel@audriga.com), Arnt Gulbrandsen(arnt@gulbrandsen.priv.no)
- Summary: 本文讨论了结构化电子邮件的安全性和信任问题，并提供了处理这些信息的一些建议。结构化邮件增加了消息的语法和语义复杂性，可能导致对垃圾邮件过滤器的误判。此外，使用正式的数据表示可能会引入不一致，例如不同格式的文本、图像等可能被误解为不同的实体。对于自动化处理来说，它也包括跟踪用户与消息的交互。最后，社会工程学攻击的可能性增加，使得受信任的消息更容易受到欺骗。总的来说，结构化邮件需要更严格的审查机制来确保安全和隐私。 总结：本文主要讨论了结构化电子邮件在安全性方面的挑战，提出了限制发送者信任级别的措施以保护用户的隐私。此外，还讨论了如何更好地处理包含结构化数据的消息，如防止非正式的数据展示和避免过度自动化的处理。最后，指出了实现这些要求时应注意的问题，并提出了一些建议来提高结构化电子邮件的安全性和隐私性。
- Diff: 新的版本讨论了电子邮件中的结构化数据及其信任和安全问题，并提供了处理策略建议。相较于旧版本，《Structured Email: Trust and Security Considerations》增加了以下特点： 1. 简洁明了地定义了结构化的邮件概念。 2. 提出了不同类型的网络威胁（如垃圾邮件过滤器、正式的数据显示、自动处理等）可能对结构化邮件产生影响。 3. 描述了不同信任机制的使用情况，包括受信发送者、签名、域签名以及交易标识符等。 4. 讨论了结构化邮件在Roundcube Webmail插件中的应用情况。 总的来说，新版更加详细地探讨了结构化邮件的安全性和信任问题，为实现结构化邮件提供了一套更全面的指南。