PT-TLS: A TCP-based Posture Transport (PT) Protocol
draft-ietf-nea-pt-tls-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6876.
|
|
|---|---|---|---|
| Authors | Paul Sangster , Nancy Cam-Winget , Joseph A. Salowey | ||
| Last updated | 2012-04-26 | ||
| Replaces | draft-sangster-nea-pt-tls | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6876 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-nea-pt-tls-03
decision. This message type MUST only
be sent by the NEA Server when the NEA
Client and NEA Server are in the PT-
TLS Negotiation phase. The NEA Client
MUST send an Invalid Message error
code in a PT-TLS Error message if a
SASL Result is received after the PT-
TLS Negotiation phase.
7 (PB-TNC Batch) Contains a PB-TNC batch. For more
information on PB-TNC batches see
section 4 of the PB-TNC specification.
This message type MUST only be sent
when the NEA Client and NEA Server are
in the PT-TLS Data Transport phase.
Recipients SHOULD send an Invalid
Message error code in a PT-TLS Error
message if a PB-TNC Batch is received
outside of the Data Transport phase.
8 (PT-TLS Error) PT-TLS Error message as described in
section 3.9. This message type may be
used during any PT-TLS phase.
9+ (Reserved) These values are reserved for future
allocation following guidelines
defined in the IANA Considerations
section 6.1. Recipients of messages
of type 9 or higher that do not
support the PT-TLS Message Type Vendor
ID and PT-TLS Message Type of a
received PT-TLS message MUST respond
with a Type Not Supported PT-TLS error
code in a PT-TLS Error message.
3.7. PT-TLS Version Negotiation
This section describes the message format and semantics for the PT-
TLS protocol version negotiation. This exchange is used by the PT-
TLS Initiator to trigger a version negotiation at the start of an
assessment. The PT-TLS Initiator MUST send a Version Request message
as its first PT-TLS message and MUST NOT send any other PT-TLS
messages on this connection until it receives a Version Response
message or an Error message. The PT-TLS Responder MUST complete the
version negotiation (or cause an error) prior to sending or accepting
reception of any additional messages. After the successful
Sangster et al. Expires October 25, 2012 [Page 19]
Internet-Draft PT-TLS April 25, 2012
completion of the version negotiation, both the Posture Transport
Client and Posture Transport Server MUST only send messages compliant
with the negotiated protocol version. Subsequent assessments on the
same session MUST use the negotiated version number and therefore
MUST NOT send additional version negotiation messages.
3.7.1. Version Request Message
This message is sent by a PT-TLS Initiator as the first PT-TLS
message in a PT-TLS session. This message discloses the sender's
supported versions of the PT-TLS protocol. To ensure compatibility,
this message MUST always be sent using version 1 of the PT-TLS
protocol. Recipients of this message MUST respond with a Version
Response, or a PT-TLS Error message (Version Not Supported or Invalid
Message). The following diagram shows the format of the Version
Request Message:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Min Vers | Max Vers | Pref Vers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Min Vers
This field contains the minimum version of the PT-TLS
protocol supported by the sender. This field MUST be set to
1 indicating support for the first version of PT-TLS.
However, future versions of this specification will probably
remove this requirement so PT-TLS Responders MUST be
prepared to receive other values.
Max Vers
This field contains the maximum version of the PT-TLS
protocol supported by the sender. This field MUST be set to
1 indicating support for the first version of PT-TLS.
However, future versions of this specification will probably
remove this requirement so PT-TLS Responders MUST be
prepared to receive other values.
Pref Vers
Sangster et al. Expires October 25, 2012 [Page 20]
Internet-Draft PT-TLS April 25, 2012
This field contains the sender's preferred version of the
PT-TLS protocol. This is a hint to the recipient that the
sender would like this version selected if supported. The
value of this field MUST fall within the range of Min Vers
to Max Vers. This field MUST be set to 1 indicating support
for the first version of PT-TLS. However, future versions
of this specification will probably remove this requirement
so PT-TLS Responders MUST be prepared to receive other
values.
3.7.2. Version Response Message
This message is sent in response to receiving a Version Request
Message at the start of a new assessment session. If a recipient
receives a Version Request after a successful version negotiation has
occurred on the session, the recipient SHOULD send an Invalid Message
error code in a PT-TLS Error message and have TLS close the session.
This message MUST be sent using the syntax, semantics, and
requirements of the protocol version specified in this message.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Version
This field contains the version selected by the sender of
this message. The version selected MUST be within the Min
Vers to Max Vers inclusive range sent in the Version Request
Message. If a PT-TLS Initiator receives a message with an
invalid Version selected, the PT-TLS Initiator MUST respond
with a Version Not Supported PT-TLS error message.
3.8. Client Authentication using SASL
This section includes a description of the message format and
semantics necessary to perform client authentication
(authentication of the NEA Client) over PT-TLS. Client
authentication could be necessary if the NEA Server requires
such an authentication and it was not performed during the TLS
Sangster et al. Expires October 25, 2012 [Page 21]
Internet-Draft PT-TLS April 25, 2012
handshake. The general model used for performing an
authentication of the client using PT-TLS messages is to
integrate the Simple Authentication and Security Layer (SASL)
[RFC4422] framework. SASL provides a number of standards-
based authentication mechanisms capable of authenticating the
NEA Client using a variety of base technologies.
Client authentication may occur during the TLS handshake using
TLS defined authentication techniques. Because this client
authentication is optional, the NEA Server's policy may require
the client to be authenticated by PT-TLS before performing the
assessment. Similarly, the NEA Server may require a PT-TLS
authentication even if the NEA Client was authenticated during
the TLS handshake (e.g. to allow a user authentication after a
system level authentication occurred during the TLS handshake).
The decision of whether a SASL client authentication is to
occur is left to the NEA Server's policy.
As discussed in section 3.1.1, it is possible that the NEA
Server may initiate the TLS session to the NEA Client, thus
causing it to fill the role of TLS Client during the TLS
handshake. Because the NEA Server is required to possess an
X.509 certificate for when it is acting as the TLS Server role
(normal case), PT-TLS requires that the NEA Server MUST use its
X.509 certificate for TLS client authentication during the TLS
handshake to authenticate itself even when it is acting as the
TLS Client. In this case, the NEA Client and NEA Server will
authenticate using certificates during the TLS handshake, so
the PT-TLS SASL client authentication might not be required
unless NEA Server policy required an additional authentication
of the NEA Client. Therefore, the normal usage for the SASL
messages is when the NEA Client acted as the TLS client and did
not authenticate during the TLS handshake.
3.8.1. SASL Entity Authentication Requirements
Implementations compliant with the PT-TLS specification MUST
implement the SASL authentication messages described in this
section. In order to ensure interoperability, all PT-TLS
implementations compliant with this specification MUST at least
support the PLAIN SASL mechanism [RFC4616]. Similarly,
implementations MUST provide the EXTERNAL SASL mechanism if
both parties are authenticated during the TLS establishment.
In order to be able to take advantage of other strong, widely
deployed authentication technologies such as Kerberos and
Sangster et al. Expires October 25, 2012 [Page 22]
Internet-Draft PT-TLS April 25, 2012
support for channel bindings, implementations MAY include
support for GS2 (second GSS-API bridge for SASL) [RFC5801].
GS2 includes negotiable support for channel binding for use
with SASL (see section 5 of RFC 5801).
3.8.2. SASL in PT-TLS Overview
Mechanism negotiation is initiated by the NEA Server sending the SASL
Mechanisms TLV to the NEA Client to indicate the zero or more SASL
mechanisms the NEA Server's policy is willing to use with the NEA
Client. The NEA Client selects one SASL mechanism from the list and
sends a SASL Mechanism Selection TLV completing the negotiation.
Subsequent challenges and responses are carried within the SASL
Authentication Data TLV carrying the authentication data for the
selected mechanism. The authentication outcome is communicated in a
SASL Result TLV containing a status code. If additional
authentications are required, the NEA Server could trigger the next
authentication by sending another SASL Mechanisms TLV after sending
the SASL Result TLV for the current authentication mechanism.
3.8.3. SASL Authentication Flow
The SASL client authentication starts when the NEA Server
enters the PT-TLS Negotiation phase and its policy indicates
that an authentication of the NEA Client is necessary but was
not performed during the TLS handshake protocol. The NEA
Server is responsible for triggering the client authentication
by sending the SASL Mechanisms TLV to the NEA Client listing
the set of SASL mechanisms the server is willing to use based
upon its policy.
The NEA Client selects a SASL mechanism from the list proposed
by the NEA Server or sends a PT-TLS Invalid message error code
indicating it is unable or unwilling to perform any of the
mechanisms that were offered. If the NEA Server receives a
SASL Mechanism Selection TLV that contains an unacceptable SASL
mechanism, the NEA Server would respond with a SASL Mechanism
Error in a PT-TLS Error TLV.
In situations where the NEA Server does not require a client
authentication (either authentication isn't necessary or was
performed during the TLS Setup phase), the NEA Server MUST send
a SASL Mechanisms TLV with no mechanisms included (only the PT-
TLS header) indicating the connection should transition to the
PT-TLS Data Transport phase. The same mechanism is employed to
indicate that a SASL authentication already performed in this
session is adequate to permit transition to the PT-TLS Data
Sangster et al. Expires October 25, 2012 [Page 23]
Internet-Draft PT-TLS April 25, 2012
Transport phase. So the NEA Server MUST always send a SASL
Mechanisms TLV with no mechanisms as the last message in the
PT-TLS Negotiation phase and the NEA Client MUST NOT transition
to the PT-TLS Data Transport phase until it receives such a
message.
If the NEA Server receives a NEA assessment message before the
completion of the client authentication, the NEA Server MUST
send an Authentication Required PT-TLS Error indicating to the
NEA Client that an authentication exchange is required prior to
entering the PT-TLS Data Transport phase.
3.8.4. Aborting SASL Authentication
The NEA Server may abort the authentication exchange by sending the
SASL Result TLV with a status code of ABORT. The NEA Client may
abort the authentication exchange by sending a PT-TLS Error message
with an Error Code of SASL Mechanism Error.
3.8.5. Linkages to SASL Framework
3.8.5.1. SASL Service Name
The service name for PT-TLS is "nea-pt-tls".
3.8.5.2. SASL Authorization Identity
The PT-TLS protocol does not make use of a SASL authorization
identity string as described in RFC4422.
3.8.5.3. SASL Security Layer
The NEA PT-TLS protocol always runs under the protection of TLS.
SASL security layers are not used and thus MUST be negotiated off
during SASL authentication.
3.8.5.4. Multiple Authentications
Only one SASL mechanism authentication may be in progress at any one
time. Once a SASL mechanism completes (successfully or
unsuccessfully) the NEA Server may trigger an additional
authentication by sending a SASL Mechanisms TLV.
3.8.6. SASL Channel Bindings
SASL channel bindings are used to bind the SASL authentication to the
outer TLS tunnel to ensure that the authenticating endpoints are the
Sangster et al. Expires October 25, 2012 [Page 24]
Internet-Draft PT-TLS April 25, 2012
same as the TLS endpoints. For SASL mechanisms that support channel
bindings the TLS-unique value defined in RFC 5929 is carried by the
SASL Mechanism. For most mechanisms this means including the tls-
unique value with the appropriate prefix defined in RFC 5929 in the
application data portion of the SASL Mechanism channel binding data.
If the validation of the channel-binding fails then the connection
MUST be aborted.
3.8.7. SASL Mechanisms
This TLV is sent by the NEA Server to indicate the list of SASL
mechanisms that it is willing and able to use to authenticate the NEA
Client. Each mechanism name consists of a length followed by a
name. The total length of the list is determined by the TLV Length
field.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
Rsvd (Reserved)
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Mech Len (Mechanism Name Length)
The length of the Mechanism-Name field in octets.
Mechanism Name
SASL mechanism name adhering to the rules defined in
RFC4422.
3.8.8. SASL Mechanism Selection
This TLV is sent by the NEA Client in order to select a SASL
mechanism for use on this session.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sangster et al. Expires October 25, 2012 [Page 25]
Internet-Draft PT-TLS April 25, 2012
| Rsvd| Mech Len| Mechanism Name (1-20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Initial Mechanism Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd (Reserved)
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Mech Len (Mechanism Name Length)
The length of the Mechanism-Name field in octets.
Mechanism Name
SASL mechanism name adhering to the rules defined in
RFC4422.
Optional Initial Mechanism Response
Initial set of authentication information required from the
NEA Client to kick start the authentication. This data is
optional and if not provided would be solicited by the NEA
Server in the first SASL Authentication Data TLV request.
3.8.9. SASL Authentication Data
This TLV carries an opaque (to PT-TLS) blob of octets being exchanged
between the NEA Client and the NEA Server. This TLV facilitates
their communications without interpreting any of the bytes. The SASL
Authentication Data TLV MUST NOT be sent until a SASL mechanism has
been established for a session. The SASL Authentication Data TLV
associated with the current authentication mechanism MUST NOT be sent
after a SASL Result is sent with a Successful status. Additional
SASL Authentication Data TLVs would be sent if the PT-TLS Initiator
and Responder desire a subsequent SASL authentication to occur but
only after another SASL mechanism selection exchange occurs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SASL Mechanism Data (Variable Length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sangster et al. Expires October 25, 2012 [Page 26]
Internet-Draft PT-TLS April 25, 2012
SASL Mechanism Data
Opaque, variable length set of bytes exchanged between the
PT-TLS Initiator's SASL mechanism and its peer PT-TLS
Responder's SASL mechanism. These bytes MUST NOT be
interpreted by the PT-TLS layer.
3.8.10. SASL Result
This TLV is sent by the NEA Server at the conclusion of the SASL
exchange to indicate the authentication result. Upon reception of a
SASL Result TLV indicating an Abort, the NEA Client MUST terminate
the current authentication conversation. The recipient may retry the
authentication in the event of an authentication failure. Similarly,
the NEA Server may request additional SASL authentication(s) be
performed after the completion of a SASL mechanism by sending another
SASL Mechanisms TLV including any mechanisms dictated by its policy.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Optional Result Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . . . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code
This field contains the result of the SASL authentication
exchange.
Value (Name) Definition
------------ ----------
0 (Success) SASL authentication was successful and
identity was confirmed.
1 (Failure) SASL authentication failed. This
might be caused by the client
providing an invalid user identity
and/or credential pair. Note that
this is not a mechanism failure to
process the authentication as reported
by the Mechanism Failure code.
2 (Abort) SASL authentication exchange was
aborted by the sender
Sangster et al. Expires October 25, 2012 [Page 27]
Internet-Draft PT-TLS April 25, 2012
3 (Mechanism Failure) SASL "mechanism failure" during the
processing of the client's
authentication (e.g. not related to
the user's input).
Optional Result Data
This field contains a variable length set of additional data
for a successful result. This field MUST be zero length
unless the NEA Server is returning a Result Code of Success
and has more data to return. For more information on the
additional data with success in SASL, see RFC 4422.
3.9. Error Message
This section describes the format and contents of the PT-TLS Error
Message sent by the NEA Client or NEA Server when it detects a PT-TLS
level protocol error. Each error message contains an error code
indicating the error that occurred, followed by a copy of the message
that caused the error.
When a PT-TLS error is received, the recipient MUST NOT respond with
a PT-TLS error because this could result in an infinite loop of error
messages being sent. Instead, the recipient MAY log the error,
modify its behavior to avoid future errors, ignore the error,
terminate the assessment, or take other action as appropriate (as
long as it is consistent with the requirements of this
specification).
The Message Value portion of a PT-TLS Error Message contains the
following information:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Original Message (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . . . . |
Reserved
Reserved for future use. This field MUST be set to 0 on
transmission and ignored upon reception.
Sangster et al. Expires October 25, 2012 [Page 28]
Internet-Draft PT-TLS April 25, 2012
Error Code Vendor ID
This field contains the IANA assigned SMI Private Enterprise
Number for the vendor whose Error Code name space is being
used in the message. For IETF standard Error Code values
this field MUST be set to zero (0). For other vendor-
defined Error Code name spaces this field MUST be set to the
SMI Private Enterprise Number of the vendor.
Error Code
This field contains the error code. This error code exists
within the scope of Error Code Vendor ID in this message.
Posture Transport Clients and Posture Transport Servers MUST
NOT require support for particular vendor-specific PT-TLS
Error Codes and MUST interoperate with other parties despite
any differences in the set of vendor-specific PT-TLS Error
Codes supported (although they MAY permit administrators to
configure them to require support for specific PT-TLS error
codes).
When the Error Code Vendor ID is set to the IETF Private
Enterprise Number, the following table lists the supported
IETF standard numeric error codes:
Value (Name) Definition
------------ ----------
0 (Reserved) Reserved value indicates that the PT-
TLS Error Message SHOULD be ignored by
all recipients. This MAY be used for
debugging purposes to allow a sender
to see a copy of the message that was
received while a receiver is operating
on its contents.
1 (Malformed Message) PT-TLS message unrecognized or
unsupported. This error code SHOULD
be sent when the basic message content
sanity test fails. The sender of this
error code MUST consider it a fatal
error and abort the assessment.
2 (Version Not Supported) This error SHOULD be sent when a PT-
TLS Responder receives a PT-TLS
Version Request message containing a
range of version numbers that doesn't
Sangster et al. Expires October 25, 2012 [Page 29]
Internet-Draft PT-TLS April 25, 2012
include any version numbers that the
recipient is willing and able to
support on the session. All PT-TLS
messages carrying the Version Not
Supported error code MUST use a
Version number of 1. All parties that
receive or send PT-TLS messages MUST
be able to properly process an error
message that meets this description,
even if they cannot process any other
aspect of PT-TLS version 1. The
sender and receiver of this error code
MUST consider this a fatal error and
close the TLS session after sending or
receiving this PT-TLS message.
3 (Type Not Supported) PT-TLS message type unknown or not
supported. When a recipient receives
a PT-TLS message type that it does not
support, it MUST send back this error,
ignore the message and proceed. For
example, this could occur if the
sender used a Vendor ID for the
Message Type that is not supported by
the recipient. This error message
does not indicate a fatal error has
occurred, so the assessment is allowed
to continue.
4 (Failed Authentication) The authentication of the identity of
the client failed. This could occur
if the SASL mechanism was unable to
authenticate the claimed identity of
the PT-TLS Initiator. This error
message does not indicate a fatal
error has occurred, so the
authentication is allowed to be re-
started.
5 (Invalid Message) PT-TLS message received was invalid
based on the protocol state. For
example, this error would be sent if a
recipient receives a message
associated with the PT-TLS Negotiation
Phase (such as Version messages) after
the protocol has reached the PT-TLS
Data Transport Phase. The sender and
Sangster et al. Expires October 25, 2012 [Page 30]
Internet-Draft PT-TLS April 25, 2012
receiver of this error code MUST
consider it a fatal error and close
the TLS session after sending or
receiving this PT-TLS message.
6 (SASL Mechanism Error) A fatal error occurred while trying to
perform the client authentication.
For example, the NEA Client is unable
to support any of the offered SASL
mechanisms. The sender and receiver
of this error code MUST consider it a
fatal error and close the TLS session
after sending or receiving this PT-TLS
message.
7 (Authentication Needed) The PT-TLS Responder has received a
NEA assessment message before the
completion of the client
authentication. This could occur if
the NEA Client initiated the PT-TLS
session and then started sending PB
messages before a required (by NEA
Server policy) client authentication
was performed. When the PT-TLS
Initiator (typically NEA Client)
receives this error, it should
initiate an client authentication as
discussed in 3.8.3.
Copy of Original Message
This variable length value MUST contain a copy (up to 1024
bytes) of the original PT-TLS message that caused the error.
If the original message is longer than 1024 bytes, only the
initial 1024 bytes will be included in this field. This
field is included so the error recipient can determine which
message sent caused the error. In particular, the recipient
can use the Message Identifier field from the Copy of
Original Message to determine which message caused the
error.
4. Security Considerations
This section discusses the major threats potentially faced by each
binding of the PT protocol and countermeasures provided by the PT-TLS
protocol.
Sangster et al. Expires October 25, 2012 [Page 31]
Internet-Draft PT-TLS April 25, 2012
4.1. Trust Relationships
In order to understand where security countermeasures are necessary,
this section starts with a discussion of where the NEA architecture
envisions some trust relationships between the processing elements of
the PT-TLS protocol. The following sub-sections discuss the trust
properties associated with each portion of the NEA reference model
directly involved with the processing of the PT-TLS protocol.
4.1.1. Posture Transport Client
The Posture Transport Client is trusted by the Posture Broker Client
to:
o Not observe, fabricate or alter the contents of the PB-TNC batches
received from the network
o Not observe, fabricate or alter the PB-TNC batches passed down
from the Posture Broker Client for transmission on the network
o Transmit on the network any PB-TNC batches passed down from the
Posture Broker Client
o Deliver properly security protected messages received from the
network that are destined for the Posture Broker Client
o Provide configured security protections (e.g. authentication,
integrity and confidentiality) for the Posture Broker Client's PB-
TNC batches sent on the network
o Expose the authenticated identity of the Posture Transport Server
only to the PB-TNC layer within the NEA Client
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network
o Provide a secure, reliable, in order delivery, full duplex
transport for the Posture Broker Client's messages
The Posture Transport Client is trusted by the Posture Transport
Server to:
o Not send malicious traffic intending to harm (e.g. denial of
service) the Posture Transport Server
o Not send malformed messages (e.g. messages lacking PT-TLS header)
Sangster et al. Expires October 25, 2012 [Page 32]
Internet-Draft PT-TLS April 25, 2012
o Not send invalid or incorrect responses to messages (e.g. errors
when no error is warranted)
o Not ignore or drop messages causing issues for the protocol
processing (e.g. dropping PT-TLS SASL Authentication Data
messages)
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network
4.1.2. Posture Transport Server
The Posture Transport Server is trusted by the Posture Broker Server
to:
o Not observe, fabricate or alter the contents of the PB-TNC batches
received from the network
o Not observe, fabricate or alter the PB-TNC batches passed down
from the Posture Broker Server for transmission on the network
o Transmit on the network any PB-TNC batches passed down from the
Posture Broker Server
o Deliver properly security protected messages received from the
network that are destined for the Posture Broker Server
o Provide configured security protections (e.g. authentication,
integrity and confidentiality) for the Posture Broker Server's
messages sent on the network
o Expose the authenticated identity of the Posture Transport Client
only to the PB-TNC layer within the NEA Server
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network
o Provide a secure, reliable, in order delivery, full duplex
transport for the Posture Broker Server's messages
The Posture Transport Server is trusted by the Posture Transport
Client to:
o Not send malicious traffic intending to harm (e.g. denial of
service) the Posture Transport Server
Sangster et al. Expires October 25, 2012 [Page 33]
Internet-Draft PT-TLS April 25, 2012
o Not send malformed messages (e.g. messages lacking PT-TLS header)
o Not send invalid or incorrect responses to messages (e.g. errors
when no error is warranted)
o Not ignore or drop messages causing issues for the protocol
processing (e.g. dropping PT-TLS SASL Result messages)
o Verify the security protections placed upon messages received from
the network to ensure the messages are authentic and protected
from attacks on the network
4.2. Security Threats and Countermeasures
Beyond the trusted relationships assumed in section 4.1 the PT-TLS
protocol faces a number of potential security attacks that could
require security countermeasures.
Generally, the PT-TLS protocol is responsible for offering strong
security protections for all of the NEA protocols so any threats to
its ability to protect NEA protocol messages could be very damaging
to deployments. Once the message is delivered to the Posture Broker
Client or Posture Broker Server, the posture brokers are trusted to
properly and safely process the messages.
4.2.1. Message Theft
When PT-TLS messages are sent over unprotected network links or
spanning local software stacks that are not trusted, the contents of
the messages may be subject to information theft by an intermediary
party. This theft could result in information being recorded for
future use or analysis by the adversary. Messages observed by
eavesdroppers could contain information that exposes potential
weaknesses in the security of the endpoint, or system fingerprinting
information easing the ability of the attacker to employ attacks more
likely to be successful against the endpoint. The eavesdropper might
also learn information about the endpoint or network policies that
either singularly or collectively is considered sensitive
information. For example, if PT-TLS does not provide confidentiality
protection, an adversary could observe the PA-TNC attributes included
in the PT-TLS message and determine that the endpoint is lacking
patches, or particular sub-networks have more lenient policies.
In order to protect against NEA assessment message theft, the PT-TLS
protocol provides strong cryptographic authentication, integrity and
confidentiality protection. Deployers are strongly encouraged to
employ best practice of the day TLS ciphers to ensure the information
Sangster et al. Expires October 25, 2012 [Page 34]
Internet-Draft PT-TLS April 25, 2012
remains safe despite advances in technology and discovered cipher
weaknesses. The use of bi-directional authentication of the
assessment transport session ensures that only properly authenticated
and authorized parties may be involved in an assessment dialog. The
PT-TLS protocol also provides strong cryptography for all of the PB-
TNC and PA-TNC protocol messages traveling over the network allowing
the message contents to be hidden from potential theft by the
adversary even if the attacker is able to observe the encrypted PT-
TLS session.
4.2.2. Message Fabrication
Attackers on the network or present within the NEA system could
introduce fabricated PT-TLS messages intending to trick or create a
denial of service against aspects of an assessment. For example, an
adversary could attempt to insert into the message exchange fake PT-
TLS error codes in order to disrupt communications.
The PT-TLS protocol provides strong security protections for the
complete message exchange over the network. These security
protections prevent an intermediary from being able to insert fake
messages into the assessment. In particular, the TLS's protocol use
of hashing algorithms provides strong integrity protections that
allow for detection of any changes in the content of the message
stream. Additionally, adversaries are unable to observe the PT-TLS
protocol exchanges because they are encrypted by the TLS ciphers, so
would have difficulty in determining where to insert the falsified
message, since the attacker is unable to determine where the message
boundaries exist. Even a successful message insertion did occur; the
recipient would be able to detect it due to the TLS cipher suite's
integrity checking failing.
4.2.3. Message Modification
This attack could allow an active attacker capable of intercepting a
message to modify a PT-TLS message or transported PA-TNC attribute to
a desired value to ease the compromise of an endpoint. Without the
ability for message recipients to detect whether a received message
contains the same content as what was originally sent, active
attackers can stealthily modify the attribute exchange.
The PT-TLS protocol leverages the TLS protocol to provide strong
authentication and integrity protections as a countermeasure to this
theat. The bi-directional authentication prevents the attacker from
acting as an active man-in-the-middle to the protocol that could be
used to modify the message exchange. The strong integrity
protections (e.g. hashing) offered by TLS allows PT-TLS message
Sangster et al. Expires October 25, 2012 [Page 35]
Internet-Draft PT-TLS April 25, 2012
recipients to detect message alterations by other types of network
based adversaries.
4.2.4. Denial of Service
A variety of types of denial of service attacks are possible against
the PT-TLS protocol if the message exchanges are left unprotected
while traveling over the network. The Posture Transport Client and
Posture Transport Server are trusted not to participate in the denial
of service of the assessment session, leaving the threats to come
from the network.
The PT-TLS protocol provides bi-directional authentication
capabilities in order to prevent a man-in-the-middle on the network
from becoming an undetected active proxy of PT-TLS messages. Because
the PT-TLS protocol runs after the TLS handshake and thus cipher
establishment/use, all of the PT-TLC messages are protected from
undetected modification that could create a denial of service
situation. However it is possible for an adversary to alter the
message flows causing each message to be rejected by the recipient
because it fails the integrity checking.
The PT-TLS protocol operates as an application protocol on top of TLS
and thus TCP/IP protocols, so is subject to denial of service attacks
against the TLS, TCP and IP protocols.
4.2.5. NEA Asokan Attacks
As described in section 3.3 and in the NEA Asokan Attack Analysis
[ASOKAN], a sophisticated MITM attack can be mounted against NEA
systems. The attacker forwards PA-TNC messages from a healthy
machine through an unhealthy one so that the unhealthy machine can
gain network access. Section 3.3. and the NEA Asokan Attack Analysis
provide a detailed description of this attack and of the
countermeasures that can be employed against it.
Because lying endpoint attacks are much easier than Asokan attacks
and the only known effective countermeasure against lying endpoint
attacks is the use of an External Measurement Agent (EMA),
countermeasures against an Asokan attack are not necessary unless an
EMA is in use. However, PT-TLS implementers may not know whether an
EMA will be used with their implementation. Therefore, PT-TLS
implementers SHOULD support the Asokan attack countermeasures
described in section 3.3 by providing the value of the tls-unique
channel binding to higher layers in the NEA reference model: Posture
Broker Clients, Posture Broker Servers, Posture Collectors, and
Posture Validators.
Sangster et al. Expires October 25, 2012 [Page 36]
Internet-Draft PT-TLS April 25, 2012
The Asokan attack can also apply to authentication mechanisms carried
within TLS. SASL mechanisms providing channel bindings use the tls-
unique channel binding data as defined in section 3.3 to protect
against the attack.
4.2.6. Trust Anchors
The TLS protocol bases its trust decision about the signer of the
certificates received during the TLS authentication using a set of
trust anchor certificate. It is essential that these trust anchor
certificates are integrity protected from unauthorized modification.
Many common software components (e.g. browsers, operating systems,
security protocols) include a set of trust anchor certificates that
are relevant to their operation. The PT-TLS SHOULD use a PT-TLS
specific set of trust anchor certificates in order to limit what
Certificate Authorities are authorized to issue certificates for use
with NEA.
5. Privacy Considerations
The role of PT-TLS is to act as a secure transport for PB-TNC and
other higher layer protocols. As such, PT-TLS does not directly
utilize personally identifiable information (PII) except when client
authentication is enabled. When client authentication is being used,
the NEA Client will be asked to use SASL which may disclose a local
identifier (e.g. username) associated with the endpoint and an
authenticator (e.g. password) to authenticate that identity. Because
the identity and authenticator are potentially privacy sensitive
information, the NEA Client MUST offer a mechanism to restrict which
NEA Servers will be sent this information. Similarly, the NEA Client
should provide an indication to the person being identified that a
request for their identity has been made in case they choose to opt
out of the authentication to remain anonymous.
PT-TLS provides cryptographic peer authentication, message integrity
and data confidentiality protections to higher layer NEA protocols
that may exchange data potentially including PII. These security
services can be used to protect any PII involved in an assessment
from passive and active attackers on the network. Endpoints sending
potentially privacy sensitive information should ensure that the PT-
TLS security protections (TLS cipher suites) negotiated for an
assessment of the endpoint are adequate to avoid interception and
off-line attacks of any long term privacy sensitive information.
Sangster et al. Expires October 25, 2012 [Page 37]
Internet-Draft PT-TLS April 25, 2012
6. IANA Considerations
This specification requests the creation of two new IANA
registries and the assignment of a TCP port number. First, this
specification requests the IANA reserve a registered TCP port
number for use with the PT-TLS protocol upon publication of
this specification as an Internet standard RFC.
This section also defines the contents of two new IANA
registries: PT-TLS Message Types, and PT-TLS Error Codes. This
section explains how these registries work.
All of the registries defined in this document support IETF
standard values and vendor-defined values. To explain this
phenomenon, we will use the PT-TLS Message Type as an example
but the other registries work the same way.
Whenever a PT-TLS Message Type appears on a network, it is
always accompanied by an SMI Private Enterprise Number (PEN),
also known as a vendor ID. If this vendor ID is zero, the
accompanying PT-TLS Message Type is an IETF standard value
listed in the IANA registry for PT-TLS Message Types and its
meaning is defined in the specification listed for that PT-TLS
Message Type in that registry. If the vendor ID is not zero,
the meaning of the PT-TLS Message Type is defined by the vendor
identified by the vendor ID (as listed in the IANA registry for
SMI PENs). The identified vendor is encouraged but not required
to register with IANA some or all of the PT-TLS Message Types
used with their vendor ID and publish a specification for each
of these values.
This delegation of namespace is analogous to the technique used
for OIDs. It can result in interoperability problems if
vendors require support for particular vendor-specific values.
However, such behavior is explicitly prohibited by this
specification, which dictates that "Posture Transport Clients
and Posture Transport Servers MUST NOT require support for
particular vendor-specific PT-TLS Error Codes and MUST
interoperate with other parties despite any differences in the
set of vendor-specific PT-TLS Error Codes supported (although
they MAY permit administrators to configure them to require
support for specific PT-TLS error codes)." Similar requirements
are included for PT-TLS Message Types and PT-TLS Auth Types.
Sangster et al. Expires October 25, 2012 [Page 38]
Internet-Draft PT-TLS April 25, 2012
6.1. Designated Expert Guidelines
For all of the IANA registries defined by this specification,
new values are added to the registry by Expert Review with
Specification Required, using the Designated Expert process
defined in RFC 5226 [RFC5226].
This section provides guidance to designated experts so that
they may make decisions using a philosophy appropriate for
these registries.
The registries defined in this document have plenty of values.
In most cases, the IETF has approximately 2^32 values available
for it to define and each vendor has the same number of values
for its use. Because there are so many values available,
designated experts should not be terribly concerned about
exhausting the set of values.
Instead, designated experts should focus on the following
requirements. All values in these IANA registries MUST be
documented in a specification that is permanently and publicly
available. IETF standard values MUST also be useful, not
harmful to the Internet, and defined in a manner that is clear
and likely to ensure interoperability.
Designated experts should encourage vendors to avoid defining
similar but incompatible values and instead agree on a single
IETF standard value. However, it is beneficial to document
existing practice.
There are several ways to ensure that a specification is
permanently and publicly available. It may be published as an
RFC. Alternatively, it may be published in another manner that
makes it freely available to anyone. However, in this latter
case, the vendor MUST supply a copy to the IANA and authorize
the IANA to archive this copy and make it freely available to
all if at some point the document becomes no longer freely
available to all through other channels.
The following three sections provide guidance to the IANA in
creating and managing the new IANA registries defined by this
specification.
6.2. Registry for PT-TLS Message Types
The name for this registry is "PT-TLS Message Types". Each
entry in this registry should include a human-readable name, an
Sangster et al. Expires October 25, 2012 [Page 39]
Internet-Draft PT-TLS April 25, 2012
SMI Private Enterprise Number, a decimal integer value between
0 and 2^32-1, and a reference to the specification where the
contents of this message type are defined. This specification
must define the meaning of the PT-TLS message type and the
format and semantics of the PT-TLS Message Value field that
include the designated Private Enterprise Number in the PT-TLS
Message Type Vendor ID field and the designated numeric value
in the PT-TLS Message Type field.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should
become the initial entries in the registry for PT-TLS Message
Types. Additional entries to this registry are added by Expert
Review with Specification Required, following the guidelines in
section 6.1.
PEN Value Name Defining Specification
--- ----- ---- ----------------------
0 0 Experimental RFC # Assigned to this I-D
0 1 Version Request RFC # Assigned to this I-D
0 2 Version Response RFC # Assigned to this I-D
0 3 SASL Mechanisms RFC # Assigned to this I-D
0 4 SASL Mechanism Selection RFC # Assigned to this I-D
0 5 SASL Authentication Data RFC # Assigned to this I-D
0 6 SASL Result RFC # Assigned to this I-D
0 7 PB-TNC Batch RFC # Assigned to this I-D
0 8 PT-TLS Error RFC # Assigned to this I-D
0 9+ Reserved RFC # Assigned to this I-D
6.3. Registry for PT-TLS Error Codes
The name for this registry is "PT-TLS Error Codes". Each entry
in this registry should include a human-readable name, an SMI
Private Enterprise Number, a decimal integer value between 0
and 2^32-1, and a reference to the specification where this
error code is defined. This specification must define the
meaning of this error code and the format and semantics of the
Error Information field for PT-TLS messages that have a PT-TLS
Vendor ID of 0, a PT-TLS Message Type of PT-TLS Error, the
designated Private Enterprise Number in the PT-TLS Error Code
Vendor ID field, and the designated numeric value in the PT-TLS
Error Code field.
The following entries for this registry are defined in this
document. Once this document becomes an RFC, they should
become the initial entries in the registry for PT-TLS Error
Codes. Additional entries to this registry are added by Expert
Sangster et al. Expires October 25, 2012 [Page 40]
Internet-Draft PT-TLS April 25, 2012
Review with Specification Required, following the guidelines in
section 6.1.
PEN Value Name Defining Specification
--- ----- ---- ----------------------
0 0 Reserved RFC # Assigned to this I-D
0 1 Malformed Message RFC # Assigned to this I-D
0 2 Version Not Supported RFC # Assigned to this I-D
0 3 Type Not Supported RFC # Assigned to this I-D
0 4 Failed Authentication RFC # Assigned to this I-D
0 5 Invalid Message Error RFC # Assigned to this I-D
0 6 SASL Mechanism Error RFC # Assigned to this I-D
0 7 Authentication Needed RFC # Assigned to this I-D
0 8+ Reserved RFC # Assigned to this I-D
7. Acknowledgments
Thanks to the Trusted Computing Group for contributing the initial
text upon which this document was based [IFT-TLS].
The authors of this draft would also like to acknowledge the
following people who have contributed to or provided substantial
input on the preparation of this document or predecessors to it: Syam
Appala, Stuart Bailey, Lauren Giroux, Steve Hanna, Josh Howlett,
Carolin Latze, Scott Kelly, Sung Lee, Lisa Lorenzin, Ravi Sahita,
Subbu Srinivasan, Susan Thomson and Mark Townsend.
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4346] Dierks T., Rescorla E., "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[RFC4422] Melnikov A., Zeilenga K., "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4616] Zeilenga K., "The PLAIN Simple Authentication and Security
Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC5226] Narten T., Alvestrand H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008.
Sangster et al. Expires October 25, 2012 [Page 41]
Internet-Draft PT-TLS April 25, 2012
[RFC5246] Dierks T., Rescorla E., "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S., Housley,
R., Polk, W., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[RFC5746] Rescorla E., Ray M., Oskov N., "Transport Layer Security
(TLS) Renegotiation Indication Extension", RFC 5746,
February 2010.
[RFC5792] Sangster P., Narayan K., "PA-TNC: A Posture Attribute
Protocol (PA) Compatible with TNC", RFC 5792, March 2010.
[RFC5793] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", RFC 5793, March
2010.
[RFC5929] Altman, J., Williams, N., Zhu L., "Channel Bindings for
TLS", RFC 5929, July 2010.
[RFC6125] Saint-Andre, P., Hodges, J., "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6520] Segglemann, R., Tuexen, M., Williams M., "Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)
Heartbeat Extension", RFC 6520, February 2012.
8.2. Informative References
[ASOKAN] Salowey, J., Hanna, S., "NEA Asokan Attack Analysis",
draft-ietf-nea-asokan-00.txt (work in progress), April
2012.
[IFT-TLS] Trusted Computing Group, "TNC IF-T: Binding to TLS",
http://www.trustedcomputinggroup.org/files/resource_files/5
1F0757E-1D09-3519-
AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf, May 2009.
[PT-EAP] Cam-Winget, N., S., Sangster, P., "PT-EAP: Posture
Transport (PT) Protocol For EAP Tunnel Methods", draft-
ietf-nea-pt-eap-01.txt (work in progress), March 2012.
Sangster et al. Expires October 25, 2012 [Page 42]
Internet-Draft PT-TLS April 25, 2012
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[RFC5801] Josefsson, S., Williams, N., "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The GS2
Mechanism Family", RFC 5801, July 2010.
Authors' Addresses
Paul Sangster
Symantec Corporation
6825 Citrine Dr
Carlsbad, CA 92009
Email: paul_sangster@symantec.com
Nancy Cam-Winget
Cisco Systems
80 West Tasman Drive
San Jose, CA 95134
US
Email: ncamwing@cisco.com
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
US
Email: jsalowey@cisco.com
Sangster et al. Expires October 25, 2012 [Page 43]