Subject: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 02 Jan 2013 06:43:03 -0800

The IESG has received a request from the Network Endpoint Assessment WG
(nea) to consider the following document:
- 'PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods'
  <draft-ietf-nea-pt-eap-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-01-16. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

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

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/ballot/

The following IPR Declarations may be related to this I-D:

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

---

From: SM <[email-masked]>
Date: Tue, 08 Jan 2013 23:25:24 -0800

>[email-masked] mailing lists by 2013-01-16. Exceptionally, comments may be

This is a quick comment.

In Section 1:

   "The PT-EAP protocol MUST be protected by an outer
    TLS-based EAP tunnel method to ensure the exchanged messages are
    protected from a variety of threats from hostile intermediaries."

The RFC 2119 boilerplate is after that "MUST".

In Section 1.1:

   "This document does not define an architecture or reference model.
    Instead, it defines a protocol that works within the reference model
    described in the NEA Requirements specification [RFC5209]."

The reference is informative.

In Section 6:

   "PT-EAP does not directly utilize or require direct knowledge of
    any personally identifiable information (PII).  PT-EAP will
    typically be used in conjunction with other EAP methods
    that provide for the user authentication (if bi-directional
    authentication is used), so the user's credentials are not
    directly seen by the PT-EAP inner method."

Section 9 RFC 5209 mentions that:

   "However, in situations where the endpoint is owned by the user
    or where local laws protect the rights of the user even when
    using endpoints owned by another party, it is critical that the NEA
    implementation enable the user to control what endpoint information
    is shared with the network."

I didn't find any information in the draft to assess the privacy 
implications.  Are there any such implications?

Regards,
-sm

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 14 Jan 2013 20:29:51 +0000

Hi SM,

Thanks for the thorough review of the draft.  Please see comments below:

>The RFC 2119 boilerplate is after that "MUST".
[NCW] I can change it to a lower case "must", ok?

>The reference is informative.
[NCW] We can move the reference to be normative.

>implications.  Are there any such implications?
[NCW] I don't think there are specifically for PT-EAP.  The sections you
reference
Were to (in section 6) addressing the general EAP identity as PT-EAP is
really not
An "authentication" method.

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 14 Jan 2013 22:17:57 +0000

Changing our reference to RFC 5209 to be normative may cause
more problems than it solves. As RFC 3967 (BCP 97) says,

> IETF procedures generally require that a standards track RFC
> may not have a normative reference to another standards track
> document at a lower maturity level or to a non standards track
> specification (other than specifications from other standards
> bodies). For example, a standards track document may not have
> a normative reference to an informational RFC.

Generally, documents that contain use cases or architectures are
Informational. References to such documents in a standards track
document are informative because referring to the use cases is
not required in order to implement the standard.

RFC 5209 lists use cases for NEA, describes a reference model
for NEA, and includes requirements that the NEA protocols must
meet. None of the requirements in RFC 5209 are requirements on
implementations of the NEA protocols. Therefore, the PT-EAP spec
should not include a normative reference to RFC 5209. And that's
good, because RFC 5209 is an Informational RFC.

If I've missed something (e.g. a reason why the reference should
be normative), please explain it more clearly.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SM
> Sent: Monday, January 14, 2013 4:34 PM
> To: Nancy Cam-Winget (ncamwing)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture
> Transport (PT) Protocol For EAP Tunnel Methods) to Proposed Standard
> 
> Hi Nancy,
> At 12:29 14-01-2013, Nancy Cam-Winget (ncamwing) wrote:
> That's ok.
> Ok.
> If I understood the above correctly PT-EAP does not transport any
> information which could be used to identify an individual.  That's
> different from PT-EAP not being an "authenticated" method. Therefore,
> there isn't much to say in terms of privacy considerations.
> 
> I suggest not including the following then:
> 
>    "As a transport protocol, PT-EAP does not directly utilize or
>     require direct knowledge of any personally identifiable
>     information (PII)."
> 
> The draft can leverage the second paragraph of Section 6 as "privacy
> considerations" instead of making a statement about PII.  I'll copy
> this message to ietf-privacy@ to get a better opinion.
> 
> In Section 6:
> 
>    "Therefore, it is important for deployers to leverage these
>     protections in order to prevent disclosure of PII potentially
>     contained within PA-TNC or PB-TNC within the PT-EAP payload."
> 
> I suggest "information about an individual" instead of PII [1].
> 
> Regards,
> -sm
> 
> 1. I used the wording from draft-iab-privacy-considerations-06
>

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 14 Jan 2013 23:41:06 +0000

SM wrote:
> It's a matter of mentioning the down-ref in the Last Call announcement.

I understand that we COULD request approval for a downward reference.
We'd need to restart the IETF Last Call in order to do so but if that's
the right thing to do, we can do it.

I just don't see why we need a downref. Yes, you should understand the
NEA reference model while building an implementation of PT-EAP. You also
should understand the EAP architecture and PB-TNC and lots of other things.
That doesn't mean that all those things should be normative references.
RFC 5209 doesn't include ANY normative text that would affect implementers
of PT-EAP. An informative reference seems more appropriate to me. And
that's what we did for all the other NEA specs (PA-TNC, PB-TNC, and
PT-TLS). PB-TNC (RFC 5793) includes basically the same language as PT-EAP:

1.1.  Prerequisites

   This document does not define an architecture or reference model.
   Instead, it defines a protocol that works within the reference model
   described in the NEA Requirements specification [8].  The reader is
   assumed to be thoroughly familiar with that document.  No familiarity
   with TCG specifications is assumed.

Still, I know that the IETF process can be unpredictable. If we
now think that we need to have a normative reference in this spec,
we can change it and run the IETF Last Call process again, requesting
approval for a downref to RFC 5209.

What is the sense of the Working Group? Any guidance from the ADs?

Thanks,

Steve

> From: SM [mailto:[email-masked]]
> Sent: Monday, January 14, 2013 5:47 PM
> To: Stephen Hanna
> Cc: [email-masked]; Nancy Cam-Winget (ncamwing)
> Subject: RE: Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP: Posture
> Hi Stephen,
> At 14:17 14-01-2013, Stephen Hanna wrote:
> Yes.
>  From Section 1.1:
>    "The reader is assumed to be thoroughly familiar with that
>     document." (RFC 5209)
> 
> It's a matter of mentioning the down-ref in the Last Call announcement.
> 
> See above.  I flagged it as the matter may be raised as an issue.  I
> am ok with whatever the WG decides.
> 
> Regards,
> -sm
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Jan 2013 00:07:07 +0000

Hiya,

> What is the sense of the Working Group? Any guidance from the ADs?

I bet you know:-)

Ignore it and push on. If we get stuck then we go back to IETF LC
then and fix. The precedent in the WG should be enough to see it
through I'd say esp since PT-TLS is so recent (still in the RFC
editor queue) with precisely the same reference. Neither IETF
LC called out this out as a downref.

SM does have a point, but OTOH so do you, and yes the IESG is
fickle about stuff like this, and BCP97 doesn't really deal with
requirement or framework RFCs (I guess those are a subsequent
fad;-). And in this case, 5209 is requirements plus the
overview and I think you can credibly say that in reality a
coder who's gotten as far as coding up PT-EAP already does
know the overview, and the reqiurements are not relevant
for that coder, so this is a purely process problem if it
is a problem of any sort and does no harm to the Internet.

S.

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

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 15 Jan 2013 00:21:10 +0000

Stephen,

Thanks for the guidance. As you recommend, we'll proceed
without this change for now. If it becomes a problem,
we'll cycle back and do the downref thing.

Take care,

Steve

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, January 14, 2013 7:07 PM
> To: Stephen Hanna
> Cc: SM; [email-masked]
> Subject: Re: [Nea] Last Call: <draft-ietf-nea-pt-eap-06.txt> (PT-EAP:
> Posture Transport (PT) Protocol For EAP Tunnel Methods) to Proposed
> Standard
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Jan 2013 00:27:00 +0000

> we'll cycle back and do the downref thing.

Grand. SM - I can put a note on the ballot so other ADs know about it.

S

---

From: SM <[email-masked]>
Date: Mon, 14 Jan 2013 13:34:09 -0800

Hi Nancy,

That's ok.

Ok.

In Section 6:

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 14 Jan 2013 14:46:30 -0800

Hi Stephen,

Yes.

 From Section 1.1:

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 14 Jan 2013 17:11:52 -0800

Hi Stephen,
>Grand. SM - I can put a note on the ballot so other ADs know about it.

I suggest waiting for the AppsDir review.

Regards,
-sm