Subject: [secdir] Secdir review of draft-ietf-calext-rscale-03

From: "Takeshi Takahashi" <[email-masked]>
Date: Sat, 14 Feb 2015 17:37:41 +0900

Hello,

I have reviewed current version of this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by
the IESG.
These comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.

[overview]
This draft provides an extension to iCalender to support use of
non-Gregorian recurrence rules.
It first elaborates the difficulties to cope with the non-Gregorian calendar
using the existing "CALSCALE" property in iCalendar.
The "RRULE" property is thus extended to include an "RSCALE" element.
The draft also explains how to handle the dates expressed by non-Gregorian
calendar.

[security consideration check]
The security consideration section says that this draft does not introduce
any additional security concerns beyond those described in RFC 5545, 5546,
and 4791.
I agree, since this draft simply added an "RSCALE" element; I do not think
it may cause any extra security concerns.

[status]
I think this draft is ready for further process.

Thank you.
Take

---

From: Tina TSOU <[email-masked]>
Date: Sun, 15 Feb 2015 13:13:23 +0000

Dear all,

* Section 3.2, page 5:
  The initiator calls GSS_Init_sec_context(), using the
  input_context_handle for the current proto-security-context and its
  fixed set of input parameters, and the input_token received from the
  acceptor (if not the first iteration of the loop).

Your use of proto-security-context would make it seem like this is a
parameter specified in RFC2473 but it is not. So I'd recommend to remove
the hyphens. (BTW, at times you refer to "proto-security-context" while
at others to just "security context"... why?)

* Section 3.2, Page 5:

(if not the first iteration of the loop)

Please rephrase as "(if this is not...)"

* Section 3.2, page 5:
However, there are some known
     implementations of certain mechanisms which do produce empty
     context negotiation tokens.  For maximum interoperability,
     applications should be prepa

It would be great if you could provide examples of such implementations.

* Section 3.4, page 6
It is likely appropriate
  for the acceptor to report this error condition to the acceptor via
  the application's communication channel.

It should say:
  It is likely appropriate
  for the acceptor to report this error condition to the initiator via
  the application's communication channel.

* Section 3.5, page 7:
  The GSS acceptor calls GSS_Accept_sec_context(), using the
  input_context_handle for the current proto-security-context and the
  input_token received from the initiator

Again, remove the hyphens

* Section 4.1, page 10
Additional information can be
  available in GSS-API Naming Extensions, [RFC6680].

s/can be/is/

* Section 5.1: You should clarify what's the convention for the return
codes of send_token() and receive_token(). Otherwise it's not clear
whether, when you use these functions, you're checking the return codes
correctly.

Thank you,
Tina

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Feb 2015 23:01:13 -0500 (EST)

> other last call comments.

Thank you for the review.

> at others to just "security context"... why?)

The use of "proto-" was to indicate that this was a security context which
is not fully established; that is, one for which the establishment process
is still under way.  Since this is confusing, I think I would rather
change it to "security context being established" instead of just removing
the hyphens.

> Please rephrase as "(if this is not...)"

Okay.

> It would be great if you could provide examples of such implementations.

I believe the NTLMSSP mechanism is the main example.  I am not sure what
the best reference to use for it is, though.

>   the application's communication channel.

Thank you for spotting this (Gen-ART did as well).

> Again, remove the hyphens

As above.

>   available in GSS-API Naming Extensions, [RFC6680].

I believe that "can be" is appropriate, since the naming extensions from
RFC 6680 are not universally deployed.

> whether, when you use these functions, you're checking the return codes

I think that the intent is clear from the return code checking where they
are used, but will add a comment above the implementations, "Returns 0 on
success, non-zero on failure."

Thank you,

Ben