Active and Passive Metrics and Methods (with Hybrid Types In-Between)
draft-ietf-ippm-active-passive-06

[Ballot comment]

4.3: would it be worth noting (here or elsewhere) that
this seems to be a hard thing to do with non-e2e ciphertext,
e.g. part way along a VPN path

[Ballot comment]
Jouni Korhonen performed the opsdir review

Summary: Ready with issues

Major:    None.

Minor:

* The IDnits gives a comment but the outdated reference can be corrected at any time seen appropriate.

* Line 412:  expand DSCP on the first use.

* Lines 413-414: there is no closing ")".

* Lines 491-494: I find a discussion about IPR converage in this I-D somewhat odd. Specifically because there are no hard facts i.e., "..may be covered.." Maybe it is just me and if the WG has agree to have such text there I have no problem with it.


- Jouni

[Ballot comment]
Just a nit..  Section 3. (Terms and Definitions) says that the “definitions are consistent with [I-D.zheng-ippm-framework-passive].”  Shouldn’t it be the other way around?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ippm-active-passive-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ippm-chairs@ietf.org, ippm@ietf.org, draft-ietf-ippm-active-passive@ietf.org, spencerdawkins.ietf@gmail.com, ietf@trammell.ch, "Brian Trammell"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Active and Passive Metrics and Methods (and everything in-between, or Hybrid)) to Informational RFC


The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'Active and Passive Metrics and Methods (and everything in-between, or
  Hybrid)'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2015-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo provides clear definitions for Active and Passive
  performance assessment.  The construction of Metrics and Methods can
  be described as Active or Passive.  Some methods may use a subset of
  both active and passive attributes, and we refer to these as Hybrid
  Methods.  This memo also describes multiple dimensions to help
  evaluate new methods as they emerge.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-active-passive/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ippm-active-passive/ballot/


No IPR declarations have been submitted directly on this I-D.

Internet Engineering Task Force (IETF)                          B. Kaduk
Request for Comments: 7546                                          MIT
Category: Informational                                        May 2015
ISSN: 2070-1721

    Structure of the Generic Security Service (GSS) Negotiation Loop

Abstract

  This document specifies the generic structure of the negotiation loop
  to establish a Generic Security Service (GSS) security context
  between initiator and acceptor.  The control flow of the loop is
  indicated for both parties, including error conditions, and
  indications are given for where application-specific behavior must be
  specified.

Status of This Memo

  This document is not an Internet Standards Track specification; it is
  published for informational purposes.

  This document is a product of the Internet Engineering Task Force
  (IETF).  It represents the consensus of the IETF community.  It has
  received public review and has been approved for publication by the
  Internet Engineering Steering Group (IESG).  Not all documents
  approved by the IESG are a candidate for any level of Internet
  Standard; see Section 2 of RFC 5741.

  Information about the current status of this document, any errata,
  and how to provide feedback on it may be obtained at
  http://www.rfc-editor.org/info/rfc7546.

Copyright Notice

  Copyright (c) 2015 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Kaduk                        Informational                    [Page 1]
RFC 7546          Structure of the GSS Negotiation Loop        May 2015

Table of Contents

  1. Introduction ....................................................2
  2. Application Protocol Requirements ...............................3
  3. Loop Structure ..................................................4
      3.1. Anonymous Initiators .......................................5
      3.2. GSS_Init_sec_context .......................................5
      3.3. Sending from Initiator to Acceptor .........................6
      3.4. Acceptor Sanity Checking ...................................6
      3.5. GSS_Accept_sec_context .....................................7
      3.6. Sending from Acceptor to Initiator .........................8
      3.7. Initiator Input Validation .................................9
      3.8. Continue the Loop ..........................................9
  4. After Security Context Negotiation ..............................9
      4.1. Authorization Checks ......................................10
      4.2. Using Partially Complete Security Contexts ................10
      4.3. Additional Context Tokens .................................11
  5. Sample Code ....................................................12
      5.1. GSS Application Sample Code ...............................13
  6. Security Considerations ........................................19
  7. References .....................................................20
      7.1. Normative References ......................................20
      7.2. Informative References ....................................20
  Acknowledgements ..................................................21
  Author's Address ..................................................21

1.  Introduction

  "Generic Security Service Application Program Interface Version 2,
  Update 1" [RFC2743] provides a generic interface for security
  services in the form of an abstraction layer over the underlying
  security mechanisms that an application may use.  A GSS initiator and
  acceptor exchange messages, called "tokens", until a security context
  is established.  Such a security context allows for each party to
  authenticate the other, the passing of confidential and/or integrity-
  protected messages between the initiator and acceptor, the generation
  of identical pseudorandom bit strings by both participants [RFC4401],
  and more.

  During context establishment, security context tokens are exchanged
  synchronously, one at a time; the initiator sends the first context
  token.  The number of tokens that must be exchanged between the
  initiator and acceptor in order to establish the security context is
  dependent on the underlying mechanism as well as the desired
  properties of the security context and is, in general, not known to
  the application.  Accordingly, the application's control flow must
  include a loop within which GSS security context tokens are
  exchanged; the loop terminates upon successful establishment of a

Kaduk                        Informational                    [Page 2]
RFC 7546          Structure of the GSS Negotiation Loop        May 2015

  security context or an error condition.  The GSS-API, together with
  its security mechanisms, specifies the format and encoding of the
  context tokens themselves, but the application protocol must specify
  the necessary framing for the application to determine what octet
  strings constitute GSS security context tokens and pass them into the
  GSS-API implementation as appropriate.

  The GSS-API C-bindings [RFC2744] provide some example code for such a
  negotiation loop, but this code does not specify the application's
  behavior on unexpected or error conditions.  As such, individual
  application protocol specifications have had to specify the structure
  of their GSS negotiation loops, including error handling, on a per-
  protocol basis (see [RFC4462], [RFC3645], [RFC5801], [RFC4752], and
  [RFC2203]).  This represents a substantial duplication of effort, and
  the various specifications go into different levels of detail and
  describe different possible error conditions.  Therefore, it is
  preferable to have the structure of the GSS negotiation loop,
  including error conditions and token passing, described in a single
  specification that can then be referred to from other documents in
  lieu of repeating the structure of the loop each time.  This document
  fills that role.

  The necessary requirements for correctly performing a GSS negotiation
  loop are essentially all included in [RFC2743], but they are
  scattered in many different places.  This document brings all the
  requirements together into one place for the convenience of
  implementors, even though the normative requirements remain in
  [RFC2743].  In a few places, this document notes additional behavior
  that is useful for applications but is not mandated by [RFC2743].

2.  Application Protocol Requirements

  Part of the purpose of this document is to guide the development of
  new application protocols using the GSS-API, as well as the
  development of new application software using such protocols.  The
  following list consists of features that are necessary or useful in
  such an application protocol:

  o  Protocols require a way to frame and identify security context
      negotiation tokens during the GSS negotiation loop.

  o  Error tokens should generally also get special framing, as the
      recipient may have no other way to distinguish unexpected error
      context tokens from per-message tokens.

Kaduk                        Informational                    [Page 3]
RFC 7546          Structure of the GSS Negotiation Loop        May 2015

  o  Protocols may benefit from a generic means of indicating an error,
      possibly accompanied by a descriptive string, to be used if error
      tokens are not available or not usable due to constraints of the
      application protocol.

  o  A protocol may use the negotiated GSS security context for per-
      message operations; in such cases, the protocol will need a way to
      frame and identify those per-message tokens and the nature of
      their contents.  For example, a protocol message may be
      accompanied by the output of GSS_GetMIC() over that message; the
      protocol must identify the location and size of that Message
      Identity Code (MIC) token and indicate that it is a MIC token and
      to what cleartext it corresponds.

  o  Applications are responsible for authorization of the
      authenticated peer principal names that are supplied by the GSS-
      API.  Such names are mechanism specific and may come from a
      different portion of a federated identity scheme.  Application
      protocols may need to supply additional information to support the
      authorization of access to a given resource, such as the Secure
      Shell version 2 (SSHv2) "username" parameter.

3.  Loop Structure

  The loop is begun by the appropriately named initiator, which calls
  GSS_Init_sec_context() with an empty (zero-length) input_token and a
  fixed set of input flags containing the desired attributes for the
  security context.  The initiator should not change any of the input
  parameters to GSS_Init_sec_context() between calls to it during the
  loop, with the exception of the input_token parameter, which will
  contain a message from the acceptor after the initial call, and the
  input_context_handle, which must be the result returned in the
  output_context_handle of the previous call to GSS_Init_sec_context()
  (GSS_C_NO_CONTEXT for the first call).  (In the C bindings, there is
  only a single read/modify context_handle argument, so the same
  variable should be passed for each call in the loop.)  RFC 2743 only
  requires that the claimant_cred_handle argument remain constant over
  all calls in the loop, but the other non-excepted arguments should
  also remain fixed for reliable operation.

  The following subsections will describe the various steps of the
  loop, without special consideration to whether a call to
  GSS_Init_sec_context() or GSS_Accept_sec_context() is the first such
  call in the loop.

Kaduk                        Informational                    [Page 4]
RFC 7546          Structure of the GSS Negotiation Loop        May 2015

3.1.  Anonymous Initiators

  If the initiator is requesting anonymity by setting the anon_req_flag
  input to GSS_Init_sec_context(), then on non-error returns from
  GSS_Init_sec_context() (that is, when the major status is
  GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED) the initiator must verify
  that the output value of anon_state from GSS_Init_sec_context() is
  true before sending the security context token to the acceptor.
  Failing to perform this check could cause the initiator to lose
  anonymity.

3.2.  GSS_Init_sec_context

  The initiator calls GSS_Init_sec_context() using the
  input_context_handle for the current security context being
  established and its fixed set of input parameters and the input_token
  received from the acceptor (if this is not the first iteration of the
  loop).  The presence or absence of a nonempty output_token and the
  value of the major status code are the indicators for how to proceed:

  o  If the major status code is GSS_S_COMPLETE and the output_token is
      empty, then the context negotiation is fully complete and ready
      for use by the initiator with no further actions.

  o  If the major status code is GSS_S_COMPLETE and the output_token is
      nonempty, then the initiator's portion of the security context
      negotiation is complete but the acceptor's is not.  The initiator
      must send the output_token to the acceptor so that the acceptor
      can establish its half of the security context.

  o  If the major status code is GSS_S_CONTINUE_NEEDED and the
      output_token is nonempty, the context negotiation is incomplete.
      The initiator must send the output_token to the acceptor and await
      another input_token from the acceptor.

  o  If the major status code is GSS_S_CONTINUE_NEEDED and the
      output_token is empty, the mechanism has produced an output that
      is not compliant with [RFC2743].  However, there are some known
      implementations of certain mechanisms such as NT LAN Manager
      Security Support Provider [NTLMSSP] that do produce empty context
      negotiation tokens.  For maximum interoperability, applications
      should be prepared to accept such tokens and should transmit them
      to the acceptor if they are generated.

Kaduk                        Informational                    [Page 5]
RFC 7546          Structure of the GSS Negotiation Loop        May 2015and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

One nit, caused by a space in a bracketed reference to an RFC in a diagram not
meant to be a reference.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None necessary

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document has no IANA consideration.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None.