Subject: [Nea] RFC 7171 on PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods

From: [email-masked]
Date: Wed, 7 May 2014 23:15:24 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 7171

        Title:      PT-EAP: Posture Transport (PT) Protocol 
                    for Extensible Authentication Protocol (EAP) Tunnel 
                    Methods 
        Author:     N. Cam-Winget, P. Sangster
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      19
        Characters: 45604
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-nea-pt-eap-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7171.txt

This document specifies PT-EAP, a Posture Transport (PT) protocol
based on the Extensible Authentication Protocol (EAP) and designed to
be used only inside an EAP tunnel method protected by Transport Layer
Security (TLS).  The document also describes the intended
applicability of PT-EAP.

This document is a product of the Network Endpoint Assessment Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Steve Hanna <[email-masked]>
Date: Fri, 09 May 2014 11:10:50 -0400

I'm happy to say that the nea working group has completed our last
milestone: publishing PT-EAP as a Standards Track RFC. TCG has
published a document bringing their corresponding standard
(IF-T/EAP) into alignment with the published version of PT-EAP:

http://www.trustedcomputinggroup.org/community/2014/05/complete_set_of_nac_standards_from_ietf_and_tcg

So we have achieved our goal of getting one set of standards for
posture assessment.

This WG will now be closed. The email list will stay open for
any needed discussions.

Thanks to all who have worked on the NEA protocols over the years.

Good work!

Steve Hanna

-------- Original Message --------
Subject: [Nea] RFC 7171 on PT-EAP: Posture Transport (PT) Protocol for 
Extensible Authentication Protocol (EAP) Tunnel Methods
Date: Wed,  7 May 2014 23:15:24 -0700 (PDT)
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked], [email-masked]

         RFC 7171

This document is a product of the Network Endpoint Assessment Working 
Group of the IETF.

The RFC Editor Team

_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea

---

From: TGLASSEY <[email-masked]>
Date: Fri, 09 May 2014 08:58:42 -0700

What is the status of the Cisco Patent here?

Todd

On 5/9/2014 8:10 AM, Steve Hanna wrote:
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4577 / Virus Database: 3931/7462 - Release Date: 05/08/14
>
>

-- 
-------------

Personal Email - Disclaimers Apply

---

From: Steve Hanna <[email-masked]>
Date: Fri, 09 May 2014 16:08:33 -0400

Todd,

I presume that you're referring to this IPR disclosure:

https://datatracker.ietf.org/ipr/1889/

If that's the case, you should refer to Cisco's statement
in the IPR disclosure linked to above.

Speaking only for myself and noting that I'm not a lawyer,
I don't think there's any reason to worry about that IPR.
In layman's terms, the Cisco statement says that anyone can
use their IPR to implement the spec. However, if you sue
them, they'll sue you back.

Are you planning to implement the spec or just asking?

Thanks,

Steve

---

From: Joe Klein <[email-masked]>
Date: Fri, 9 May 2014 16:40:22 -0400

Does anyone have working code for this protocol?  I would like to validate
a few assumptions.

Joe Klein
"Inveniam viam aut faciam"

---

From: Steve Hanna <[email-masked]>
Date: Fri, 09 May 2014 16:48:27 -0400

According to this web page, StrongSwan supports an earlier draft:

http://wiki.strongswan.org/issues/342

I'm sure that Andreas would love to have another independent
implementation to test against so please let him (and the nea
list) know if you do an implementation.

Thanks,

Steve

On 5/9/2014 4:40 PM, Joe Klein wrote:
> Does anyone have working code for this protocol?  I would like to
> validate a few assumptions.
>
> Joe Klein
> On Fri, May 9, 2014 at 4:08 PM, Steve Hanna <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Todd,
>
>     https://datatracker.ietf.org/__ipr/1889/
>     <https://datatracker.ietf.org/ipr/1889/>
>
>             http://www.__trustedcomputinggroup.org/__community/2014/05/complete___set_of_nac_standards_from___ietf_and_tcg
>             <http://www.trustedcomputinggroup.org/community/2014/05/complete_set_of_nac_standards_from_ietf_and_tcg>
>
>
>             <mailto:[email-masked]>
>             To: [email-masked] <mailto:[email-masked]>,
>             [email-masked] <mailto:[email-masked]>
>             CC: [email-masked]
>             <mailto:[email-masked]>, [email-masked]
>             <mailto:[email-masked]>, [email-masked]
>             <mailto:[email-masked]>
>
>                      Mailbox: [email-masked]
>             <mailto:[email-masked]>,
>             [email-masked] <mailto:[email-masked]>
>                      Pages:      19
>                      Characters: 45604
>                      URL: http://www.rfc-editor.org/rfc/__rfc7171.txt
>             <http://www.rfc-editor.org/rfc/rfc7171.txt>
>
>             http://www.ietf.org/mailman/__listinfo/ietf-announce
>             <http://www.ietf.org/mailman/listinfo/ietf-announce>
>             http://mailman.rfc-editor.org/__mailman/listinfo/rfc-dist
>             <http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist>
>
>             For searching the RFC series, see
>             http://www.rfc-editor.org/__search
>             <http://www.rfc-editor.org/search>
>             For downloading RFCs, see
>             http://www.rfc-editor.org/rfc.__html
>             <http://www.rfc-editor.org/rfc.html>
>
>             author of the RFC in question, or to
>             [email-masked]
>             <mailto:[email-masked]>. Unless
>             _________________________________________________
>             Nea mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/nea
>             <https://www.ietf.org/mailman/listinfo/nea>
>
>
>             _________________________________________________
>             Nea mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/nea
>             <https://www.ietf.org/mailman/listinfo/nea>
>
>
>             -----
>             Checked by AVG - www.avg.com <http://www.avg.com>
>     _________________________________________________
>     Nea mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/nea
>     <https://www.ietf.org/mailman/listinfo/nea>
>
>

---

From: Andreas Steffen <[email-masked]>
Date: Mon, 12 May 2014 14:55:32 +0200

Hi,

a strongSwan developers release is available which implements
the RFC 7171 PT-EAP transport protocol:

  http://download.strongswan.org/strongswan-5.2.0dr3.tar.bz2

As the outer EAP tunnel method protecting the PT-EAP protocol
EAP-TTLS is currently used because we haven't implemented
RFC 7170 TEAP yet.

An example scenario with two strongSwan IPsec Access Requestors (ARs)
connecting to a strongSwan VPN Policy Enforcement Point (PEP) via
IKEv2 which in turn has an EAP-RADIUS connection to a strongSwan
Policy Decision Point (PDP) is shown here:

http://www.strongswan.org/uml/testresults5dr/tnc/tnccs-20-pdp-eap/

The complete IETF NEA stack is used:

   - RFC 5792 PA-TNC
   - RFC 5793 PB-TNC
   - RFC 7181 PT-EAP

Alternatively the strongSwan pt-tls-client which implements the
RFC 6876 PT-TLS transport protocol can connect directly to
the strongSwan Policy Decision Point over a TLS socket:

http://www.strongswan.org/uml/testresults5dr/tnc/tnccs-20-pdp-pt-tls/

In this alternative scenario the stack is

   - RFC 5792 PA-TNC
   - RFC 5793 PB-TNC
   - RFC 6876 PT-TLS

Best regards

Andreas

On 09.05.2014 22:48, Steve Hanna wrote:
>> <mailto:[email-masked]>
>>                      Pages:      19
>>                      Characters: 45604
>>             protocol for the Internet community,and requests
>> discussion and
>>             suggestions

-- 
======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==