Subject: [Nea] Operations Directorate Review of draft-ietf-nea-pt-tls-05

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 11 Jun 2012 16:19:46 +0200

Hi, 

This is an OPS-DIR review for draft-ietf-nea-pt-tls-05. Although this is
not an easy reading for a non-expert, it's a well written specification,
based upon wide field experience with proprietary protocols, and I do
not expect major obstacles in operational deployment. 

A few issues triggered by the checklist in RFC 5706: 

1.        'Does the new protocol need supporting services (e.g., DNS or
          Authentication, Authorization, and Accounting - AAA) added to
          an existing network?'

The protocol stacks atop of TLS. Section 3.4.3 (TLS requirements)
includes a SHOULD requirement for TLS 1.2, but neither here nor in other
parts of the document I could find a requirement that PT-TLS
implementations MUST support TLS 1.0 and TLS 1.1. The authors may want
to add this.

I believe that mentioning the fact that the protocol is layered atop of
TLS in the title and Abstract would make this key design issue more
clear to the readers.

2. The protocol uses the Vendor PEN, but assumes it is limited to
24-bit. 

In Section 3.5 - Message Vendor ID - .  

      Consistent with PA-TNC and PB-
      TNC, we depend on the PEN fitting in 24 bits, so if IANA were to
      register a wider PEN than that PEN could not be used with NEA.
      IETF namespace PT-TLS Message Types MUST use zero (0) in this
      field.  

However, discussions triggered by draft-liang-iana-pen-00 may end by
that document recommending that new protocols define at least 32-bit PEN
fields. Is this impossible in this case? What are the 8 bits preceding
the Message Type Vendor ID Reserved for?

3. 'Have suggestions for verifying correct operation been discussed?'

Not really. How are assessment results communicated to the operators?
Are they public? Maybe they MUST NOT be public (because of privacy
concerns for example)? The document says nothing about this. Same
question about errors, authentication failures, or other error counts.  

4. 'Has management interoperability been discussed?'

As with many other security-related protocols this document offers
little to none information about manageability, so interoperable
management does not seem to be an issue, or maybe these aspects are
discussed in another document. In any case, this could be explained in
text. 

5. Editorial observation - Readability could be improved if acronyms
like MITM (Man-in-the Middle) would be expanded at their first
occurrence. 

Regards,

Dan

---

From: Paul Sangster <[email-masked]>
Date: Wed, 13 Jun 2012 21:42:53 -0700

Thanks for the review, comments are in-lined below...

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Monday, June 11, 2012 7:20 AM
> To: Paul Sangster; [email-masked]; Joe Salowey
> Cc: [email-masked]; Stephen Farrell; [email-masked];
> [email-masked]; [email-masked]
> Subject: Operations Directorate Review of draft-ietf-nea-pt-tls-05
> 
> Hi,
> 

[PS:] This protocol certainly does need to be carried in TLS.   As you mention, its discussed in the TLS Requirements section.  The working group discussed how to word the TLS 1.1 and 1.2 requirements on numerous occasions and we settled on this approach (SHOULD for 1.2 since it's not widely deployed yet and pointing out that 1.0/1.1 are also good transports of this protocol without including a normative reference to a downgraded RFC).  This approach parallels the way some other specs are handling this tricky issues (e.g. see OAuth at http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6).

> the Message Type Vendor ID Reserved for?

[PS:] I believe we would rather stay consistent with the other protocols in the NEA stack.  There are A LOT of numbers left in the PEN space before >24 bits is required unless for some reason the IANA started doing non-linear allocations.  Changing the protocol would only fix 1/3 of the NEA stack so not really be of large benefit for interoperability and diverge from the existing NAC protocols in the field.

> question about errors, authentication failures, or other error counts.

[PS:] This protocol is just the transport for the assessment.  The assessment is the topic of PA-TNC and PB-TNC plus the NEA architecture RFCs.  For items like authentication failures those can be passed up the stack to higher layers which make the policy decisions on how/whether to proceed and in some cases can display messages to the user or operator.  These are more architectural issues for the higher layers then this simple transport protocol.

> discussed in another document. In any case, this could be explained in

[PS:] Agreed, this would be a topic for another specification since this is just a transport protocol for the higher layer protocols in NEA.  I'd expect higher level concepts like NEA policies would need a management framework and assessment statistics could be collected from the PB layer which knows more about the assessment data and results then the transport.

> like MITM (Man-in-the Middle) would be expanded at their first

[PS:] Thanks will expand the acronym on first use.  Fortunately in this case MITM is used in a reference to the NEA Asokan attack spec which defines the MITM attack in great detail so should help the interested reader.