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

[Paul Sangster <[e-mail]>]

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

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> Sent: Monday, June 11, 2012 7:20 AM
> To: Paul Sangster; [e-mail]; Joe Salowey
> Cc: [e-mail]; Stephen Farrell; [e-mail];
> [e-mail]; [e-mail]
> Subject: Operations Directorate Review of draft-ietf-nea-pt-tls-05
> 
> 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.

[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).

> 
> 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?

[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.

> 
> 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.

[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.

> 
> 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.

[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.

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

[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.

> 
> Regards,
> 
> Dan
>