今日共有28篇文稿更新，涉及7个area里的21个WG

ART

dmarc

1. draft-ietf-dmarc-dmarcbis-38

  • Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  • Authors: Todd Herr(todd@someguyinva.com), John R. Levine(ietf@johnlevine.com)
  • Summary: 本文主要介绍了域邮件认证、报告和合规性（DMARC）协议，包括其高阶目标、抗钓鱼等。DMARC允许域名持有者（Domain Owner）和公共后缀运营者（Public Suffix Operator, PSD）验证其电子邮件认证部署，并指示它们在验证失败消息中使用的处理偏好。它还支持向报告消费者发送定期的聚合和失败报告，用于识别使用其域名发送欺诈邮件的来源。 此外，文稿讨论了DMARC如何防止未经授权使用域名作者域，以及如何限制因违反DMARC机制而被拒绝的邮件数量。它还提供了关于如何配置DNS树以发现DMARC政策记录的信息。 总之，DMARC是一种旨在增强安全性和减少垃圾邮件的协议，通过使用DNS来实现这一目标，同时确保与现有电子邮件基础设施的良好兼容性。
  • Diff: 此文档概述了域基于邮件认证、报告和一致性的(Domain-based Message Authentication, Reporting, and Conformance, DMARC)协议，旨在解决当前SMTP电子邮件系统中的问题，例如防止冒充行为，以及处理因发送方未验证使用特定域名的授权而导致的问题。它还描述了如何在DNS记录中发布信息以进行验证，并规定了不同的执行状态来确保组织内的一致性。与之前的RFC 7489相比，这一新版本增加了对不同情况（如不被验证或失败验证的消息）的支持，并引入了新的技术元素。此外，它还包括了一些改进的术语定义和一些新的内容，例如聚合反馈的例子等。总的来说，该文档是对之前工作的扩展和完善，为实施和维护安全且一致的邮件流提供了指南。

jmap

1. draft-ietf-jmap-webpush-vapid-09

  • Title: Use of VAPID in JMAP WebPush
  • Authors: Daniel Gultsch(daniel@gultsch.de)
  • Summary: 本文提出了一种在JMAP协议中使用VAPID（Voluntary Application Server Identification）来认证WebPush通知的方法。本文定义了如何通过JMAP服务器广告其支持使用VAPID的身份验证方法，以便客户端可以获取新的推送服务端点所需的VAPID公钥。 为了发现JMAP服务器是否支持VAPID，需要查看标准JMAP会话对象中的“urn:ietf:params:jmap:webpush-vapid”属性。当发布推送消息时，服务器必须使用协议中描述的JWT来验证POST请求，并使用与先前发布的VAPID密钥匹配的应用服务器公钥进行签名。如果发现VAPID密钥已更改，则应更新会话状态并重建推订阅以重新创建或删除旧VAPID密钥支持的推送订阅。同时，要确保同步期间避免因缺少同步而导致的安全问题。
  • Diff: 该文档定义了JMAP服务器如何通过VAPID协议发布其支持使用WebPush通知的能力的方法。在客户端需要验证推送消息时，应用服务器必须使用JMAP规范中指定的应用服务器密钥（以X9.62算法和base64url编码方式表示）。此外，当更新应用服务器密钥后，可以继续发送推送通知给已存在的订阅，但需要确保使用的密钥与之前的密钥匹配。最后，如果出现同步问题，客户端应负责检测并解决任何潜在的不一致情况。该特性仅用于提供关于服务器对VAPID支持的信息，并没有引入新的安全或隐私风险。

regext

1. draft-ietf-regext-epp-ttl-18

  • Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values
  • Authors: Gavin Brown(gavin.brown@icann.org)
  • Summary: 这篇文稿主要讨论了在EPP协议中添加一个扩展，允许客户改变域名和主机对象中的时间戳（TTL）值。该扩展定义了一个名为ttl:ttl的元素来管理TTL值，并提供了相应的命令映射、服务器处理规则以及相关的安全考虑。文稿还提出了一些关于如何使用这个扩展来改善操作性能和安全性的问题。 此外，文稿提到了一些可能被修改的参数值范围以应对操作需求或安全问题，但没有详细介绍具体的修改方法和限制条件。最后，文稿还介绍了这个扩展的注册流程和相关的注意事项，包括对相关命名空间和XML规范的要求等。 总的来说，这篇文稿提供了一种新的方式来管理和控制DNS记录的时间戳值，这对于需要快速完成特定任务的用户来说是一个有用的补充。然而，具体实施时还需要考虑到多个方面的因素，如变更成本、操作稳定性等。
  • Diff: 本文档介绍了Extensible Provisioning Protocol (EPP)的一个扩展，允许EPP客户端管理其分配给域名或主机对象的资源记录（RR）的超时（Time-to-Live, TTL）值。新版本增加了对支持类型的支持，并简化了XML命名空间的使用。此外，它还讨论了如何在处理客户端更改时协调服务器政策的变化。 与旧版相比，主要的区别在于： 1. 增加了对支持类型的限制，确保只有在现有域和主机对象中实际存在的类型才会被接受。 2. 简化了XML命名空间的使用，使其更易于理解。 3. 添加了关于操作影响、何时需要更改服务器策略以及可能的安全考虑的更多详细信息。 总的来说，新版本更注重细节管理和协议实现，使协议更加健壮且灵活。

wimse

1. draft-ietf-wimse-arch-03

  • Title: Workload Identity in a Multi System Environment (WIMSE) Architecture
  • Authors: Joseph A. Salowey(joe@salowey.net), Yaroslav Rosomakho(yrosomakho@zscaler.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net)
  • Summary: 本文主要讨论了工作负载身份在多系统环境中的架构设计和标准化。提出了工作负载身份的概念，包括信任域、工作负载标识符、工作负载标识符凭据等基本组成部分，并探讨了工作负载的身份验证、授权和审计过程。 文中还介绍了工作负载识别系统的几种应用场景，如身份认证、服务授权、授权策略、跨边界工作负载识别等。同时，对安全性考虑进行了详细分析，包括流量拦截、信息泄露以及工作负载安全等方面。 文稿最后给出了IANA考虑的一些参考文献。总体来说，该文旨在为构建一个多系统环境下的工作负载身份提供一种架构框架和标准指南。
  • Diff: 该文档讨论了在多系统环境（Multi-System Environment）架构下设计和标准化工作负载标识符和安全上下文信息协议与负载的方法。它定义了工作负载身份的概念，并探讨了其使用案例、安全性考虑等。 与旧版本的主要区别在于： 1. 确定了工作负载（Workload）概念，指运行特定目的软件实例的工作负载。 2. 引入了工作负载身份概念，即工作负载中的工作负载执行的特定任务。 3. 提出了工作负载身份凭证的概念，用于认证工作负载间通信。 4. 描述了不同方式来表达工作负载身份信息，包括X.509证书和JSON Web Tokens（JWT）。 5. 讨论了跨域工作负载身份、授权和审计问题。 6. 探讨了如何解决威胁，如流量拦截、信息泄露和工作负载被劫持等问题。 7. 对IANA进行了概述性描述。 8. 包含了一些规范性的引用参考文献。 总的来说，该文档提供了关于工作负载身份的更深入理解，并提出了应对多种安全挑战的策略和方法。

INT

6man

1. draft-templin-6man-omni3-26

  • Title: Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces
  • Authors: Fred Templin(fltemplin@acm.org)
  • Summary: 是一篇关于IPv6在多链路网络(Multi-link Network, MultiLink)上的应用标准文档。该文档详细介绍了如何将IPv6协议应用于一个基于多链路网络的架构上，以支持移动节点、固定节点和其它移动节点之间的通信。 文中首先介绍了多链路网络接口模型（OMNI）的概念，包括不同的下层接口类型以及它们之间的关系。接着讨论了OMNI适配层(OAL)的功能，如数据包的封装、分段、重组装等，并对这些功能进行了详细的说明。此外，还提到了一些关键概念和技术细节，比如多路径选择、流量选择策略、端到端路由等。 最后，文稿总结了IPv6在多链路网络中的优势和挑战，指出了未来的研究方向和可能的应用场景，为开发者提供了实用的指南和参考。总的来说，《IPv6 over OMNI Interfaces》是一份非常全面和深入的技术文档，对于理解IPv6在网络边缘的实现具有重要意义。
  • Diff: 上述新版本的英文标准文稿详细介绍了关于多层网络（Multilink Network）接口模型、最大传输单元（Maximum Transmission Unit）、以及如何在多层网络（Multilink）上的网络适配层（Adaptation Layer）进行分包和重组等方面的技术细节。 与旧版相比，新版本的主要区别在于： 1. 增加了关于多层网络（Multilink Network）的概念，如“multilink”、“multinet”、“mobility”等，并定义了它们之间的关系。 2. 提供了一个完整的多层网络接口（OMNI Interface）模型，包括如何将IPv6协议数据包封装成多层网络接口的数据包以及如何从多层网络接口数据包恢复到原始的IPv6数据包。 3. 描述了在多层网络（Multilink）上的网络适配层（Adaptation Layer），包括如何根据需要对数据包进行分包和重组，以及如何维护地址标识信息等。 4. 指出了如何使用IPv6多层网络接口（OMNI Interface）来支持诸如移动服务（Mobility Service）、固定节点通信和多网互联等关键特性。 总的来说，新版文档提供了更全面的信息，有助于理解多层网络接口的工作原理和应用场景。


2. draft-ietf-6man-rfc6724-update-16

  • Title: Prioritizing known-local IPv6 ULAs through address selection policy
  • Authors: Nick Buraglio(buraglio@forwardingplane.net), Tim Chown(tim.chown@jisc.ac.uk), Jeremy Duncan(jduncan@tachyondynamics.com)
  • Summary: 这篇标准文档更新文档，主要更新了RFC 6724中关于优先使用ULAs和GUA地址的相关规定。主要修改包括： 1. 更改默认策略表，将fc00::/7的优先级从30调整到30以上，高于Legacy IPv4。 2. 将2002::/16和Teredo 2002::/16重新定义为相同优先级，以便支持更多场景。 3. 修改Rule 5.5以强制要求所有节点必须在插入手动插入已知本地ULAs，并且具有较高优先级的标识符（14），并低于一般ULAs（13）。 4. 强制手动插入已知本地ULAs到策略表。 5. 对UCLA源与GUA或远程ULA目的地进行讨论，描述如何在这些场景下正确选择通信路径。 总结，本文更新了RFC 6724中的相关配置规则，旨在提升对常见场景的支持性，并辅助移除IPv4在双栈环境下的广泛使用。
  • Diff: 这篇新版本的英文标准文稿对RFC6724进行了多方面的更新和改进，主要包括以下几个方面： 1. 增加了“Known-local”Ula地址的概念，允许节点根据实际情况将特定的ULA地址标记为本地地址，并优先使用。 2. 对默认的policy表进行调整，提高ULA地址的优先级，使其在全局范围内具有更高的优先级。 3. 强调对ULA地址的支持是必须的，即所有节点都必须支持对ULA地址的支持，包括自动插入到政策表中。 4. 提高了对于ULA地址的认知和理解，使得用户能够更准确地识别并选择ULA地址作为通信目的地。 5. 在配置默认的policy表时，增加了对ULA地址自动插入的规范，使得网络管理员可以更容易地管理和控制ULA地址的使用情况。 总的来说，新版本的主要区别在于提高了ULA地址在全局范围内的优先级，强调了其重要性；增加了解决ULA地址问题的方法；以及引入了自动插入ULA地址到policy表中的机制，使得ULA地址的管理更加方便快捷。

OPS

anima

1. draft-ietf-anima-brski-prm-16

  • 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-PRM模式下的远程通信，即承诺充当服务器的角色，并触发请求。 此外，它还定义了用于处理跨协议（如BTLE或NFC）的数据交换的新功能。BRSKI-PRM架构还包括一个名为Join Proxy的独立代理，它可以提供从其他位置的网络连接的替代方案，特别是在移动网络覆盖受限的情况下。为了实现这一点，它需要通过一个由制造商提供的产品序列号列表来发现承诺。此外，它还需要使用一种称为Agent ProximityAssertion的附加声明来验证承诺和代理之间的代理证书。 总之，这篇文档提出了增强后的BRSKI架构，以支持远程安全密钥基础设施的零接触初始化。通过引入新的端点和功能，可以更灵活地进行通信并解决环境限制问题。
  • Diff: 该文档定义了在无或有限网络连接的情况下提升零接触远程密钥基础设施（BRSKI）使用率的新解决方案。相比于之前的英文标准文稿，本版本的主要区别在于： 1. 增加了与域名注册机构（Registrar-Agent）交互的端点，使发起者模式改为响应者模式。 2. 引入了用于识别注册代理的角色，以便追踪承诺安装，并提供对承诺安装的账务责任。 3. 定义了新的认证类型，以区分MASA声明的凭证和证书请求中的凭证。 4. 支持使用非IP协议来交换数据。 5. 提供了启用校验功能的新的证书更新方法，包括证书更新的数字签名。 总的来说，该版本为支持跨协议部署提供了更灵活的选择，同时保持了现有架构的可重用性。

dnsop

1. draft-ietf-dnsop-compact-denial-of-existence-06

  • Title: Compact Denial of Existence in DNSSEC
  • Authors: Shumon Huque(shuque@gmail.com), Christian Elmerot(christian@elmerot.se), Ólafur Guðmundsson(ogud@ogud.com)
  • Summary: 本文主要介绍了在域名解析中使用的一种新机制，称为“(compact denial of existence”,或简称为“Compact Denial”。这种机制允许在线签名服务器生成一个签名的DNS响应，并声称名称存在但没有数据。这样可以减少在线签名的工作量，同时防止了区域内容泄露。 该技术通过在签名记录中声明名称不存在来实现这一目标。此外，它还可以提供一种方法来恢复由于使用Compact Denial而丢失的NXDOMAIN响应代码，以帮助相关工具正确识别非存在的域名称。 总的来说，Compact Denial是一种有效的方法，用于简化DNS响应生成和恢复过程，从而提高了系统的安全性。
  • Diff: 该文档提供了新的定义和实现方法来生成在DNS查询时声称一个名称不存在但没有相关资源记录响应给定类型的答案。相比于之前的技术，这种新的方法可以更有效地减少在线签名的工作量，并且在解析器的应用层不需要进行额外的操作就可以恢复到正常的NXDOMAIN响应。此外，它还支持对域名中包含的非存在名称信号执行响应代码修复。 与旧版本相比，此更新包括了以下主要区别： 1. 新增了一个新的资源记录类型NXNAME用于表示非存在名称。 2. 标识出了如何使用NSEC或NSEC3记录来生成这些回应，以减少在线签名操作的数量。 3. 增加了对NXNAME响应的处理逻辑，即如果请求的是NXNAME，则返回格式错误（FORMERR）并提供关于无效查询类型的扩展DNS错误码。 4. 提供了将NXNAME信号显式地归还为NXDOMAIN响应的机制，允许某些工具自动检测非存在名称。 5. 更新了有关预计算签名模型中的限制以及在线签名技术中可能发生的不利影响的信息。

ippm

1. draft-mzbc-ippm-transit-measurement-option-05

  • Title: The Transit Measurement Option
  • Authors: Tal Mizrahi(tal.mizrahi.phd@gmail.com), Tianran Zhou(zhoutianran@huawei.com), Shahar Belkar(shahar.belkar@huawei.com), Reuven Cohen(reuven.cohen@huawei.com)
  • Summary: 本文提出了一种新的IPv6选项类型，即“通路测量”，它包括一个紧凑的性能相关字段集。这些字段可以用于连续跟踪网络和检测潜在问题，以进一步分析。此外，源节点可以根据需要选择最佳路径，同时使用该选项提供的轻量级信息，如累积延迟和拥堵状态比特，来决定是否使用更精细的测量，例如启用基于延迟和拥堵状态的IOAM（In-Situ Operations, Administration, and Maintenance）选项。通过在源节点之间传播此选项，它可以在不影响数据传输的情况下提供持续的网络性能监控，并有助于故障定位和问题解决。 本文还介绍了这一新选项的IANA注册规范，以及可能的安全考虑。尽管这种选项可能会被滥用，但可以通过正确配置和使用来降低其负面影响。总之，本文提供了关于如何利用通路测量选项进行网络性能监控的一般性指导。
  • Diff: 该文档主要介绍了IPv6选项中的一个新功能——"转输测量"（Transit Measurement）。这个选项包含了一个紧凑的字段集，可以在数据包中嵌入，并且可以被路径上的节点更新，以提供轻量级的测量和监控信息，这些信息是基于常长度的数据，而不是依赖于网络中的跳数。 主要内容包括： 1. 带有要求语言的要求：要求文档中的术语和关键短语在所有大写形式下出现。 2. 新定义的术语：如“OAM”、“ECN”，并给出了相应的定义。 3. 转移测量选项的主要组成部分：Accumulated Delay和Status Bitmap。 4. 两个主要的字段：Accumulated Delay用于测量数据包在路径上的往返延迟；Status Bitmap表示每个节点是否处于拥挤状态。 5. 可以将该选项应用到所有或部分经过源节点转发的流量上。它为每条路径添加了一定的固定开销，其值保持不变。 与之前的版本相比，新版本增加了以下改进点： 1. 提出了新的IPv6 Option类型，即Transit Measurement。 2. 更详细的字段描述，特别是Accumulated Delay和Status Bitmap。 3. 更多的应用场景介绍，例如性能监测、路径选择以及故障定位等。 总的来说，新版本提供了更具体、可操作的信息，旨在简化和提高IPv6网络中的测量和监控效率。

netmod

1. draft-ietf-netmod-yang-semver-18

  • Title: YANG Semantic Versioning
  • Authors: Joe Clarke(jclarke@cisco.com), Robert Wilton(rwilton@cisco.com), Reshad Rahman(reshad@yahoo.com), Balázs Lengyel(balazs.lengyel@ericsson.com), Jason Sterne(jason.sterne@nokia.com), Benoît Claise(benoit@claise.be)
  • Summary: 本文是关于如何在YANG模块和子模块上应用修改过的版本控制规则，以及如何使用YANG Semantic Versioning来标识一个版本。本文更新了之前的RFC文档，并定义了一个新的扩展来标记YANG模块的版本信息。 本文主要介绍了YANG Semantic Versioning的概念、定义及其应用场景；提出了适用于YANG模块和子模块的版本标识方法；明确了YANG Semantic Versioning与YANG版本的不同之处，如支持更灵活的分支机制等；定义了几个相关的术语和概念，例如预发布版本、构建版本等；指出了如何将YANG Semantic Versioning应用于实际开发过程中的各个阶段。 总的来说，本文为YANG标准的发展提供了一种更加灵活且具有可操作性的版本管理方式，有助于提高YANG模块的版本控制效率。
  • Diff: 在本文档中，作者提出了一个新的YANG扩展，它定义了一种基于扩展性版本化规则的YANG文件版本标识符（YANG Semver），以提供更人性化的版本信息给用户，而无需比较其具体代码。 主要区别在于： 1. 新版文档引入了新的YANG版本标识符（YS：Version）来替代传统的SemVer，使得YANG文件的版本可以被标记和更新。 2. 它支持对老版本的更新，并允许使用新版本的修正进行非前向兼容性更改。 3. 对于编辑修改，它定义了一个新的“non_compatible”类型，用于表示编辑级变更，但不影响版本号，这样可以在不破坏版本对比的情况下对版本进行修正。 4. 虽然版本标识符会表明一个非前向兼容性的变化是否发生了，但它不会保证这种变化会真正影响到其他用户的体验。工具如Yang Schema Comparison也可以帮助检测这些变更的影响。 总的来说，新版YANG Semver是针对需要管理和维护YANG文件生命周期的新需求而设计的，提供了更多的人性化版本标识和控制方式。

RTG

bess

1. draft-ietf-bess-bgp-multicast-controller-14

  • Title: Controller-based BGP Multicast Signaling
  • Authors: Zhaohui (Jeffrey) Zhang(zzhang@juniper.net), Robert Raszuk(robert@raszuk.net), Dante Pacella(dante.j.pacella@verizon.com), Arkadiy Gulko(arkadiy.gulko@edwardjones.com)
  • Summary: 本文档详细描述了在控制平面使用BGP来设置多播分组树（通过IP源/目的地址对或mLDP FEC）的方法。这种控制器可以使用复杂的算法和约束来实现流量工程，以及直接向树节点信号动态复制状态，使得控制面非常简单。本文讨论了以下关键点： 1. 控制器可以根据需要设置多播分组树的标识符，包括IP源/目的地地址对或mLDP FEC。 2. 树标识符由一个标签栈表示，而不是树标识符本身。 3. 可以选择将树标识符作为标签栈的一部分，或者不将其包含在内。 4. 确保树节点收到路由后能够安装正确的转发状态。 5. 定义了一个新的NLRI类型，用于标记多播分组树的标识符，包括IP源/目的地地址对或mLDP FEC。 6. 描述了如何发送和接收这些路由，并定义了一些子TLV，如RPF子TLV、备份隧道子TLV等。 总的来说，本文提供了使用BGP替代协议独立多播进行网络配置的方法，从而简化了网络管理流程。
  • Diff: 本文主要讨论了使用BGP作为替代信号来设置和管理多播分发树（MDT）的机制。与传统协议如PIM、MLDP等相比，BGP提供了更加灵活的控制策略，并且在控制器直接向节点发送信号时，简化了多播控制平面。 主要内容包括： 1. 基本概念：介绍了BGP的几种模式，以及它们在MDT中的应用。 2. 路由计算：控制器可以计算多播树并将其信号给各节点，而无需路由选择规则。 3. 标签分配：对于基于标签的MDT，所有路由器共享相同的标签空间。 4. 管理根和叶子：通过BGP更新实现，这些更新可以是动态的或静态的。 5. 安全性考虑：描述了用于保护网络安全的方法。 6. 互联网工程任务组规范引用：列举了一些关键参考文件。 总体来说，这个标准文档提供了一种新的方法，可以在不使用PIM或MLDP的情况下使用BGP来管理多播分发树，为跨域多播树的部署提供了新的视角。

idr

1. draft-uttaro-idr-bgp-oad-05

  • Title: One Administrative Domain using BGP
  • Authors: Jim Uttaro(juttaro@ieee.org), Alvaro Retana(aretana.ietf@gmail.com), Pradosh Mohapatra(pradosh@google.com), Keyur Patel(keyur@arrcus.com), Bin Wen(bin_wen@cable.comcast.com)
  • Summary: 本文主要讨论了使用One Administrative Domain（OAD）作为EBGP连接中的一个新类型，它允许在不同的自治系统之间传播任何属性。OAD的实现需要配置适当的策略来处理与OAD相关的路径属性。另外，文稿还指出了在配置时需要遵循的一些原则，如确保EBGP-OAD的两端都使用相同的会话类型。 总的来说，该文档提供了关于如何在不同自治系统之间的EBGP连接中实现路径共享的详细信息，并定义了一种新的路径分配机制，即OAD。这是通过将EBGP与其他类型的会话相区分来实现的，例如在一些情况下，某些路径属性可能会被忽略或丢弃。 总之，本文提供了一个新的框架，使得EBGP连接可以跨越多个自治系统并支持任何属性的传递，这对于网络设计和管理具有重要意义。
  • Diff: 在总结这部分，我将简要概括和分析新版本的英文标准文稿的主要区别。 1. 新版文档定义了新的外部 BGP（EBGP）会话类型 EBGP-OAD，用于连接位于同一自治系统（AS）中的两个 EBGP 对象，这些对象属于一个或多个行政域（OAD）。新版文档允许 EBGP-OAD 同步传递可选的多边路径属性，而无需强制使用所有属性。这为跨自治系统的多边路径属性交换提供了灵活性。 2. 新版文档明确指出 EBGP-OAD 对象必须支持四字节 AS 号，并且可以指定“支持四字节 AS 号能力”（RFC6793）。 3. 在处理可选路径属性时，新版文档允许 EBGP-OAD 对象接受任意数量的可选路径属性，除非它们被禁止。这意味着 EBGP-OAD 对象可以根据需要选择性地接收或忽略任何属性。 4. EBGP-OAD 对象遵守 EBGP 协议定义的行为规范。此外，根据 RFC8212 规范，不可传递到 EBGP 界面的所有属性（例如 ORIGINATOR_ID 和 CLUSTER_LIST 属性）都应由出口政策明确规定允许，并且应由导入政策明确规定允许。 5. 新版文档规定 EBGP-OAD 对象支持四种八位 AS 号，发布支持四字节 AS 号能力的“能力声明”（RFC6793）。 6. 与旧版文档不同的是，新版文档不强制要求 EBGP-OAD 对象向其他 EBGP 对象发送或接收特定属性。这使得 EBGP-OAD 对象可以在不影响其功能的情况下，灵活处理网络拓扑信息。 7. EBGP-OAD 对象遵循 RFC8212 的行为规范，这意味着它们只允许接收 EBGP 界面上已发布的属性，并严格避免出现错误路由选择等异常情况。 总的来说，新版文档增加了对多边路径属性的支持，允许 EBGP-OAD 对象在不违反基本协议规范的前提下自由处理可选属性。这为企业实现跨自治系统的信息共享和数据流动提供了可能。

lsr

1. draft-ietf-lsr-ospf-admin-tags-24

  • Title: Extensions to OSPF for Advertising Prefix Administrative Tags
  • Authors: Acee Lindem(acee.ietf@gmail.com), Peter Psenak(ppsenak@cisco.com), Yingzhen Qu(yingzhen.ietf@gmail.com)
  • Summary: 文档是关于如何在OSPF协议中使用标签来控制路由和流量的。它描述了如何在不同的路由器之间传递这些标签，以及它们在各种OSPF版本中的用途。此外，还讨论了如何通过管理网络来配置和管理这些标签，并提供了相应的数据模型。 该文档主要分为以下几个部分： 1. 引言：介绍要求语言、需求语义等。 2. 定义标签子Tlv：定义了可以用来标识不同类型的OSPF路由的标签子Tlv。 3. 管理操作：解释了如何通过OSPF路由器发布、传播和修改这些标签。 4. 来自Bgp-LS：说明如何将这些标签用于BGP-LS协议中。 5. 相关参考文献：列出了一些相关的标准和规范。 总的来说，《OSPf Admin Tag》文档提供了一个通用的机制，可以在不牺牲网络性能的前提下，对OSPF协议进行安全和控制性的扩展。它有助于提高网络的安全性和可用性，同时也可以实现更有效的流量管理和路径选择。
  • Diff: 该文档为新的OSPF（Open Shortest Path First）扩展标签（AdminTags）版本，旨在允许路由器在OSPFv2和OSPFv3路由域内使用不同的标签来标识前缀。这种灵活的编码使得多个管理标签可以在所有类型的前缀上发布。 新版本的主要区别在于： 1. 增加了新的标签子类型：Extended Prefix TLV Sub-TLV、E-Inter-Area-Prefix-LSA Sub-TLV、E-Intra-Area-Prefix-LSA Sub-TLV等。 2. 支持更多的应用，如路径选择、优先级选择等，并且可以配置多标签以满足不同需求。 3. 对于特定的应用场景进行了调整，比如不允许向汇总前缀传播管理员标签，以及只对部分区域进行推广或过滤。 总的来说，这一更新增强了OSPF协议的灵活性，使管理员能够更有效地管理和控制路由信息。

SEC

ace

1. draft-ietf-ace-pubsub-profile-11

  • Title: Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)
  • Authors: Francesca Palombini(francesca.palombini@ericsson.com), Cigdem Sengul(cigdem.sengul@gmail.com), Marco Tiloca(marco.tiloca@ri.se)
  • Summary: 本文是关于认证和授权框架在Constrained Application Protocol（CoAP）中的应用，主要关注于使用发布订阅协议实现的组通信。该文定义了一个名为"ACE Pub-Sub Profile"的应用程序脚本，旨在提供一组安全的公私密钥交换，并保护消息传输。 文稿首先概述了本文所涉及的术语、架构和概念，如客户端、资源服务器（RS）、授权服务器（AS）等。然后讨论了如何通过使用CoAP协议以及ACE框架来完成相关的认证、授权和密钥分发操作。 接下来，文稿详细描述了加入一个Pub-Sub安全组的过程，包括发现主题资源、获取访问令牌并上传权限信息等步骤。此外，还提供了授权响应格式和Token转移过程等关键细节。 最后，本文指出了这个应用脚本对其他运输协议及更多Pub-Sub架构的适用性，同时给出了相应的扩展或修改建议。 总之，本文为构建一个基于ACE的组通信解决方案提供了基础结构，特别是对于采用CoAP协议的场景，从而确保了消息传输的安全性和可靠性。
  • Diff: 新的版本定义了一个应用层协议，该协议定义了如何在发布订阅（Pub-Sub）架构中使用授权服务器和密钥分发中心来实现安全的组通信。与旧版本的主要区别在于： 1. 更详细地描述了应用层协议的功能：包括如何获取授权参与某个Pub-Sub主题、如何加入一个公私安全组以及如何处理权限变更等。 2. 对于特定的资源类型进行了扩展：增加了关于访问令牌的信息，并允许客户端通过共享密钥保护通信。 3. 规定了接入和退出过程中的安全性要求，如授权信息和密钥交换的安全性。同时，对一些关键概念进行了说明，如ACE框架、OAuth 2.0等。 4. 在认证、授权和密钥管理方面提供了详细的指导。这些指导使开发者能够构建满足特定需求的应用程序环境。

emu

1. draft-ietf-emu-rfc7170bis-20

  • Title: Tunnel Extensible Authentication Protocol (TEAP) Version 1
  • Authors: Alan DeKok(aland@freeradius.org)
  • Summary: 本文定义了隧道扩展认证协议版本1（TEAP v1），这是一种基于EAP方法的隧道通信方式，用于在安全隧道中执行其他EAP方法。TEAP支持TLS1.2和TLS1.3两种加密协议，并通过使用TLS握手来建立隧道。它允许用户使用TLV格式对象在保护的隧道中传递数据，并且可以通过将TLV对象封装在EAP消息中来实现身份验证。 TEAP版本1定义了版本协商过程、隧道建立阶段以及在隧道内进行的两步交互过程。其中，在隧道建立阶段，双方会协商支持的TLS版本；而在隧道内交互阶段，两个实体会在一个或多个内部方法之间交互。TEAP还支持重试机制以提高系统的可扩展性和稳定性。 文稿总结了TEAP的特性，包括其依赖于TLS的特性，使用TLS作为隧道建立的加密协议；以及TEAP与EAP-TTLS（基于TLS的EAP）的不同之处，后者可以提供更多的控制和安全性。此外，文稿还讨论了TEAP的安全性要求，如密钥交换、完整性保护等，并指出了未来可能需要考虑的问题，如防止中间人攻击和保护传输数据等。
  • Diff: 这篇新的标准文档定义了隧道扩展认证协议（TEAP）版本1，这是一种用于在安全隧道中执行其他认证方法的隧道式扩展认证协议。与之前的版本相比，主要的区别在于： 1. 使用TLS 1.2或更高版本的协议，并且推荐支持特定的TLS加密算法。 2. 提供匿名密钥交换和密钥生成功能的TLS-PSK不再被推荐使用。 3. 使用TLS压缩和TLS扩展来检查服务器证书的有效性。 4. TEAP使用了新的Crypto-Binding TLV来验证连接状态，以确保消息传递的正确性。 5. 对于更复杂的EAP通信场景，如Channel Binding，也有相应的描述。 总的来说，新的TEAP版本在安全性、扩展性和可维护性方面进行了改进。

lamps

1. draft-ietf-lamps-kyber-certificates-07

  • Title: Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
  • Authors: Sean Turner(sean@sn3rd.com), Panos Kampanakis(kpanos@amazon.com), Jake Massimo(jakemas@amazon.com), Bas Westerbaan(bas@westerbaan.name)
  • Summary: 是关于互联网工程任务组(IETF)制定的一种新的密钥封装机制标准，用于加密和认证信息。该标准由美国国家标准与技术研究院(NIST)制定，并将作为下一代量子计算环境下安全性的基准。通过使用这个标准，可以确保关键密钥的安全性，防止恶意攻击者获取到密钥并伪造消息。 在互联网的公钥基础设施(X.509)中，这种密钥封装机制被用于保护身份标识和数据传输的安全性。这种标准定义了如何在证书中正确地表示这些密钥，并且如何在证书扩展部分添加其他属性，以提供额外的信息。同时，它还对如何使用这个标准进行了详细的说明。 总的来说，本文介绍了如何在X.509证书中使用模块化基于密钥封装机制来保护信息安全，并详细解释了相关的算法、格式和安全性考虑等细节。
  • Diff: 上述新版本的英文标准文稿是对的补充说明和更新。 与旧版的主要区别如下： 1. 文档格式：文档使用了新的标题、段落标签等，结构更加清晰规范。 2. 术语定义：新增了一些相关的术语定义，如ML-KEM、ML-KEM-512、ML-KEM-768、ML-KEM-1024等。 3. 安全考虑：增加了针对ML-KEM的安全性考虑，包括对安全级别的定义以及相应的安全性要求。 4. 证书扩展：解释了如何在证书中扩展私钥字段来支持更强的安全性。 5. 参考文献：引用了更多的参考文献以提供更全面的信息来源。 总体来说，新版文稿在保持原有的基本信息和结构的基础上，进行了部分修订和改进，以适应最新版本的需要，并提供了更多详细的技术细节。


2. draft-ietf-lamps-automation-keyusages-02

  • Title: X.509 Certificate Extended Key Usage (EKU) for Automation
  • Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), Dr. David Goltzsche(david.goltzsche@siemens.com)
  • Summary: 本文主要讨论了在工业自动化和铁路领域，如何使用X.509证书中的扩展密钥用途（Extended Key Usage, EKU）来增加安全性。它定义了通用用途、信任锚配置文件签名、软件和固件更新包签名以及安全通信关键用途等的EKU扩展密钥目的，并给出了使用这些目的的具体示例。此外，还强调了要确保正确地将这些EKU扩展密钥目的插入到每个由认证机构签发的证书中。 文中提到，如果一个依赖方知道特定证书用户必须使用这些密钥目的，则需要强制执行它们的包含。此外，应确保证书政策设置为数字签名或非否认验证，以进行签名验证，如果需要密钥加密或密钥协商，则应该选择密钥加密或密钥协商。最后，文稿指出在某些情况下，可能会有跨协议攻击的风险，因此可能需要禁止组合密钥目的的使用。
  • Diff: (draft-ietf-lamps-automation-keyusages-02) 摘要：RFC 5280规范了几个关键用途标识符(KeyPurposeIds)，用于X.509证书。本文档定义了自动化领域和工业自动化系统相关的一些特殊目的标识符(KeyPurposeIds)，如配置文件、信任锚点配置文件、软件更新包和安全通信等，并在X.509 v3公钥证书中使用这些标识来表示认证意图。为了防止交叉协议攻击，可以禁止或允许特定组合的KeyPurposeIds。 正文： 1. 引言：自动化产品连接到互联网并需要CE标志表明其符合法规要求，这些法规旨在提高网络安全，如欧盟的欧洲网络与信息安全管理法案(European Union Cyber Resilience Act)。因此，必须满足对安全属性透明度和互操作性的要求。 2. 概念和定义：此文档为工业自动化领域提供了新的扩展用途标识符(KeyPurposeIds)。这些扩展用途标识符可用于验证各种格式的配置文件签名，验证信任锚点配置文件，以及验证安全通信中的身份验证请求。此外，还定义了ID-KP-安全通信等特定的安全通信用途。 3. X.509证书扩展用途（EKA） 该文档定义了用于工业自动化领域的一些特殊用途标识符，例如用于验证各种格式的配置文件签名的ID-KP-配置签名，用于验证信任锚点配置文件的ID-KP-信任锚点签署，用于验证软件和更新包安全通信的ID-KP-安全通信等。通过将这些特定的安全通信用途整合到X.509 v3公钥证书中，可以加强安全性。 4. 包含扩展用途标识符的证书 [RFC5280] 规定了X.509证书的扩展用途（EKA），即可以在证书中包含多个用途标识符以指示认证的目的。如果多个用途被指示，则应用程序不必识别所有指定的用途。但是，如果单个证书包含了多个用途标识符，那么这个证书只应该用于一个指定的用途。 5. 对于认证权威的影响 证书授权机构(CA)应确保正确地插入每个包含扩展用途标识符的证书，并且这些标识符不应与其他标识符冲突。如果CA未按照规则处理，可能会导致不兼容问题。 6. 安全考虑 本文档概述了如何利用这些扩展用途标识符来增加现有安全风险，从而提供一种方法来确定证书是否生成用于验证签名的配置文件、验证安全更新包还是验证身份验证请求。对于安全通信用途，还包括了用于基于TLS或其他安全协议的身份验证请求的认证功能。 7. 隐私考虑 本文档概述了一些已知的安全协议，如TLS 1.2，其中证书交换是明文形式的；而TLS 1.3则是在加密状态下交换证书。这些扩展用途标识符可以帮助观察者确定证书的确切用途。此外，如果证书由公共证书授权机构颁发，那么这些扩展用途标识符也可以帮助攻击者监视证书透明传输日志来识别证书的确切用途。 8. IANA考虑 本文档指出了在"PKI工业自动化扩展用途模块标识"注册表中注册以下ASN.1模块OID的建议。该OID定义了编号为id-mod-eu-automation-eku的自动化扩展用途模块。 9. 致谢 感谢RFC 9336和RFC 9509模板作者的帮助。感谢所有对该文档进行评审的人员的宝贵反馈。

openpgp

1. draft-ehlen-openpgp-nist-bp-comp-01

  • Title: PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters
  • Authors: Quynh Dang(quynh97@gmail.com), Stephan Ehlen(stephan.ehlen@bsi.bund.de), Johannes Roth(johannes.roth@mtg.de), Falko Strenzke(fstrenzke@cryptosource.de)
  • Summary: 本文定义了基于多算法的复合方案，包括NIST和Brainpool椭圆曲线域参数，支持在OpenPGP协议中使用。本文扩展了之前的[draft-ietf-openpgp-pqc-06]文档，增加了新的加密、签名算法组合以及对应的密钥生成流程。这些算法可以提供比传统方法更强的安全性。
  • Diff: 新的标准化文档定义了基于多重算法的公钥加密和签名方案，用于使用NIST和Brainpool椭圆曲线参数。这个新版本的主要区别在于： 1. 新添加了对NIST和Brainpool椭圆曲线参数的支持。 2. 对现有的OpenPGP协议进行了扩展，定义了更多复合算法组合。 3. 定义了基于ML-KEM和ML-DSA的更广泛的算法组合，包括对NIST和Brainpool椭圆曲线参数的支持。 4. 包括了实验性代码点以进行互操作测试。 总的来说，新的文档比旧版本增加了更多的支持，使不同类型的算法可以组合在一起，从而提供更好的安全性。

scim

1. draft-ietf-scim-device-model-11

  • Title: Device Schema Extensions to the SCIM model
  • Authors: Muhammad Shahzad(mshahza@ncsu.edu), Hassan Iqbal(hassaniqbal931@gmail.com), Eliot Lear(lear@lear.ch)
  • Summary: 本文讨论了SCIM协议在物联网设备管理中的扩展使用。首先，定义了设备、设备组和资源类型（EndpointApp）的概念。然后详细介绍了设备的核心属性和扩展属性，包括通用属性、特定于设备的功能性属性以及扩展特性。最后，指出了如何注册新的SCIM模型和设备扩展，以支持物联网设备管理。本文为SCIM协议在物联网领域的应用提供了基础性的描述和指南。
  • Diff: 摘要：本文对SCIM（系统交叉身份管理）协议和模型进行了扩展，为设备提供支持，允许使用各种底层验证系统，如Wi-Fi Easy Connect、FIDO设备认证凭据、蓝牙配对码和MAC旁路等。 在设备类型上，新增了一个新的资源类型“Device”，包含了核心设备属性以及多种扩展属性。这些扩展属性根据设备的功能特性进行定义，以实现设备认证、授权等功能。 此外，还新增了新的资源类型“EndpointApp”，用于授权客户端控制或接收服务功能。这些扩展属性包括但不限于应用类型、应用名称、客户端令牌等。 总的来说，本文档的主要区别在于增加了对设备的支持，使得SCIM协议能够更全面地处理设备认证与权限问题。同时，也提供了相应的扩展属性来满足不同场景下的需求。

WIT

cdni

1. draft-ietf-cdni-logging-extensions-01

  • Title: CDNI Logging Extensions
  • Authors: Ben Rosenblum(ben@rosenblum.dev), Omar Ramadan(omar@blockcast.net), Kenton Seward(kenton.seward@gmail.com)
  • Summary: 本文是关于对CDNI（内容交付网络接口）的扩展，以支持交易日志在推流和拉流模式下的传输、新记录格式、记录字段、新的日志标记以及用于描述转换、去加密化、去密钥化的日志字段的新标记。这些改进旨在满足未来更多Open Caching系统（OCS）组件的日志需求，并提供一个更详尽的设置流程，以便安全地管理和传输日志数据。 主要要点包括： 1. 介绍：日志生成、保留、账务计算、数据分析与报告、内容保护和隐私保护等方面的重要性。 2. 需求：定义了相关的容器文件格式、日志记录格式、日志标记类型等。 3. 容器文件格式：包含JSON、newline-delimited records等格式。 4. 日志记录字段：包含时间戳、ISO8601时间、事件状态等信息。 5. 日志记录类型：包括标准、扩展、历史等标准。 6. 拉流配置：提供了日志推送的详细配置方法。 7. 分享与存储：指出了如何分享和存储日志数据的方法。 8. 内容保护：为日志数据的安全性做了考虑。
  • Diff: 新的标准文档定义了CDNI（Content Delivery Network Interface）支持交易日志传输的新特性，包括push和pull模式、新日志容器格式和记录格式、新增的日志字段以及日志数据保护等。这些特性使得CDNI能够在推流和拉流模式下提供更完善的日志管理功能。 与旧版标准文稿相比，新版本增加了以下关键改进： 1. 支持使用JSON、newline delimitd records和protobuf进行日志文件存储。 2. 提供了针对日志记录格式的新要求，如时间戳格式、压缩归档、自定义日志类型和日志记录格式等。 3. 在日志记录字段中增加了一些隐私保护措施，如字段长度限制和对私有信息的加密处理。 4. 对日志转换功能进行了扩展，允许在输出字段上应用配置以满足不同地域和服务区域的合规需求。 5. 新增了日志容器文件格式定义，并为自定义日志记录类型提供了定义方法。 总的来说，新的标准文档比旧版更加丰富和完善，能够更好地支持CDNI的运营管理和数据分析，提升CDNI作为CDN服务质量的重要组成部分的作用。


2. draft-ietf-cdni-named-footprints-01

  • Title: Content Delivery Network Interconnection (CDNI) Named Footprints
  • Authors: Alan Arolovitch(alan@2you.io)
  • Summary: 本文主要讨论了CDN之间连接的扩展需求，特别是关于如何通过FCDI接口来支持CDN脚本类型。文稿提出了两种新的脚本类型："expr"和"named"。这两种脚本类型都基于CDN脚本模型扩展，并且可以用于引用其他脚本对象或在不同的脚本层级上使用。此外，还提到了将脚本与服务标识器联系起来以提供更灵活的服务细分的能力。 本文还对CDN功能广告进行了修改，增加了额外的脚本类型，如"named"，并修改了一些已有的脚本类型，例如"expr"和"country"。这些变化旨在提高CDN之间的数据交换效率，并为CDN提供商提供更多的能力选择。
  • Diff: 根据上述新版本的英文标准文稿，主要内容包括： 1. 引言：定义了什么是脚本和不同类型的脚本；目前在FCI中支持的脚本类型。 2. 要求：描述了脚本发布到开放缓存架构中的方式，以及对现有脚本类型进行了扩展。 3. 对比与旧版本：指出了本文档相对于旧版的主要区别在于引入了新的脚本类型、新增了对域名标识符的支持，并提供了更有效的数据源管理机制等。 总的来说，本文档对现有的脚本广告方法进行了改进和扩展，以满足更复杂的需求，同时保留了兼容性，并且提供了一种有效的方法来跟踪和管理脚本资源。

httpbis

1. draft-ietf-httpbis-rfc6265bis-19

  • Title: Cookies: HTTP State Management Mechanism
  • Authors: Steven Bingler(bingler@google.com), Mike West(mkwst@google.com), John Wilander(wilander@apple.com)
  • Summary: 本文定义了HTTP中的Cookie和Set-Cookie头部字段。使用Set-Cookie头部，服务器可以向用户代理发送状态信息（称为cookies），当用户代理在以后的HTTP请求中收到这些cookies时，它们将返回给服务器。 服务器应遵循规范的“安全”设置，以防止未授权访问和数据泄露。如果一个服务器需要为不同来源的状态信息提供相同的服务，则它应该选择Section 4来创建这些cookies，并将它们发送给用户代理。相反，如果一个服务器只希望处理特定来源的状态信息，则它应该选择Section 5来接收这些cookies。 对于任何类型的客户端或服务器，都应该接受某些不安全的行为。例如，服务器不应指示一个cookie是针对“安全”的连接，但这种指示并不提供完整性保护，因为网络攻击者可能活跃。 为了提高兼容性，服务器应在生成cookies时尽量遵循规范的“安全”配置，而用户代理则应基于其cookie策略来更宽泛地处理这些cookies。这样做的目的是减少与现有服务器的差异，使应用程序能与其他服务器协同工作。 然而，由于历史原因，Cookies包含了一系列的不安全性。例如，一个服务器可能会表示一个cookie是为“安全”的连接，但实际上，没有使用完整的网络安全性。同样，共享主机上的所有端口都指向同一站点，即使通常有相同的“同源政策”隔离从不同端口获取内容。 本文还讨论了服务器、客户端、代理和起源等概念，以及如何使用这些概念构建浏览器应用。此外，还讨论了不同类型实施者的职责，即生产者和消费者，以及他们应该采取的最佳实践。最后，该文档描述了IANA对这些字段进行的编号工作，包括Set-Cookie和Cookie属性的注册。 总的来说，本文旨在建立一种协议，使得不同的客户端和服务器能够在互联网上协同工作，共同维护状态管理机制，同时考虑安全性和隐私因素。
  • Diff: 新的文档（draft-ietf-httpbis-rfc6265bis）定义了HTTP Cookie和Set-Cookie头部字段，允许服务器向客户端发送状态信息以维持HTTP协议下的状态会话。在服务器响应中使用Set-Cookie字段，用户代理可以返回Cookie请求头到服务器，服务器从中获取之前接收的Cookie值。同时，服务器可以在任何响应中包括多个Set-Cookie字段，而不影响HTTP缓存存储和重用。 相比于旧版标准文档，主要区别在于： 1. 更严格地规定了Cookie生成时必须遵循的规范。 2. 提供了一个更宽松的处理策略给客户端，使其能够兼容更多类型的服务器。 3. 增加了对安全属性的规范，比如Secure、HttpOnly等，用于保护Cookie数据的安全性。 4. 规定了相同的站点（Same-Site）行为，使得跨站脚本攻击难以通过相同的域名访问不同的站点。 总体而言，这个新版本明确了如何正确使用Cookie，以及如何确保安全性，从而提供了更好的HTTP客户端与服务器之间的通信方式。

quic

1. draft-jholland-quic-multicast-06

  • Title: Multicast Extension for QUIC
  • Authors: Jake Holland(jakeholland.net@gmail.com), Lucas Pardue(lucas@lucaspardue.com), Max Franke(mfranke@inet.tu-berlin.de)
  • Summary: 本文提出了一种用于多播传输的扩展，允许使用相同的数据流在多个单独的QUIC连接之间发送。这个扩展利用了多播IP的潜力，使得数据能够被许多客户端同时接收，而无需担心网络安全、可靠性或实施难度问题。服务器和客户端都可以选择是否加入或多发一个特定的多播通道，以满足各自的性能要求。 本文还定义了一些关键概念，如源到源（SSM）和任何来源（ASM）数据流，以及两个不同类型的多播数据：多播消息（MC）和控制消息（CM）。此外，本文讨论了数据包的加密、完整性保护以及恢复机制等内容。文中还详细介绍了各个概念的具体实现细节。总的来说，本文提供了一个多播传输的扩展框架，旨在充分利用多播IP的优势，同时确保数据的安全性和可靠性的平衡。
  • Diff: 该文档定义了一个扩展到QUIC协议版本1的多播子集，用于在多个单个连接（QUIC）之间发送同一批数据流，以实现多播网络上的大规模可扩展性。以下是与旧版本的主要区别： 1. 定义了新的传输参数，允许客户端和服务器设置限制资源使用上限。 2. 提供流量控制和拥塞控制机制来处理多播流量。 3. 维护QUIC协议对多播数据包的安全性和完整性，满足特定的加密和哈希算法要求。 4. 借助多播IP网络的优势来发送那些被大量客户群消费的数据。 相较于旧版，它改进了以下方面： 1. 在不改变QUIC协议结构的前提下，增加了更多的子集扩展，提供更丰富的功能。 2. 实现了多播数据流的高效利用，减少了每个连接的数据量。 3. 针对安全性、可靠性等方面进行了优化，并提出了相应的策略。 4. 改进了多播通道管理流程，简化了加入和退出过程。

IRTF

cfrg

1. draft-mattsson-cfrg-aes-gcm-sst-15

  • Title: Galois Counter Mode with Strong Secure Tags (GCM-SST)
  • Authors: Matt Campagna(campagna@amazon.com), Alexander Maximov(alexander.maximov@ericsson.com), John Preuß Mattsson(john.mattsson@gmail.com)
  • Summary: 本文定义了Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD)算法，它是在通用接口的基础上定义的。这种模式在不使用任何特定加密标准的情况下可以被用于任何非对称密钥生成器，且其安全性比GCM更好。 GCM-SST引入了一个新的子密钥Q，以及一个与之相关的子密钥H。通过这些额外的子密钥，GCM-SST可以使短标签下有近理想的伪造概率，即使是对多个失败尝试也一样有效。同时，它减少了多次成功的伪造的可能性，从而提高了安全级别。此外，它的性能在软件和硬件上都与GCM相同。 本文还注册了一些使用AES和Rijndael-256进行GCM-SST实例，验证了它们的行为像理想MAC，即每次成功产生的MAC个数等同于短标签下期望的认证长度。相比Poly1305，GCM-SST提供了更好的完整性，而代价是增加了额外的安全性要求。GCM-SST还可以提供良好的保密性，这是因为它能很好地抵抗被动攻击。
  • Diff: 以上新版本的英文标准文稿定义了Galois Counter Mode with Strong Secure Tags (GCM-SST) Authenticated Encryption with Associated Data (AEAD)算法，并与AES和Rijndael-256进行结合。主要区别有： 1. 使用了额外的子密钥Q，用于生成新的子密钥H和Q。 2. 对于每个nonce，通过哈希函数GHASH来计算H和Q，而非使用GCM中的GHASH。 3. 使用了POLYVAL函数从AES-GCM-SIV中定义的GHASH，而不再使用GCM中的GHASH。 4. 可以在多个nonce之间共享相同的子密钥Q，而不是仅限于一个nonce。 5. 针对长标签提供了更好的性能，如不使用过多的加解密操作。 6. 改进了验证机制，确保只有正确的tag长度才会被接受。 7. 重新考虑了安全属性和可扩展性要求。 综上所述，这些变化使得GCM-SST具有更近似理想伪造概率的安全性，并且可以更好地抵抗多次伪造攻击。它适合用于支持Replay保护的单播安全协议，并且可以提供比GCM更少的资源消耗，同时保持其安全性水平。

Unknown

Unknown

1. draft-young-md-query-saml-22

  • Title: SAML Profile for the Metadata Query Protocol
  • Authors: Ian Young(ian@iay.org.uk)
  • Summary: 该文档主要提出了一个用于验证身份管理的SAML（Security Assertion Markup Language）协议，它使用了MDQ（Metadata Query）机制。这个协议支持查询和获取SAML元数据信息，包括实体标识、安全属性和其他相关信息。 MDQ协议具有以下几个关键特点： 1. 使用XML格式表示元数据，满足标准规范。 2. 提供了一种安全的机制来验证元数据完整性，例如通过数字签名确保元数据的正确性。 3. 支持对SAML元数据进行多维度查询和检索，如特定实体的信息或其关系等。 4. 可以处理多种类型的数据结构，满足不同业务场景的需求。 MDQ协议为用户提供了一个灵活的工具，可以方便地获取并验证SAML元数据，从而提高身份认证和授权过程的安全性和效率。
  • Diff: 摘要 这篇文稿为SAML（Security Assertion Markup Language）中的元数据查询协议进行了标准化。 本文的主要贡献在于定义了用于SAML元数据查询的元数据查询协议，并描述了其功能和结构。它还提供了详细的文档结构、请求和响应模式等信息，以及对安全性和互操作性的建议。 相比于之前的版本，新的版本在内容上有以下主要区别： 1. 提供了更详细的文档结构，包括HTTP头部和元数据类型。 2. 更明确地指出了对哈希算法的选择要求，以防止攻击者利用弱哈希算法进行攻击。 3. 强化了第二预图像问题的概念，指出这是SAML协议中的一个特定问题，并引用了相关的攻击案例来支持这一观点。 4. 在文档中添加了更多关于使用SHA-1生成数字签名的详细说明，强调该方法可能引入安全风险，但目前未发现实际攻击实例。 总之，新版本的标准化文稿提供了一个更加详尽的框架，强调了安全性方面的问题，并为实现更可靠的元数据查询协议提供了指导原则。


2. draft-young-md-query-22

  • Title: Metadata Query Protocol
  • Authors: Ian Young(ian@iay.org.uk)
  • Summary: 是关于如何从HTTP协议中检索命名实体或命名集合中的元数据的文档。这个文档定义了一个简单的协议，允许请求者依赖某些严格定义的行为。它旨在使客户端能够根据特定行为执行查询，并确保服务响应效率高。这个文档是在REFEDS工作组过程中产生的。本文主要介绍了该协议的运输、查询协议、高效检索和缓存等内容。其中还提出了几个扩展点，如对特定标识符进行语法扩展，以及对更高层次协议使用情况进行说明。 总结来说，《Metadata Query Protocol》定义了一个简单但强大的协议，用于从HTTP协议中检索命名实体或命名集合的元数据，为网络上的各种应用程序提供了一种标准方式。它强调了标准化、效率和可扩展性，同时保证了安全性和可靠性。
  • Diff: 新的版本在以下几方面有显著区别： 1. 在协议运输部分，明确指出HTTP/1.1是必需的，而以前只是推荐。 2. 修改了HTTP方法为GET，更符合HTTP协议的要求。 3. 增加了对Accept头和Content-Type头的支持，使其更加完善。 4. 改进了响应状态码，比如删除了501状态码，并更新了HTTP版本支持。 5. 删除了对SSL的支持，更符合当前的安全要求。 6. 对协议扩展点进行了定义，以方便未来添加更多功能。 总的来说，新版文档更严谨、规范，同时增加了对最新协议的遵循，对后续维护和使用都更为有利。


3. draft-tomas-openroaming-04

  • Title: WBA OpenRoaming Wireless Federation
  • Authors: Bruno Tomas(bruno@wballiance.com), Mark Grayson(mgrayson@cisco.com), Necati Canpolat(necati.canpolat@intel.com), Betty A. Cockrell(bcockrell@singledigits.com), Sri Gundavelli(sgundave@cisco.com)
  • Summary: 本文主要讨论了无线宽带联盟(WBA)OpenRoaming系统。该系统是一种无缝接入体验,旨在为连接到联盟成员访问网络的设备提供统一和安全的Wi-Fi体验。WBA OpenRoaming定义了一个全球性分布式服务架构,支持运营商、IDP之间的互操作性和结算无须支付费用。 OpenRoaming使用mTLS技术来保护交换的信号，其核心是基于无线宽带联盟(PKI)的私有证书授权体系。此外，它还支持动态发现机制，允许通过DNS解析找到权威的radsec端点服务器。这些特性使OpenRoaming能够提供无缝接入体验，并支持不同的价值主张，例如免费Wi-Fi的部署以支持教育和研究社区等场景。 在OpenRoaming的法律框架下，没有直接关系被假设在运营商和IDP之间。为了实现跨运营商间Wi-Fi自助服务的可靠性和安全性，WBA及其成员已发布Wireless Broadband Alliance证书政策文件，用于规定运营者的具体策略和行为。 总的来说，OpenRoaming旨在建立一个公平、安全且可扩展的Wi-Fi自助服务解决方案，满足不同用户的需求。
  • Diff: WBA OpenRoaming是无线宽带联盟（WBA）设计的一个全球Wi-Fi服务网络框架，旨在为用户提供无缝安全的Wi-Fi体验。OpenRoaming架构可以支持接入网和身份提供商之间的无缝连接，并提供透明的身份验证和授权。 主要区别： 1. OpenRoaming提供了基于mTLS的安全解决方案，通过证书在Wireless Broadband Alliance（WBA）私有证书机构（PKI）下进行加密交换。 2. OpenRoaming定义了开放访问组控制（CAC）、闭合接入组政策（CAGP）等机制来满足不同场景的需求，如支付结算、流量优先级等。 3. OpenRoaming使用动态发现协议（Dynamic Peer Detection）来发现并配置RadSec服务器，而不是传统的静态路由或RADIUS协议。 4. OpenRoaming允许运营商和第三方提供者共同参与，并将认证和计费策略纳入到OpenRoaming系统中。 5. OpenRoaming采用开放标准化的方式，与其他已有的Wi-Fi漫游解决方案相兼容。


4. draft-happel-structured-email-trust-02

  • Title: Trust and security considerations for Structured Email
  • Authors: Hans-Jörg Happel(happel@audriga.com), Arnt Gulbrandsen(arnt@gulbrandsen.priv.no)
  • Summary: 这篇文稿讨论了电子邮件中的结构化邮件和其信任和安全考虑。它探讨了不同类型的网络安全和隐私问题，以及这些情况下可能采取的安全措施。此外，还提出了实施指南、实施状况和安全性考虑等主题。该文档提供了一种框架来分析和管理电子邮件中的结构化数据，以确保它们既安全又可靠。
  • Diff: 新的标准文档讨论了电子邮件中的结构化数据处理的安全和信任问题，并给出了相关建议。主要区别在于： 1. 程序语言：原文为要求使用Requirements Language（需求语言），而新版则直接在第一部分指出该文档讨论的是“Trust and security considerations for Structured Email”。 2. 相关安全考虑：新增了对自动处理、外部引用以及发送者签名的信任机制进行了详细介绍。 3. 列表格式：删除了原始文档中的表格，改为用200字左右的中文进行总结。 总体而言，新版标准文档更加详细地讨论了邮件结构化数据的处理安全性和信任性，并提供了相应的建议。