One document matched: draft-ietf-sacm-architecture-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY I-D.ietf-sacm-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-use-cases.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-requirements.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-terminology">
<!ENTITY I-D.handt-sacm-alternate-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.handt-sacm-alternate-architecture.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sacm-architecture-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters P-->
<title abbrev="Abbreviated Title">Secure Automation and Continuous Monitoring (SACM) Architecture</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Nancy Cam-Winget" initials="N." surname="Cam-Winget" role="editor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3550 Cisco Way</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
<!-- Reorder-->
</postal>
<email>ncamwing@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Brian Ford" initials="B." surname="Ford">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>5507-10 Nesconset Hwy #242</street>
<city>Mt Sinai</city>
<country>US</country>
<code>11766</code>
<region>NY</region>
</postal>
<email>brford@cisco.com</email>
</address>
</author>
<author fullname="Lisa Lorenzin" initials="L." surname="Lorenzin">
<organization>Pulse Secure</organization>
<address>
<postal>
<street>2700 Zanker Rd, Suite 200</street>
<city>San Jose</city>
<country>US</country>
<code>95134</code>
<region>CA</region>
</postal>
<email>llorenzin@pulsesecure.net</email>
</address>
</author>
<author fullname="Ira E McDonald" initials="I." surname="McDonald">
<organization>High North Inc</organization>
<address>
<postal>
<street>PO Box 221</street>
<city>Grand Marais</city>
<country>US</country>
<code>49839</code>
<region>MI</region>
</postal>
<email>blueroofmusic@gmail.com</email>
</address>
</author>
<author fullname="Aaron Woland" initials="A." surname="Woland">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1900 South Blvd. Suite 200</street>
<city>Charlotte</city>
<country>US</country>
<code>28203</code>
<region>NC</region>
</postal>
<email>loxx@cisco.com</email>
</address>
</author>
<date month="November" year="2014"/>
<area>General</area>
<workgroup>SACM</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes an architecture for standardization of interfaces, protocols and information
models related to security automation and continuous monitoring. It describes the basic architecture,
components and their interfaces defined to enable the collection, acquisition and verification of Posture
and Posture Assessments.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Several data models and protocols are in use today that allow different applications to perform
the collection, acquisition, and assessment of posture. These applications can vary from being focused
on general system and security management to specialized configuration, compliance, and control systems.
With an existing varied set of applications, there is a strong desire to standardize data models,
protocols, and interfaces to better allow for the automation of such data processes.</t>
<t>This document addresses general and architectural requirements defined in <xref target="I-D.ietf-sacm-requirements"/>.
This document describes an architecture to enable standardized collection, acquisition, and verification
of Posture and Posture Assessments. This architecture includes the components and interfaces that can be
used to better identify the Information Model and type(s) of transport protocols needed for communication.</t>
<t> This document uses terminology defined in <xref target="I-D.ietf-sacm-terminology"/>.</t>
</section>
<section anchor="problem-statement" title="Problem Statement">
<t>Securing information and the systems that store, process, and transmit that information is a
challenging task for organizations of all sizes, and many security practitioners spend much of their
time on manual processes. Administrators can't get technology from disparate sources to work together;
they need information to make decisions, but the information is not available. Everyone is collecting
the same data, but storing it as different information. Administrators therefore need to collect data
and craft their own information, which may not be accurate or interoperable because it's customized by
each administrator, not shared.</t>
<t>Security automation and continuous monitoring require a large and broad set of mission and business
processes; to make the most effective of use of technology, the same data must support multiple processes.
The need for complex characterization and assessment necessitates components and functions that
interoperate and can build off each other to enable far-ranging and/or deep-diving analysis.</t>
</section>
<section anchor="arch" title="Architectural Overview">
<t>At a high level, the architecture describes 'How' and 'Where' information and assessment of
posture may be collected, processed or assessed. Three main functional components are
defined: a Posture Assessment Information Consumer (C), a Posture Assessment Information
Provider (P), and a Controller (Cr) used to facilitate some of the security functions such
as authentication and authorization and other metadata functions.</t>
<figure title="Simple Architectural Model" anchor="simple-architectural-model">
<artwork>
<![CDATA[
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | Posture Assessment |
+-| Information Consumer (C) |
+--------------------------------------+
/ \ / \ / \
/ \ / \ / \
- - - d - - -
|| ||A | a |B | |C
|| || | t | | |
- - - a - | |
\ / \ / | |
\ / \ / | |
/|---------------------|\ | |
/|----/ \--------| d |--|\
/ / Controller (Cr) \ ctrl | a | \
\ \ [Broker/Proxy/Repository] / plane | t | /
\|----\ /--------| a |--|/
\|---------------------|/ | |
/ \ / \ | |
/ \ / \ | |
- - - d - | |
|| ||A | a |B | |C
|| || | t | | |
- - - a - - -
\ / \ / \ /
\ / \ / \ /
+------------------------------------+
| |-+
| Posture Assessment | |
| Information Provider (P) | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
]]>
</artwork>
</figure>
<section anchor="roles" title="Component Roles">
<t>An endpoint, as defined in <xref target="I-D.ietf-sacm-terminology"/>, can
function in two primary ways: as the target of an assessment, and/or as a functional component
of the SACM architecture that can instantiate one or more capabilities (see <xref target="capabilities"/>).
Individual endpoints may be a target endpoint, or a component, or both simultaneously.
Components can take on the role of Posture Assessment Information Provider, Posture Assessment
Information Consumer, and/or Controller.</t>
<section anchor="provider" title="Posture Assessment Information Provider">
<t>The Posture Assessment Information Provider (P or Provider) is the component that
contributes Posture Assessment Information and/or Guidance either spontaneously or
in response to a request. A Provider can be a Posture Evaluator, Posture Collector,
or an application that has aggregated Posture Assessment Information that can be shared.</t>
<t>The Provider implements the capabilities and functions that must be handled to share or
provide Posture Assessment information.</t>
<t>A Provider may provide information spontaneously, or in response to a direct request
from a Consumer. The information may be filtered or truncated to provide a subset of the
requested information to honor the request. This truncation may be performed based on the
Consumer's request and/or the Provider's ability to filter. The latter case may be due
to security considerations (e.g. authorization restrictions due to domain segregation,
privacy, etc.).</t>
<t>The Provider may only be able to share the Posture Assessment Information using a
specific data model and protocol. It may use a standard data model and/or protocol, a
non-standard data model and/or protocol, or any combination of standard and non-standard
data models and protocols. It may also choose to advertise its capabilities through a
metadata abstraction or through the use of the registration function of the Controller
(see <xref target="controller"/>) [QUESTION: Are these different?].</t>
<t>The Provider must be authorized to provide the Posture Assessment Information and
further, be authorized to do so with the specific data models and protocols.</t>
</section>
<section anchor="requestor" title="Posture Assessment Information Consumer">
<t>As described in Section 2.2 of the SACM Use Cases <xref
target="I-D.ietf-sacm-use-cases"/>, several usage scenarios are posed with different
application types requesting posture assessment information. Whether it is a
configuration verification system; a checklist verification system; or a system for
detecting posture deviations, compliance or vulnerabilities, they all need to acquire
information about Posture Assessment. Thus, the architectural component to enable such
requests is defined as a Posture Assessment Information Consumer (C or Consumer).</t>
<t>The Consumer implements the capabilities and functions that must be handled in order to
facilitate a Posture Assessment Information Request. Requests can be either for a
single posture attribute or a set of posture attributes where those attributes can be
the raw information or an evaluated or assessed state based upon that information. The
Consumer may further choose to query for the information directly (one-time query), or
to request for updates to be provided as the Posture Assessment Information changes
(subscription). A request could be made directly to an explicitly identified Posture
Assessment Information Provider (P or Provider), but a Consumer may also desire to
obtain the information without having to know the available providers.</t>
<t>There may be instances where a Consumer may be requesting information from various
Providers and due to its policy or application requirements may need to be better
informed of the Providers and their capabilities. In those use cases, a Consumer may
also request to discover the respective capabilities of those Providers using the
discovery function of the Controller (see <xref target="controller"/>).</t>
<t>The Controller (described below) must authorize a Consumer to acquire the information
it is requesting. The Consumer may also be subject to limits or constraints on the
numbers, types, sizes, and rate of requests.</t>
</section>
<section anchor="controller" title="Controller">
<t>The Controller (Cr) may be an independent endpoint, or an abstracted component running
on an endpoint has multiple capabilities. The purpose of the Controller is to execute on
security functions and overall system functions including:
<list hangIndent="1" style="hanging">
<t hangText="Authentication:">The architecture must account for an abstraction where a
Controller may be defined to affect the authentication of Consumers and Providers
independent of the actual information sharing communication channel. This supports
use cases where:<list style="symbols">
<t>Consumers may request information independent of knowing the identities of the
Providers.</t>
<t>Providers may want to share the information without prior solicitation.</t>
</list>
</t>
<t hangText="Authorization:">To restrict how Posture Assessment Information is shared
between the Consumers and Providers. At minimum a management function must define
the necessary policies.</t>
<t>The introduction of the Controller supports use cases where:<list style="symbols">
<t>Consumer's may request information independent of knowing the identities of the
Provider's</t>
<t>Providers may want to share information unsolicited</t>
</list></t>
<t>The architecture must account for an abstraction where a Controller may be defined
to affect the authentication of the Consumers and Providers independent of the
actual information sharing communication channel.</t>
<t hangText="Identity Management:">As typically, Identity Management for
authentication and authorization policies are best defined through a centralized
component, the Controller also provides these services. </t>
<t hangText="Registration/Discovery:">A discovery mechanism is required to facilitate
the interaction of Providers that may have different Posture Assessment Information
and potentially limited (or a rich set) of ways in which they can share the
information. Through the use of a discovery mechanism, Consumers can have visibility
of the Providers present and the type(s) of Posture Assessment Information that is
available and how it can be requested. Similarly, a Provider may need to register
what Posture Assessment Information it can share and how it can share it (e.g.
protocol or with filtering capabilities). Enabling this function through a
Controller also allows for the distinct definition of security considerations (e.g.
authorized registration of capabilities and of Providers) beyond how a Provider may
define its own capability.</t>
</list></t>
<t>These functions may be provided by a single component, or by multiple components. For
example, an endpoint acting as a data store may also act as its own broker.</t>
<t>The Controller also helps define how to manage an overall SACM system that allows for
Consumers to obtain the desired Posture Assessment Information without the need to
distinctly know and establish a one (Consumer) to many (Provider) connections. Note that
the Controller also allows for the direct discovery and connection between a Consumer
and Provider.</t>
</section>
</section>
<section anchor="interface" title="Interfaces between Consumers, Providers, and Controllers">
<t>
As shown in <xref target="simple-architectural-model"/>, communication can proceed with
the following interfaces and expected functions and behaviors:</t>
<t><list hangIndent="1" style="hanging">
<t hangText="A:"> interface "A" shown in <xref target="simple-architectural-model"/>
handles the management and control functions that are needed to establish, at minimum,
a secure communication between Consumers and Providers. The interface must also handle
the functions to allow for the discovery and registration of the Providers as well as
the ways in which Posture Assessment Information can be provided (or requested).</t>
<t hangText="B:"> interface "B" shown in <xref target="simple-architectural-model"/>
enables Providers to share their Posture Assessment Information spontaneously;
similarly, it enables Consumers to request information without having to know the
identities (or reachability) of all the Providers that can fulfill Consumers'
requests.</t>
<t hangText="C:"> interface "C" shown in <xref target="simple-architectural-model"/>
demonstrates the ability and desire for Consumers and Providers to be able to
communicate directly when a Provider is sharing Posture Assessment Information
directly to a Consumer. The interface allows for the different data models and
protocols to be used between a Consumer and a Provider with the expectation that the
appropriate authentication and authorization mechanisms have been employed to
establish a secure communication link between the Consumer and the Provider.
Typically, it is expected that the secure link establishment occurs as a management or
control function through the abstracted Controller role (e.g. the Controller could be
a proxy or could be embedded in a Consumer or a Provider).</t>
</list></t>
<t>TODO - add text around the usage of various protocols for endpoint data collection
(SNMP, NETCONF, etc.?)</t>
</section>
</section>
<section anchor="capabilities" title="Component Capabilities">
<t>TODO: Intro text about capabilities</t>
<section anchor="control-plane-capabilities" title="Control Plane Capabilities">
<t>TODO: Intro text about control plane capabilities</t>
<t>TODO: Determine whether broker, proxy, and repository need to be full subsections or paragraphs in this section.</t>
<t><list hangIndent="1" style="hanging">
<t hangText="Broker:"> Intermediary negotiating connection between provider and consumer.</t>
<t hangText="Proxy:">Intermediary negotiating on behalf of a consumer.</t>
<t hangText="Repository:">Intermediary receiving and storing data from a provider, and providing stored data to a consumer.</t>
</list></t>
</section>
<section anchor="data-plane-capabilities" title="Data Plane Capabilities">
<t>TODO: Intro text about data plane capabilities</t>
<section anchor="collector" title="Collector">
<t>A collector consumes Guidance and/or other Posture Assessment Information; it provides Posture Assessment Information. Collectors may be internal or external.</t>
<section anchor="internal-collector" title="Internal Collector"><t>TODO</t></section>
<section anchor="external-collector" title="External Collector">
<t>An external collector is a collector that observes endpoints from outside. These collectors may be configured and operated to manage assets for reasons including, but not limited to, posture assessment. Collectors that are not primarily intended to support posture assessment (e.g. intrusion detection systems) may still provide information that speaks to endpoint posture (e.g. behavioral information).</t>
<t>Examples:<list style="symbols">
<t>A RADIUS server whereby an endpoint has logged onto the
network</t>
<t>A network profiling system, which discovers and classifies
network nodes</t>
<t>A Network Intrusion Detection System (NIDS) sensor</t>
<t>A vulnerability scanner</t>
<t>A hypervisor that peeks into the endpoint, the endpoint being a
virtual machine</t>
<t>A management system that configures and installs software on the
endpoint</t>
</list></t>
</section>
<section anchor="interactions-with-endpoint" title="Collector Interactions With Target Endpoints"><t>TODO</t></section>
</section>
<section title="Evaluator">
<t>An evaluator consumes Posture Assessment Information, Evaluation Results, and/or Guidance; it provides Evaluation Results. An evaluator may consume endpoint attribute assertions, previous evaluations of posture attributes, or previous reports of Evaluation Results.</t>
<t>[kkw-i don't think this conflicts with the definition in the terminology doc re: that evaluation tasks evaluate posture attributes.]</t>
<t>[cek-I like the change. I think it *does* require a change in the terminology doc, though.]</t>
<t>Example: a NEA posture validator <xref target="RFC5209"/></t>
<t>[jmf- a NEA posture validator is not an example of this definition. A NEA posture assessment is, maybe?]</t>
<t>[cek-Why isn't a NEA posture validator an example?]</t>
</section>
<section title="Report Generator">
<t>A report generator consumes Posture Assessment Information, Evaluation Results, and/or Guidance; it provides reports. These reports are based on:<list style="symbols">
<t>Endpoint Attribute Assertions, including Evaluation Results</t>
<t>Other Reports (a weekly report may be created from daily
reports)</t>
</list></t>
<t>It may summarize data continually, as the data arrives. It also may summarize data in response to an ad hoc query.</t>
</section>
<section title="Data Store">
<t>A data store consumes any data; it provides any data.</t>
</section>
</section>
</section>
<section anchor="example" title="Example Illustration of Capabilities and Workflow">
<t>TODO: revise all this text</t>
<figure title="Communications Model" anchor="communications-model">
<artwork>
<![CDATA[
+-------------------------------+
| +-------------------------------+
| | |
+-| Controller (Cr) |
+-------------------------------+
// / \ \\
// / \ \\
A // / \ \\ A
// / \ \\
// / B B \ \\
// / \ \\
+-------------------------------+ +-------------------------------+
| +-------------------------------+ A | +-------------------------------+
| | |===========| | |
| | Posture Assessment |-----------| | Posture Assessment |
+-| Information Consumer (C) | C +-| Information Provider (P) |
+-------------------------------+ +-------------------------------+
]]>
</artwork>
</figure>
<t> SACM's focus is on the automation of collection, verification and update of system security configurations pertaining to endpoint assessment. In order to carry out these tasks, the architectural components shown in <xref target="simple-architectural-model"/> can be further refined as: </t>
<t><list hangIndent="1" style="hanging">
<t hangText="Posture Assessment Information Providers:"> a Provider may be dedicated to perform either the collection, aggregation or evaluation of one or more posture attributes whose results can be conveyed to a Posture Assessment Information Consumer. In this example form of the SACM architecture model, these are shown as Collection, Evaluation, and Results Providers. Note that there may be posture attributes or posture assessment information that articulates Guidance information which may or may not be present in the architecture.</t>
<t hangText="Posture Assessment Information Consumers:"> a Consumer may request or receive one or more posture attributes or posture assessment information from a Posture Assessment Information Provider for their own use. In this example form of the SACM architecture model, these are shown as Collection, Evaluation, and Results Consumers. Note that there may be posture attributes or posture assessment information articulating Guidance information which may or may not be present in the architecture to be provided or consumed. </t>
<t hangText="Data Stores:"> a Data Store is both a Provider and a Consumer, storing one or more posture attributes or assessments for endpoints. It should be understood that these repositories interface directly to a Provider or Consumer (and Guidance) but the interfaces used to interact between them is outside the scope of SACM (e.g. no interface arrows are shown in the architecture).</t>
</list></t>
<t> <xref target="example-flow"/> illustrates an example flow for how Posture Assessment Information may flow. </t>
<figure anchor="example-flow" title="Example Posture Information Flow">
<artwork>
<![CDATA[
+-------------+
|Evaluation |
+-------------+ |Guidance +--+
|Endpoint | |Capability | |
+-------+ | +-------------+ |
| | | |
| +-------+-----+ +-----v-------+
| Collection | |Evaluation |
+-> Capability +--+--------+ |Capability |
| | |Collection | +-----------+ +----------+
| +------------+Provider | | |---| |
| | | |Collection | |Evaluation|
| | | |Consumer | |Provider |
| +----+------+ +----^------+ +---+------+
++---------+ | | |
|Collection| +-----v------+ +---+--------+ |
|Guidance | | | |Collection | |
|Capability| |Collection | |Provider | |
| | |Consumer |-----| | |
+----------+ +------------+ +------------+ |
| Collection | |
| Data Store | |
+------------+ |
|
+--------------+ +---------------+ |
|Evaluation | |Evaluation | |
|Results | |Consumer <-----+
|Provider |-----------| |
+-----+--------+ +---------------+
| |Results Reporting|
| |Capability |
| +------------^----+
| |
+-----v--------+ +----+------+
|Evaluation | |Reporting |
|Results | |Guidance |
|Consumer | |Data Store |
+---+----------+ +-----------+ +-------------+
| | Results |
+-----------------------------> Data Store |
| |
+-------------+
]]>
</artwork>
</figure>
<t>TODO - add example of / more content around interactions with endpoint, possible communications patterns</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Jim Bieda, Henk Birkholz, Jessica Fitzgerald-McKay, Trevor Freeman, Adam Montville, and David Waltermire for participating in architecture design discussions, reviewing, and contributing to this draft.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD. This section will need to cover the AAA and confidentiality/integrity of the data and data transports to be considered. Also, the considerations for the interfaces (which may be covered in transports) between the Consumers, Providers, and the Controller.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&I-D.ietf-sacm-use-cases;
&I-D.ietf-sacm-requirements;
&I-D.ietf-sacm-terminology;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC5209;
&RFC3444;
</references>
<!-- Change Log
v00 2014-06-16 NCW Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:28:20 |