Subject: [Gen-art] Gen-ART review of draft-myers-ikev2-ocsp-03.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 19 Jul 2006 16:40:27 -0400

I am the assigned Gen-ART reviewer for draft-myers-ikev2-ocsp-03.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Summary

This draft is almost ready, but at the very least, item (5) below 
requires action. The other items are suggested editorial improvements.

Details

(1) You may be asked to spell out some of the acronyms in the Abstract. 
I'd suggest at least spelling out "CRL" and "OCSP".

(2) It looks like the Abstract evolved and pieces were tacked on over 
time. It might read more smoothly with a bit of rearrangement, like this:

"Abstract

   "When certificates are used with IKEv2, for example when using public
    key based authentication (PKI), the communicating peers need a
    mechanism to determine the revocation status of the peer's
    certificate. The use of in-band Certificate Revocation Lists (CRLs)
    is problematic due to unbounded CRL
    size.  The Online Certificate Status Protocol (OCSP) is an attractive
    alternative, since the size of an OCSP response is well-bounded and
    small.  This document defines the "OCSP Content" extension to IKEv2.
    A CERTREQ payload with "OCSP Content" identifies one or more trusted
    OCSP responders and is a request for inclusion of an OCSP response in
    the IKEv2 handshake.  A cooperative recipient of such a request
    responds with a CERT payload containing the appropriate OCSP
    response.  This content is recognizable via the same "OCSP Content"
    identifier.

    This document applies when
    OCSP is desired and security policy prevents one of the IKEv2 peers
    from accessing the relevant OCSP responder directly.  Firewalls are
    often deployed in a manner that prevents such access by IKEv2 peers
    outside of an enterprise network."

(2) It would probably be a good idea to define the terms "OCSP request", 
"OCSP response", and "OCSP responder" in the terminology section. I'm 
especially concerned that the reader be aware that the term "OCSP 
responder" does not refer to the party sending the CERT, but instead 
takes its meaning from RFC 2560.

(3) I'd suggest that you avoid the use of capitalized Request, Response, 
and Responder. RFC 2560 is inconsistent in its policy, but generally 
uses small letters. The current draft is also inconsistent, although it 
tends in the opposite direction.

(4) Sections 4.1 and 4.2 are not about the OCSP request and OCSP 
response, as the titles indicate. Instead, they are about the behaviour 
of the sender and receiver of the OCSP request, respectively. I suggest 
the two sections be entitled:
"4.1 Behaviour of the CERTREQ sender"
"4.2 Behaviour of the CERTREQ receiver"

(5) The second paragraph below the message exchange in section 5.1 is 
somewhat mysterious to an outsider. The paragraph begins by saying that 
the CERTREQ request could never have happened, even though the message 
exchange shows it. I don't understand the final sentence of that 
paragraph either. Isn't the OCSP request a set of OCSP Responder 
certificate hashes, as defined in section 3.1? If not, the section 3.1 
definition should be modified to describe the true contents in this case.

(I'm just guessing that you meant to say that an OCSP request as defined 
by RFC 2560 could not be formed by the Responder, and the way around 
that is to use the hashed content defined in section 3.1. The final 
sentence of section 5.1 hints at this. If that is really what you meant 
to say, you'll have to say it a bit more plainly.)

The phrase "(OCSP nonces notwithstanding)" doesn't fit with the 
discussion of the issue in the Security Considerations section. Perhaps 
you meant to say: "(provided that OCSP nonces are not used)". Following 
this sentence, you should add a pointer to the Security Considerations 
section, since that sheds considerable light on the situation.

Hope these comments are helpful.

Tom Taylor

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 21 Jul 2006 03:57:59 -0400

OK with me.

Michael Myers wrote:
> Tom,
> 
> Thank you very much for your review.  Please advise if actions proposed
> below are fully responsive to your concerns.
> 
> Mike
> 
> 
> (1)  Point taken.  Will amend the abstract to read:
>      "Certificate Revocation Lists (CRL)" and
>      "Online Certificate Status Protocol (OCSP)".
> 
> (2)  I prefer the current text.  I especially do
>      not want to touch the applicability statement
>      as that was hammered out via a conference call
>      and authored by Russ.  No change.
> 
> (2a) You forgot to change your numbering, hence (2a).
>      It had not occurred to me to apply the terminology
>      section in such a fashion.  I nonetheless do take
>      your point in that non-experts in this area may
>      become confused when reading RFC2560 in parallel.
>      We will define the terms you cite and normalize
>      usage of those terms throughout the draft.
> 
> (3)  I agree the capitalization practice in the
>      I-D is not useful and potentially confusing.
>      We will amend the draft accordingly.
> 
> (4)  I agree the section titles "OCSP Request" and
>      "OCSP Response" may confuse the casual reader,
>      I prefer however the following:
> 
>          4.1  Request for OCSP Support
>          4.2  Response to OCSP Request
> 
>      We will amend the draft accordingly.
> 
> (5)  Point taken regarding the motiviation of the
>      hash approach.  Your parenthetical comment is
>      indeed the editorial intent.  We will amend
>      the draft to state the issue more plainly.
> 
> (6)  I agree that your proposed text regarding
>      the OCSP nonce caveat improves the text.
>      We will amend the draft accordingly.
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, July 19, 2006 12:40 PM
> To: Michael Myers; Hannes Tschofenig; Russ Housley; [email-masked]
> Subject: Gen-ART review of draft-myers-ikev2-ocsp-03.txt
> 
>