One document matched: draft-schaad-sacm-architecture-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY RFC4741 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4741.xml">
<!ENTITY RFC5209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5209.xml">
<!ENTITY RFC7632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY RFC6876 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6876.xml">
<!ENTITY RFC7171 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7171.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY SACM-Requirements SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-requirements.xml">
<!ENTITY SACM-NEA SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.coffin-sacm-nea-swid-patnc.xml">
]>
<?xml-stylesheet type="text/css" href="rfc7749.css"?>
<?rfc toc="yes"?>
<rfc category="info" docName="draft-schaad-sacm-architecture-00" ipr="trust200902">
<front>
<title>Prospective Architecture for SACM</title>
<author fullname="Jim Schaad" initials="J" surname="Schaad">
<organization>August Cellars</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<author fullname="David Waltermire" initials="D.W."
surname="Waltermire">
<organization>National Institute of Standards and
Technology</organization>
<address>
<postal>
<street>100 Bureau Drive</street>
<city>Gaithersburg</city>
<region>Maryland</region>
<code>20877</code>
<country>USA</country>
</postal>
<email>david.waltermire@nist.gov</email>
</address>
</author>
<date/>
<area>Security</area>
<workgroup>SACM</workgroup>
<abstract>
<t>
This document describes the high level architecture for Security Automation and Continuous Monitoring (SACM).
The architecture identifies the components that provide for the collection, storage, dissemination, and evaluation of posture information.
This architecture also describes the interfaces and associated operations that define the interactions between these components.
This information will inform future engineering work around identifying existing standards for collecting, storing, disseminating, and evaluating endpoint posture information.
This architecture will also help in identifying standardization gaps that require new engineering effort.
</t>
<t>
Security practitioners need to request, analyze, and aggregate posture information from disparate sources that use differing means to identify endpoints, hardware, software, and configurations.
This task is made harder by the large number of different protocols and formats needed to bring together all of this information into a single view.
This architecture provides a means to automatically gather posture data together for standardized dissemination to downstream components.
This allows security practitioners that leverage this architecture to focus on managing security problems, not data.
</t>
<!--
<t>
Security Automation and Continuous Monitoring (SACM) is designed to collect, verify and update system security information in an automated manner.
Currently security practitioners need to be conversant in a large number of different protocols and formats, then they need to combine these disparate sources together into a single view.
SACM intents to provide a method that automatically gathers the data together and provides it in a single information model so that security practitioners can focus on identify and re-mediating security problems.
</t>
<t>
This document lays out a high level architecture for SACM where the different components in the architecture are identified and their interactions are briefly discussed.
</t>
-->
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document represents some views of the authors but should not be considered to be the opinions of them either individually or collectively.
The document is designed both to clarify the thinking of the authors as well as to create some discussion on what the architecture looks like.
As such, it is entirely reasonable that section of the document (i.e. the one on the IM) should be combined, removed or replaced.
This can be either because they do not belong in this document or because they are just wrong.
</t>
<t>
Another aim of the document is to clarify what pieces of the work may need to be done in the future as this may help clarify some of the dicussions are underway or have been completed.
This is the aim of the list of protocols associated with a component.
With this, we can perhaps start looking at what DM(s) are doing when they are sending data.
</t>
<t>
Jim: Part of the questions that would need to be addressed before publication is the audience of the document.
It is my personal feeling that the document should be sufficently complete that it can be handed to a person who is not in the community, and they should be able to understand all of the pieces and how they interact.
</t>
<t>To manage information system security risk, network operators
must know the operational state of the endpoints they manage,
and must be able to assess known vulnerabilities against this
operational state to understand potential security risks. This
helps the network operator to determine which threats a given
endpoint might be subject to, and supports decision making
around actions that mitigate the associated risk. Vulnerability
assessment is an example of this type of analysis, where
endpoint software inventory is compared with known vulnerable
software versions reported by software vendors and vulnerability
researchers to determine which endpoints have vulnerable
software. Knowledge of vulnerable software on endpoints can then
drive software patching activities, reducing the attack surface
of the network. Additionally, many organizations develop
compliance requirements based on their understanding of security
risks. These compliance requirements, also called policies,
define what software may be installed on a given endpoint and
how that software must be configured to achieve a sufficient
level of security risk reduction for the organization. In both
cases, an organization needs to have an up-to-date view of the
operational state of the endpoints connected to their networks
and accessing their information systems.</t>
<t>Understanding the operational state of an endpoint (hereafter
referred to as "endpoint posture") requires the ability to
collect and evaluate endpoint posture information as posture
changes occur. In order to make decisions quickly to prevent,
deflect, or mitigate an attack, network operators must be able
to collect, disseminate, and evaluate posture information within
narrow timeframes. Making decisions quickly relies on automating
posture collection and evaluation processes so that network
operators can identify endpoints, software, and software
configurations in a meaningful and enduring way that is suitable
for trending and longer-term analysis. This document describes a
suitable architecture that supports automated collection,
storage, dissemination, and evaluation of endpoint posture
information.</t>
<t>
Still needs text dealing with other uses.
</t>
<t>
There is an IM and a DM. Some differences between these are found in <xref target="RFC3444"/>.
</t>
</section>
<section title="SACM Components">
<t>
The SACM architecture is made up of a number of different entities each of which supports one or more roles.
A picture of what roles can exist can be found in <xref target="ArchDrawing"/>.
</t>
<figure title="SACM Architecture" anchor="ArchDrawing">
<artwork src="image.svg">
----!----1----!----2----!----3----!----4----!----5----!----6----!-
+-----------+ +---------------+ +------------+ +-------+
| Raw | | | | | | |
| Data | | Authenticator | | Authorizor | | Data |
| Collector | | | | | | Store |
+-----------+ +---------------+ +------------+ +-------+
| | | /
+-----------+ +-----------+
| SACM |- /------\ -| Directory |
| Collector | / SACM \ +-----------+
+-----------+ / \
| | +-------------+
+--------+ \ CLOUD / -| Aggregators |
| SACM |----- \ / +-------------+
| Proxy | \------/
+--------+ +------------+
| | | | Evaluators |
/-----------\ +------------+ +-----------+ +------------+
| External | | Policy | | External |
| SACM | | Management | | Event |
| Cloud | +------------+ | Processor |
\-----------/ +-----------+
</artwork>
</figure>
<t>
A description of the different roles in the picture above is as follows:
<list style="hanging">
<t hangText="Authenticator:">
is a role that provides authentication services for other entities within the architecture.
Entities can interact with an authenticator once and be provided with a long term credential, such as a certificate, or can be interacted with whenever authentiction is needed, such as an EAP server.
Even when interacting on a frequent basis, a short term credential such as a SAML assertion can be provided.
Interactions with an authenticator include:
<list style="symbols">
<t>Enrollment: The act of being introduced to the authentication system.</t>
<t>Revocation: The act of being removed from the authentication system.</t>
<t>Authentication: The act of proving an identity to the authentication system matches one that was introduced to it.</t>
</list>
</t>
<t hangText="Authorizer:">
is a role that provides authorization and access control to data and capabilities for an entity within the architecture.
Frequently, but not always authorizers and authenticators will be co-located and administered.
Interactions with an authorizer include:
<list style="symbols">
<t>Authorization: An administrative act of adding authorizations for an identity.</t>
<t>Revocation: An administrative act of removing authorizations for an identity.</t>
<t>Querying: The act of asking if an identity is authorized for performing an action or receiving data.</t>
</list>
</t>
<t hangText="Directory:">
is a role that provides methods to locate where services and data can be found in the architecture.
Interactions with a directory include:
<list style="symbols">
<t>Publishing: The act of telling a directory what services or data can an entity provides.</t>
<t>Unpublishing: The act of removing from a directory a list of services or data that an entity provides.</t>
<t>Querying: The act of asking a directory where a service or set of data can be found.</t>
<t>Directory Location: The act of finding a directory in the first place.</t>
</list>
</t>
<t hangText="Data Store:">
is a role that provides a repository for data to be published into and queried from.
Interactions with a data store include:
<list style="symbols">
<t>Publishing: The act of providing data to a data store.</t>
<t>Querying: The act of obtaining data from a data store.</t>
<t>Synchronization: The act of two data stores making the data they hold consistent.</t>
</list>
</t>
<t hangText="SACM Collector:">
is a role that obtains data and then publishes it into the SACM environment.
A SACM collect will either publish the data to a data store, or act as a data store itself.
SACM collectors can location and publish data either in response to a query, if they act as a data store, on a schedule, or in response to some event.
A SACM collector will format data provided to it into the SACM Information model, decorating it as necessary, and then provide it to the rest of the environment.
</t>
<t hangText="Raw Data Collector:">
is a role that is ancillary to the SACM architecture rather than being a core component.
Raw data collectors gather data which is fed to a SACM collector.
Examples of raw data collectors could be NEA components, asset management databases (hardware, software or wetware), or network state databases such as a DHCP server.
</t>
<t hangText="Aggregator:">
is a role that looks at data in the SACM environment, combines together pieces of related data and publishes the new relationships back into the environment.
An example of what an aggregator might do is to look at the information provided by a DHCP server along with historic IP address information for a machine to determine when records referring to a machine are the same one or different ones.
</t>
<t hangText="Evaluator:">
is a role that looks a the data in the SACM environment along with a set of evaluation criteria, compares the data with the criteria and publishes the results of the evaluation back into the environment.
Evaluators can look at things as simple as are all of the pieces of software on a machine licensed to as complicated as comparing data for a network or machine against an intrusion report.
</t>
<t hangText="SACM Proxy:">
is a role that allows for data to be transfered between two different SACM environments.
SACM proxies frequently provide the data store role as well so that they can know what data needs to be synchronized between the two subsystems.
SACM proxies can exist in environments where they are always active, or where only intermittent connectivity exists between the two subsystems.
</t>
<t hangText="Policy Management:">
is a role that controls different policy configurations for the environment.
This includes such things as:
What to report and who to report it to.
Conditions under which automated remediation should automatically be applied.
What the priorities are used in performing evaluations and frequencies of evaluations.
</t>
<t hangText="External Event:">
is a role that acts between the SACM environment and external non-SACM systems.
One type of interaction that would be covered here is dealing with external vulnerability reports.
As reports come from external sources, they need to be messaged into the correct format for storage in the SACM IM and then supplied to evaluators to identify if the vulnerability exists in systems SACM monitors.
The same thing can happen in reverse, where vulnerabilities or conditions that look like they might be vulnerabilities could be reported to an external centeralized authority.
</t>
</list>
</t>
<t>
In many cases it is not always clear where a single service falls.
A simple example of this is where the NEA protocol would fit into the picture.
NEA can be treated either as an internal collector or as an external collector depending on what is being collected and how the observer feels about the world.
Many of the core things that NEA collects today are not directly mapped to the SACM Information Model without some massaging, as such it is reasonable to look at this as being an external collector with the NEA server being co-resident with the SACM External Collector.
This entity would take the NEA data, convert it into the SACM IM, and then publish it using one of the SACM DMs.
On the other hand, it is also possible that NEA would collect data that corresponds directly to a SACM IM and return the data already encoded in a SACM DM.
In this case, it would make sense to consider the NEA client as being a SACM Internal collector which publishes using NEA as the publishing protocol and the ENA server being either a proxy or a data store.
</t>
<section title="Combining Roles">
<t>
In many cases more than one role will be combined into a single entity.
In this section a view of how roles might be combined together to provide support as a proxy for the Ice Station Zebra use case in <xref target="RFC7632"/>.
In this scenario, the enterprise has two different SACM sub-systems.
One sub-system is at the main enterprise and the other sub-system is at Zebra.
There is not a constant high-speed connection between the two sub-systems, instead data is exchanged an intermittent, low-speed, high-latency link.
</t>
<t>
The proxy role is the one that sits between the two subsystems, that is what it is designed for.
Due to the link, one would have two different proxies one on either side of the link.
The entity that contains the proxy may additionally have the following roles:
<list style="symbols">
<t>
Data Store: Placing a data store on the proxy allows for queries about devices on the other size to be queued up and synchronized across the connection.
Additionally, having a data store for those items on the opposite side of the link allows that data store to specialize on how to optimally synchronize data across the link.
</t>
<t>
Directory Service:
Placing a directory service that tells about the systems and services on opposite side of the connection allows for the ability to filter down the set of registrations that are passed over the link.
</t>
<t>
Authorization Service:
The authorizations may be changed for some entities based on the location of the service they are asking about.
A user may have basically unlimited authorization for the local subsystem, but may have limited authorization for the remove subsystem.
This rule would apply whether they were at the home base or at Zebra.
</t>
</list>
</t>
</section>
<section title="SACM Collection">
<t>
The collection of data in the SACM world is one of the major issues that needs to be dealt with.
For this reason we drill down into that problem here.
</t>
<t>
When dealing with just the issue of collcition, the SACM architecture can be thought of as having a left-hand side and a right-hand side, illustrated by the dotted line in <xref target="CollectionSvg"/>.
The left-hand side describes how management protocols can be used to allow a Collection Controller (CC) <cref source="JLS">This is equavalent to a SACM External Collector. Does that mean we should rename one or other?</cref> to choreograph the collection of endpoint posture from a set of target endpoints through posture change subscriptions or direct requests, and for endpoints to report posture information based on these collection requests.
The left-hand side of the architecture is built upon existing endpoint management protocols; however, new protocols are needed to separate out the evaluation and collection capabilities defined by some of these protocols (e.g., NEA).
</t>
<!--
<t>
When looking at the architecture, different people will interpret how the assignment of a given role is done to a perticular entity.
As an example of this, the NEA protocol <xref target="RFC5209"/> is being adopted into the SACM infrastructure.
This raises the question of how the entities in the NEA architecture are mapped into the SACM architecture.
One viewpoint is that the NEA client maps to an raw data collector and the NEA server maps to a SACM collector.
The second viewpoint is that there is a multi-entity SACM collector that contains both the NEA client and server within it.
While both viewpoints are viable, the SACM group as a whole follows the second.
</t>
-->
<figure title="SACM Architecture" anchor="CollectionSvg">
<artwork src="architecture.svg"><![CDATA[ |
+----------+ |
| | | +-----------+
| Target +---------+ | +---------------------------> |
| Endpoint | | | | | Datastore |
| | | | | +------------> |
+----------+ +v---------v-+ | | |
| | {-------v---} +-----^-----+
+----------+ | | { } |
| | | Collection | { Messaging } |
| Target <--------> Controller <--> Protocol +--------+ |
| Endpoint | | | { | | |
| | | | { | Broker | |
+----------+ | | {--^-----+ | |
+^---------^-+ | +--------+ |
+----------+ | | | | +-----v-----+
| | | | | +-----------------> |
| Target <---------+ | | | Evaluator |
| Endpoint | | +---------------------------> |
| | | | |
+----------+ | +-----------+
|
[-----------] |
Management |
Protocol |
Interfaces |
|
Left-Hand Side | Right-Hand Side]]>
</artwork>
</figure>
<t>
At the center of the SACM architecture is a CC that spans the
left- and right-hand sides. The CC choreographs the collection
of posture information on the left-hand side, and provides a
common view of the collected posture for the right-hand side.
Working in this way, all Evaluators that consume posture
information from a given CC are provided a common view of all
endpoint posture information collected by the CC. This common
view can be accessed by Evaluators who need this information for
asset management, configuration management, and vulnerability
management use cases, and collected posture information can also
be made available to other posture consumers to support
unforeseen use cases.
</t>
<t>
The right-hand side of the SACM architecture defines how
posture information is shared between components that provide
collected posture (e.g., a Collection Controller) and components
that store, evaluate, and use collected posture information on
the network. Analytical and reporting capabilities need to be
able to publish and subscribe to posture data feeds from other
tools that have the required information. Other capabilities may
need to access data stores of previously collected, historic
posture information. By separating the methods of posture
collection from how this information is consumed for use, the
SACM architecture protects endpoints from being overloaded by
downstream requests, and posture data from unauthorized access.
These benefits support security automation by providing improved
access to posture information by downstream consumers, and
allowing downstream components to communicate information
derived from posture analysis.
</t>
<t>
The following subsection discuss the motivations for the SACM architecture.
</t>
<section title="Use of Existing Management Protocols">
<t>
On the left-hand side of the SACM architecture, a number of
existing, widely deployed endpoint management protocols
support the collection of posture information from endpoints.
Examples of these protocols include: the Simple Network
Management Protocol (SNMP) <xref target="RFC3411"/>, Network
Configuration Protocol (NETCONF) <xref target="RFC4741"/>, and
the Network Endpoint Assessment (NEA) protocol <xref
target="RFC5209"/>. These and similar protocols provide
extension points that allow for new types of posture
information to be represented and collected over time. For
these reasons, integration with existing posture collection
protocols is a key feature of this architecture.
</t>
<t>
A gap in the functionality provided by existing protocols is
a generalized mechanism to allow external components to drive
data collection activities through a common, protocol agnostic
collection interface. This is a feature supported by the SACM
architecture through the definition of a common interface on
the right-hand side that allows the CC to choreograph posture
collection through implementations of existing management
protocols on the left-hand side.
</t>
</section>
<section title="The Need for Collection Choreography">
<t>
Collection choreography is the act of managing posture
collection activities on the left-hand side to produce a
common view of collected posture information for one or more
collection consumers on the right-hand side. Collection
choreography is supported in the SACM architecture by the
Collection Controller (CC) for the following reasons:
<list style="hanging" hangIndent="6">
<t hangText="Simplification of Collection Clients">
Multiple
management protocols are needed to fullfil posture
information collection requests across different types of
endpoints. To provide coverage of all posture information
that may need to be collected, any component driving
posture collection must be well versed in multiple
protocols and associated data models. Developing and
maintaining this level of protocol support is a heavy
burden to place on Evaluators. Additionally, some
management solutions make use of specialized collection
managers or proxies (e.g., mobile device management) that
directly communicate with the target endpoint(s) on behalf
of requesting clients. Requiring evaluators to locate and
communicate with these proxies would discourage
development and adoption of SACM solutions. The SACM
architecture reduces the implementation burden on
Evaluators by making the CC manage which collection
services a request should be sent to when satisfying a
given SACM collection request. This allows Evaluators to
focus only on identifying and processing the data they
request, and not on managing the collection process.
</t>
<t hangText="Authenticating, Authorizing, and Controlling Access of Data Collection Consumers" >
An automated collection system can pose a significant
risk to an organization if the system can be misused by an
attacker to gain knowledge of the operational state of
endpoints. Once accessed by an attacker, this information
can be used to attack other hosts or move laterally within
a network. For this reason, access to collected endpoint
posture information must be restricted to authenticated
and authorized entities. Different management protocols
may employ different authentication and authorization
schemes. Through the use of a shared CC, access can be
controlled in a way that unifies the underlying
authentication, authorization, and access control
schemes.
</t>
<t hangText="Reducing Performance Impacts on the Target Endpoint" >
Without a common CC, Evaluators would need to directly
interact with an endpoint to request posture data.
Multiple clients operating in this way might request the
same posture data within a narrow time window, resulting
in multiple collection operations that can reduce the
operational performance of the endpoint. Use of a CC can
allow these repetitive and duplicative collection
operations to be optimized. Working in this way, the CC
can compute an optimal collection approach, using the
appropriate management protocols to efficiently collect
any needed posture data. This data can be cached by the
CC, operating as a Data Store, and can be reused within an
appropriate time window to provide multiple clients with
the same collected posture information.
</t>
</list>
</t>
<t>
For these reasons a Collection Controller is needed to
choreograph posture collection within the SACM
architecture.
</t>
</section>
<section title="Collected Information Dissemination">
<t>On the right-hand side of the SACM architecture, once
collection has been triggered and choreographed, there remains
the issue of efficiently disseminating the collected posture
information to consumers. The collection activity will have
yielded information in an arbitrary data format, often spread
across several formats with overlapping and mismatched
information. There is a need for a means to package this
information in a standardized way such that automated systems
downstream can consume it without a priori knowledge of the
source format.</t>
<t>The SACM architecture needs to support direct request
response and publish subscribe mechanisms for posture data
dissemination. In either case, arbitrary data formats can be
processed at collection time and re-enveloped by a
standardized information description. The downstream consumer
needs to only understand the enveloping model to process the
message containing posture information. It might also be
possible to allow the enveloping model to identify multiple
formats, allowing the consumer to request information from the
designated source in a specific format it recognizes and
supports.</t>
</section>
</section>
</section>
<section title="SACM Protocols">
<t>
List of protocols:
<list style="hanging">
<t hangText="Authentication:">
A method of doing an entity to authenticate itself is required.
Several potential candidates exist for this purpose.
Among these candidates are X.509 certificates, SAML assertions, EAP or GSS-API.
</t>
<t hangText="Authorization:">
A standardized method of either querying the authorization server or carrying authorization information needs to be selected.
Some of the candidates for this would be SAML assertions or X.509 attribute certificates.
</t>
<t hangText="Query:">
There will exist a standardized method for querying data from a repository.
The query protocal needs to do the following things:
<list style="hanging">
<t>
Get the required authentication for the quester.
The server needs to authenticate both that the requester has the needed rights both to make the query and to have access to the data involved.
</t>
<t>
The entities need to negotiate a data model to be used for the creation of the query and to express the query in.
</t>
<t>
The entities need to negotiate a data model, a serialization abstraction and a serialization data format for data to be returned in response to a query.
</t>
<t>
The ability to specify required meta-data as part of the query is a requirement.
As an example, the ability to require that the data be collected after a given date and time is required.
</t>
<t>
The ability to negotiate the frequency that the data is to be returned to the client.
Data may be required as a one time event or as an ongoing event.
One time events may be returned either immediately, or when the query can be completed as the data becomes available.
Ongoing responses can be based on a time interval or based on some event happening.
For ongoing response, the criteria for specify the frequency of response needs to be both negotiated and authorized.
</t>
</list>
</t>
<t hangText="Response:">
There will exist a standardized method for sending data from a server to a client.
Data may be sent to a client based either on a request for data, a prior request for data or because the server decided the client needs the data.
Servers need to do the authentication and authorization on the data to be returned at a regular basis.
</t>
<t hangText="Directory Register:">
There will exist a standardized method for registering and unregistering data in a directory service.
</t>
<t hangText="Directory Query:">
There will exist a standardized method for querying the directory service for supported services.
</t>
<t hangText="Publish:">
There will exist a standardized method for publishing data into a repository.
The method will:
<list style="symbols">
<t>
Verify the identity and authorization of the publisher.
</t>
<t>
If needed, negotiate the format in which the data is presented.
This includes the data model, data abstraction and data serialization.
</t>
<t>
Verify that the required meta-data that the publisher must provide is present.
</t>
<t>
Provide repository based meta-data.
</t>
</list>
Additionally, the repository will potentially trigger events within the server for dealing with outstanding requests for data or evaluations.
</t>
<t hangText="Synchronization:">
There will exist a standardized method for doing synchronization between multiple data stores.
This method will:
<list style="symbols">
<t>
TBD.
</t>
</list>
</t>
<t hangText="Collection:">
Many different protocols can be used to do collection over.
One of these is NEA <xref target="RFC5209"/> which acts as a transport for serializations of SACM data models.
The use of NEA as the transport satisifes the following requirements:
<list style="symbols">
<t>
NEA requires the use of TLS [TLS??] for cryptographic protection between the client and the server.
</t>
<t>
NEA has defined two authentication protocols to run between the client and the server.
These are PT-TLS <xref target="RFC6876"/> and PT-EAP <xref target="RFC7171"/>.
PT-TLS uses X.509 certificates on both the client and server side to authenticate each side.
PT-EAP allows for EAP <xref target="RFC3748"/> to be used which allows for lighter weight registration and authentication to occur.
</t>
<t>
Authorization is currently of the all or none variety.
Authorization is done at configuration time.
</t>
<t>
Discovery is not currently supported by NEA, so the server location is configured onto the client.
</t>
</list>
<xref target="I-D.coffin-sacm-nea-swid-patnc"/> represents one set of attributes to carry SACM information.
</t>
</list>
</t>
</section>
<section title="Information Model">
<t>
The SACM architecture includes a single Information Model to provide a consistent view of the data needed to do perform the endpoint posture assessment.
Additional IMs may be defined by entities other than the IETF which are supersets of the IETF IM.
This is one way that companies will be able to differentiate their products from each other.
The IM includes not only the data itself, but metadata as well.
The meta data includes, but is not limited to:
<list style="symbols">
<t>Who collected or created the data</t>
<t>When the data was collected or created</t>
<t>What data was used to create the data</t>
<t>What relationships exist between different data points or different versions of the same data point.</t>
</list>
</t>
</section>
<section title="Data Model">
<t>
The SACM architecture includes a single Data Model defined by the IETF.
Additional DMs maybe defined by entities other than the IETF.
These additional DMs may be either subsets or supersets of the IETF SACM DM.
The subset DMs are defined for doing special purpose work which does not need the full SACM DM.
</t>
<t>
The term DM is used by the SACM group in two different contexts and it is useful to discuss those two contexts.
Data Model can refer to how the data is arranged within a entity.
In this view of a DM, one can use a relational database as the conceptual view of the world.
The relations in the database reflect the relations between the data in the IM.
The use of a relational database is not the only way to implement the DM within a process.
</t>
<t>
The term DM can also refer to how the data is represented when serialized for transport between two entities.
This is the meaning that is more usual when looking at the current SACM documents.
This is sometimes referred to as the DM in transit.
</t>
</section>
<section title="IANA Considerations">
<!-- RFC Editor: Please remove this section -->
<t>This document has no IANA Considerations.</t>
</section>
<section title="Security Considerations">
<t>
This document is a high level description of the architecture of the SACM environment, as such it does not directly specify any security problems or requirements.
Security requirements for SACM can be found in other documents including the <xref target="I-D.ietf-sacm-requirements">SACM Requirements</xref>.
</t>
</section>
</middle>
<back>
<references title="Informational References">
&SACM-Requirements;
&RFC3444;
&RFC7632;
&RFC5209;
&RFC6876;
&RFC7171;
&RFC3748;
&SACM-NEA;
&RFC3411;
&RFC4741;
</references>
<section title="Acknowledgments" numbered="no">
<t>
This document is currently the opinions of just the authors and is not representative of the SACM working group or the IETF.
</t>
<t>
This document has been formed by discussions with a large number of the SACM working group members including but not limited to: Henk Birkholz, Lisa Lorenzin, Nancy Cam-Winget.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:21:47 |