Subject: [CDNi] non-repudiation text

From: David Mandelberg <[email-masked]>
Date: Tue, 04 Jun 2013 18:21:04 -0400

Hi,

I've attached a first draft of some text for non-repudiation. It has two
open issues that I know about:

1. I'd like to provide a sensible default for the maximum lifespan of
ephemeral keys, but I'm not sure what is reasonable in this context. On the
CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does
anybody have input about the security of 1 hour/day/month?

2. The text I wrote is not compatible with Integrity-Hash. I could update
it to work with Integrity-Hash, but I think it might be easier to just say
"Integrity-Hash and non-repudiation MUST NOT be used in the same log file"
since non-repudiation provides for integrity anyway. Thoughts?

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 5 Jun 2013 13:45:36 +0000

David and all,

Below is the text I located in RFC4949 about non-repudiation. In case you have not done it yet, can you check it out and see if we use the terminology right?

Thanks

Francois

 $ non-repudiation service
      1. (I) A security service that provide protection against false
      denial of involvement in an association (especially a
      communication association that transfers data). (See: repudiation,
      time stamp.)

      Tutorial: Two separate types of denial are possible -- an entity
      can deny that it sent a data object, or it can deny that it
      received a data object -- and, therefore, two separate types of
      non-repudiation service are possible. (See: non-repudiation with
      proof of origin, non-repudiation with proof of receipt.)

      2. (D) "Assurance [that] the sender of data is provided with proof
      of delivery and the recipient is provided with proof of the
      sender's identity, so neither can later deny having processed the
      data." [C4009]

      Deprecated Definition: IDOCs SHOULD NOT use definition 2 because
      it bundles two security services -- non-repudiation with proof of
      origin, and non-repudiation with proof of receipt -- that can be
      provided independently of each other.

      Usage: IDOCs SHOULD distinguish between the technical aspects and
      the legal aspects of a non-repudiation service:
      -  "Technical non-repudiation": Refers to the assurance a relying
         party has that if a public key is used to validate a digital
         signature, then that signature had to have been made by the
         corresponding private signature key. [SP32]
      -  "Legal non-repudiation": Refers to how well possession or
         control of the private signature key can be established. [SP32]

      Tutorial: Non-repudiation service does not prevent an entity from
      repudiating a communication. Instead, the service provides
      evidence that can be stored and later presented to a third party
      to resolve disputes that arise if and when a communication is
      repudiated by one of the entities involved.

Shirey                       Informational                    [Page 200]
RFC 4949         Internet Security Glossary, Version 2       August 2007

      Ford describes the six phases of a complete non-repudiation
      service and uses "critical action" to refer to the act of
      communication that is the subject of the service [For94, For97]:

      --------   --------   --------   --------   --------   . --------
      Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:
      Request    Generate   Transfer   Verify     Retain     . Resolve
      Service    Evidence   Evidence   Evidence   Evidence   . Dispute
      --------   --------   --------   --------   --------   . --------

      Service    Critical   Evidence   Evidence   Archive    . Evidence
      Request => Action  => Stored  => Is      => Evidence   . Is
      Is Made    Occurs     For Later  Tested     In Case    . Verified
                 and        Use |          ^      Critical   .    ^
                 Evidence       v          |      Action Is  .    |
                 Is         +-------------------+ Repudiated .    |
                 Generated  |Verifiable Evidence|------> ... . ----+
                            +-------------------+

      Phase / Explanation
      -------------------
      1. Request service: Before the critical action, the service
         requester asks, either implicitly or explicitly, to have
         evidence of the action be generated.
      2. Generate evidence: When the critical action occurs, evidence is
         generated by a process involving the potential repudiator and
         possibly also a trusted third party.
      3. Transfer evidence: The evidence is transferred to the requester
         or stored by a third party, for later use (if needed).
      4. Verify evidence: The entity that holds the evidence tests it to
         be sure that it will suffice if a dispute arises.
      5. Retain evidence: The evidence is retained for possible future
         retrieval and use.
      6. Resolve dispute: In this phase, which occurs only if the
         critical action is repudiated, the evidence is retrieved from
         storage, presented, and verified to resolve the dispute.

   $ non-repudiation with proof of origin
      (I) A security service that provides the recipient of data with
      evidence that proves the origin of the data, and thus protects the
      recipient against an attempt by the originator to falsely deny
      sending the data. (See: non-repudiation service.)

      Tutorial: This service is a strong version of data origin
      authentication service. This service can not only verify the
      identity of a system entity that is the original source of
      received data; it can also provide proof of that identity to a
      third party.

Shirey                       Informational                    [Page 201]
RFC 4949         Internet Security Glossary, Version 2       August 2007

   $ non-repudiation with proof of receipt
      (I) A security service that provides the originator of data with
      evidence that proves the data was received as addressed, and thus
      protects the originator against an attempt by the recipient to
      falsely deny receiving the data. (See: non-repudiation service.)

   $ non-volatile media
      (I) Storage media that, once written into, provide stable storage
      of information without an external power supply. (Compare:
      permanent storage, volatile media.)

On 5 Jun 2013, at 00:21, David Mandelberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/<draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt>_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 5 Jun 2013 13:51:46 +0000

and this other excerpt from RFC4949 will probably help:

"

2.4. Definition Type and Context

   Each entry is preceded by a character -- I, N, O, or D -- enclosed in
   parentheses, to indicate the type of definition (as is explained
   further in Section 3):
   -  "I" for a RECOMMENDED term or definition of Internet origin.
   -  "N" if RECOMMENDED but not of Internet origin.
   -  "O" for a term or definition that is NOT recommended for use in
      IDOCs but is something that authors of Internet documents should
      know about.
   -  "D" for a term or definition that is deprecated and SHOULD NOT be
      used in Internet documents.

"

On 5 Jun 2013, at 15:45, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

David and all,

Thanks

Francois

      Phase / Explanation
      -------------------

   $ non-volatile media

Hi,

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/<draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt>_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: David Mandelberg <[email-masked]>
Date: Wed, 05 Jun 2013 10:51:28 -0400

On Wed, 5 Jun 2013 13:45:36 +0000, "Francois Le Faucheur (flefauch)"
<[email-masked]> wrote:
> Below is the text I located in RFC4949 about non-repudiation. In case
you
> have not done it yet, can you check it out and see if we use the
> terminology right?

The only terminology I used from RFC4949 is non-repudiation with proof of
origin:

   The term "non-repudiation with proof of origin" is defined in
[RFC4949].
   For brevity, the term "non-repudiation" will be used to mean
   "non-repudiation with proof of origin" in this document.

Reading "non-repudiation service" now, I don't see anything that conflicts
with the text I wrote. I didn't explicitly name the 6 phases, but I think
they're all there. Should I update the text to explicitly map those phases
to their use in CDNI Logging?