search

sacmwg / draft-ietf-sacm-requirements

SACM Requirements draft
1 stars 1 forks source link

5.1 Trust between Provider and Requester - Non-Repudiation #46

Closed jimsch closed 9 years ago

jimsch commented 9 years ago

Version -05

I probably need to do a more in depth read, however my first comment is that I really dislike the term "non-repudiation" There is no such thing as non-repudiation, there is only repudiation followed by an attempt to provide that you lied when you repudiated it.

When you say non-repudiation, what are you really trying to imply here?

sacm commented 9 years ago

Non-repudiation has a long history, so would tread lightly if you want to throw it out.

Often, such exercises goes full circle to the point that you end up back at the same point,

with the same thing, but a new term.

Non-repudiation usually means that an object is provided with a testable assertion object

that binds or proves that assertion through some process.

e.g., if you provide a signature on a message,

that could only be signed by the private key of the sender of the message,

then the sender cannot repudiate that they sent the message,

since the signature can be verified.

Of course, if the whole trust model is weak, then all related trust-related items can be discarded.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, May 14, 2015 1:59 PM To: sacmwg/draft-ietf-sacm-requirements Subject: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Version -05

I probably need to do a more in depth read, however my first comment is that I really dislike the term "non-repudiation" There is no such thing as non-repudiation, there is only repudiation followed by an attempt to provide that you lied when you repudiated it.

When you say non-repudiation, what are you really trying to imply here?

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46 . https://github.com/notifications/beacon/AKbE0cOxU3WD-7O6QNH8uXvtq43abOWlks5oJNnogaJpZM4EavIS.gif

jimsch commented 9 years ago

This shows a good reason why I want to kill non--repudiation. Your definition of what it means does not match at all well with the version that I was hearing back when I started. In that world a non-repudiation signature was different than a regular signature, much like your signature at the bottom of a legal document is not the same as your signature on the meeting signing sheet at a F2F meeting.

In the world of SACM, the idea that non-repudiation exists does not seem to be very viable. For the most part, an entity will be signing based on best guess data as inputs. If one is going to say that my signature on my work is only as good as the inputs to it are. What kind of non-repudiation exists? It is a best guess result that I am staking my reputation on. Origination of data along with reputation the entity seems to be better concepts to use than non-repudiation.

jimsch commented 9 years ago

Pressed the wrong button when I added the comment

sacm commented 9 years ago

I think you are conflating two aspects to this. Being able to verify that a message was not changed in transit (integrity) along with being able to verify that a message came from a known source (non-repudiation) is needed to ensure that a bad actor is not injecting bogus malicious information into a system. The concept of reliability of the source of the information is different. The former confirms that you sent it. The latter judges whether your data tends to be good. But, given the nature of the system itself, that latter may be acceptable. BTW, there is both non-repudiation of sender and of receipt. So, that can work both ways.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Sunday, May 17, 2015 1:18 PM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

This shows a good reason why I want to kill non--repudiation. Your definition of what it means does not match at all well with the version that I was hearing back when I started. In that world a non-repudiation signature was different than a regular signature, much like your signature at the bottom of a legal document is not the same as your signature on the meeting signing sheet at a F2F meeting.

In the world of SACM, the idea that non-repudiation exists does not seem to be very viable. For the most part, an entity will be signing based on best guess data as inputs. If one is going to say that my signature on my work is only as good as the inputs to it are. What kind of non-repudiation exists? It is a best guess result that I am staking my reputation on. Origination of data along with reputation the entity seems to be better concepts to use than non-repudiation.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-102824246 . https://github.com/notifications/beacon/AKbE0WCTH3pregtdHftufPUuInm8oqG3ks5oKMStgaJpZM4EavIS.gif

jimsch commented 9 years ago

What you are calling non-repudiation, I call origination. One can have a weak version of origination with a MAC, but one can never have what is call non-repudiation.

How can one have non-repudiation of receipt? The only way I can think of doing so would be for the receiver to generate a new signed message, in which case one is talking about non-repudiation of a sender again and not of receipt.

sacm commented 9 years ago

BTW, I am not debating whether such a thing is needed or not, just wanted to clarify the terms meaning based on my experience with military messaging systems.

A hash could provide integrity protection, but for some level of guarantee that a particular sender sent a message, usually a PKI private key is needed to demonstrate that only that key holder could have sent the message. Pairwise symmetric secret keys could also work, but less reliable.

Origination to me would just mean that someone sent a message, but could be anybody. But that is just devolving into semantic definitions. One could define a term to be whatever one likes, if one doesn’t like a more standard one.

Non-repudiation of receipt is done by the recipient taking a hash of the received message, signing it with the receiver’s private key and sending the Ack with the signature back. The sender can verify that signature using the cert of the receiver. It’s all about whose private key and cert are used to sign and to verify.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 18, 2015 11:54 AM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

What you are calling non-repudiation, I call origination. One can have a weak version of origination with a MAC, but one can never have what is call non-repudiation.

How can one have non-repudiation of receipt? The only way I can think of doing so would be for the receiver to generate a new signed message, in which case one is talking about non-repudiation of a sender again and not of receipt.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-103112198 . https://github.com/notifications/beacon/AKbE0bbCMTAnKkki5YcRxrG-uHI7Lsefks5oKgKFgaJpZM4EavIS.gif

ncamwing commented 9 years ago

Hi, In the considerations, I did place non-repudiation as out of scope for SACM. My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator). That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim: I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

sacm commented 9 years ago

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications.

And surely, you don’t deny that exists? (3GPP systems do that)

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer. But, to say they don’t exist denies the existence of running code systems that do this.

Now, if you are using non-repudiation to mean something other than an existing meaning, I can’t help you there.

At that point, it is Alice in Wonderland time.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Sent: Wednesday, May 20, 2015 7:37 PM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi, In the considerations, I did place non-repudiation as out of scope for SACM. My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator). That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim: I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567 . https://github.com/notifications/beacon/AKbE0Y9gpeb4O7yPz0WHk40ngIgynMQBks5oLRIVgaJpZM4EavIS.gif

sacm commented 9 years ago

Hi Mike,

We are misunderstanding each other? See below:

From: Michael Hammer michael.hammer@yaanatech.com<mailto:michael.hammer@yaanatech.com> Date: Wednesday, May 20, 2015 at 5:23 PM To: "reply@reply.github.commailto:reply@reply.github.com" reply@reply.github.com<mailto:reply@reply.github.com>, "draft-ietf-sacm-requirements@noreply.github.commailto:draft-ietf-sacm-requirements@noreply.github.com" draft-ietf-sacm-requirements@noreply.github.com<mailto:draft-ietf-sacm-requirements@noreply.github.com> Cc: "sacm@ietf.orgmailto:sacm@ietf.org" sacm@ietf.org<mailto:sacm@ietf.org> Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications. And surely, you don’t deny that exists? (3GPP systems do that) [NCW] What is equivalent to connectionless messaging?

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer. But, to say they don’t exist denies the existence of running code systems that do this. [NCW] I’m not sure what you’re referring to “they don’t exist”? My comment went to my interpretation of non-repudiation which is basically an attestation of an event that the originator can not refute. That is different than providing authenticity, e.g. Including mutual authentication at the session layer, establishing ephemeral keys and provided key’ed MAC’s that imho provide authenticity but I don’t think it provides non-repudiation.

Now, if you are using non-repudiation to mean something other than an existing meaning, I can’t help you there. At that point, it is Alice in Wonderland time.

Michael Hammer Principal Engineer michael.hammer@yaanatech.commailto:michael.hammer@yaanatech.com Mobile: +1408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.comhttp://www.yaanatech.com/

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Sent: Wednesday, May 20, 2015 7:37 PM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi, In the considerations, I did place non-repudiation as out of scope for SACM. My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator). That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim: I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

— Reply to this email directly or view it on GitHubhttps://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567.

jimsch commented 9 years ago

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them. As long as we have defined our terms we should be fine.

The terms I would recommend are: Integrity Origin of Data Confidentiality Authentication Authorization

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

sacm commented 9 years ago

Yes, I'm not perhaps being clear enough. Let me try again.

I was trying to make an analogy between:

I figured most people understand TLS mutual authentication, so

I could show the parallel to gain understanding for the messaging case.

Certificates and signing are used in both cases to "prove"

who the other party is that is sending or receiving the traffic.

My "don't exist" comment was about the fact that mutual authentication in TLS

and non-repudiation of sender and receiver exist in running systems.

You had said that non-repudiation of receipt does not exist.

I disagreed since I know of systems that do exist.

In the above case, the event that cannot be refuted is the sending of a specific message that one signed.

As you clarified that your statement applies to your interpretation of the term,

I cannot disagree with that, but that is more of a tautological argument.

Hope that helps.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: Nancy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Wednesday, May 20, 2015 11:24 PM To: Michael Hammer; reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc9592 a169ce048e5db3@reply.github.com; draft-ietf-sacm-requirements@noreply.github.com Cc: sacm@ietf.org Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi Mike,

We are misunderstanding each other? See below:

From: Michael Hammer <michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com > Date: Wednesday, May 20, 2015 at 5:23 PM To: "reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc959 2a169ce048e5db3@reply.github.com <mailto:reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf0000000111 74dc9592a169ce048e5db3@reply.github.com> " <reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc959 2a169ce048e5db3@reply.github.com <mailto:reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf0000000111 74dc9592a169ce048e5db3@reply.github.com> >, "draft-ietf-sacm-requirements@noreply.github.com mailto:draft-ietf-sacm-requirements@noreply.github.com " <draft-ietf-sacm-requirements@noreply.github.com mailto:draft-ietf-sacm-requirements@noreply.github.com > Cc: "sacm@ietf.org mailto:sacm@ietf.org " <sacm@ietf.org mailto:sacm@ietf.org > Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications.

And surely, you don't deny that exists? (3GPP systems do that)

[NCW] What is equivalent to connectionless messaging?

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer. But, to say they don't exist denies the existence of running code systems that do this.

[NCW] I'm not sure what you're referring to "they don't exist"? My comment went to my interpretation of non-repudiation which is basically an attestation of an event that the originator can not refute. That is different than providing authenticity, e.g. Including mutual authentication at the session layer, establishing ephemeral keys and provided key'ed MAC's that imho provide authenticity but I don't think it provides non-repudiation.

Now, if you are using non-repudiation to mean something other than an existing meaning, I can't help you there.

At that point, it is Alice in Wonderland time.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Sent: Wednesday, May 20, 2015 7:37 PM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi, In the considerations, I did place non-repudiation as out of scope for SACM. My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator). That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim: I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomme nt-104071567 . https://github.com/notifications/beacon/AKbE0Y9gpeb4O7yPz0WHk40ngIgynMQBks5 oLRIVgaJpZM4EavIS.gif

sacm commented 9 years ago

Sounds good.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, May 21, 2015 12:39 AM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them. As long as we have defined our terms we should be fine.

The terms I would recommend are: Integrity Origin of Data Confidentiality Authentication Authorization

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658 . https://github.com/notifications/beacon/AKbE0YTnKUWT2iUYlChZfXAnaYoogOi2ks5oLVj-gaJpZM4EavIS.gif

sacm commented 9 years ago

Hi,

I note that reliable connectionless security associations and mutual authentication are available with Datagram TLS (RFC 6347) - widely deployed - appearing soon even in cellular networks with DTLS over SMS work-in-progress.

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Thu, May 21, 2015 at 9:38 AM, Michael Hammer < michael.hammer@yaanatech.com> wrote:

Yes, I’m not perhaps being clear enough. Let me try again.

I was trying to make an analogy between:

  •    What is mutual authentication for connection-oriented? (TLS)
  •    What is mutual authentication for connectionless-oriented?

    (Messaging)

I figured most people understand TLS mutual authentication, so

I could show the parallel to gain understanding for the messaging case.

Certificates and signing are used in both cases to “prove”

who the other party is that is sending or receiving the traffic.

My “don’t exist” comment was about the fact that mutual authentication in TLS

and non-repudiation of sender and receiver exist in running systems.

You had said that non-repudiation of receipt does not exist.

I disagreed since I know of systems that do exist.

In the above case, the event that cannot be refuted is the sending of a specific message that one signed.

As you clarified that your statement applies to your interpretation of the term,

I cannot disagree with that, but that is more of a tautological argument.

Hope that helps.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

From: Nancy Cam-Winget (ncamwing) [mailto:ncamwing@cisco.com] Sent: Wednesday, May 20, 2015 11:24 PM To: Michael Hammer; reply@reply.github.com; draft-ietf-sacm-requirements@noreply.github.com Cc: sacm@ietf.org

Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi Mike,

We are misunderstanding each other? See below:

From: Michael Hammer michael.hammer@yaanatech.com Date: Wednesday, May 20, 2015 at 5:23 PM To: " reply@reply.github.com" < reply@reply.github.com>, "draft-ietf-sacm-requirements@noreply.github.com" < draft-ietf-sacm-requirements@noreply.github.com> Cc: "sacm@ietf.org" sacm@ietf.org Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications.

And surely, you don’t deny that exists? (3GPP systems do that)

[NCW] What is equivalent to connectionless messaging?

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer. But, to say they don’t exist denies the existence of running code systems that do this.

[NCW] I’m not sure what you’re referring to “they don’t exist”? My comment went to my interpretation of non-repudiation which is basically an attestation of an event that the originator can not refute. That is different than providing authenticity, e.g. Including mutual authentication at the session layer, establishing ephemeral keys and provided key’ed MAC’s that imho provide authenticity but I don’t think it provides non-repudiation.

Now, if you are using non-repudiation to mean something other than an existing meaning, I can’t help you there.

At that point, it is Alice in Wonderland time.

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com michael.hammer@yaanatech.com

Mobile: +1408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org sacm-bounces@ietf.org] On Behalf Of Nancy Sent: Wednesday, May 20, 2015 7:37 PM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi, In the considerations, I did place non-repudiation as out of scope for SACM. My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator). That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim: I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567 .

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

ncamwing commented 9 years ago

Agreed! But then, can we remove non-repudiation then? I included it because in previous discussions folks insisted it be there, but as demonstrated in this thread, there are different interpretations of what that means. The Infosec and CSIRT teams I work with do tell me of the legal implications (e.g. there’s a human aspect to it), but I do see that others believe the PKI signatures could be a form of evidentiary form to serve non-repudiation.

Nonetheless, we do need clarification for SACM’s use of the terms below….and non-repudiation?

Nancy.

From: Jim Schaad notifications@github.com<mailto:notifications@github.com> Reply-To: sacmwg/draft-ietf-sacm-requirements reply@reply.github.com<mailto:reply@reply.github.com> Date: Wednesday, May 20, 2015 at 9:39 PM To: sacmwg/draft-ietf-sacm-requirements draft-ietf-sacm-requirements@noreply.github.com<mailto:draft-ietf-sacm-requirements@noreply.github.com> Cc: "ncamwing@cisco.commailto:ncamwing@cisco.com" ncamwing@cisco.com<mailto:ncamwing@cisco.com> Subject: Re: [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them. As long as we have defined our terms we should be fine.

The terms I would recommend are: Integrity Origin of Data Confidentiality Authentication Authorization

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

— Reply to this email directly or view it on GitHubhttps://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658.

sacm commented 9 years ago

If those guys are lawyers, perhaps they could

come up with a “legal disclaimer” information element. :)

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com mailto:michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

http://www.yaanatech.com/ www.yaanatech.com

From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Nancy Sent: Friday, May 22, 2015 1:42 AM To: sacmwg/draft-ietf-sacm-requirements Cc: sacm Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Agreed! But then, can we remove non-repudiation then? I included it because in previous discussions folks insisted it be there, but as demonstrated in this thread, there are different interpretations of what that means. The Infosec and CSIRT teams I work with do tell me of the legal implications (e.g. there’s a human aspect to it), but I do see that others believe the PKI signatures could be a form of evidentiary form to serve non-repudiation.

Nonetheless, we do need clarification for SACM’s use of the terms below….and non-repudiation?

Nancy.

From: Jim Schaad <notifications@github.com mailto:notifications@github.com%3cmailto:notifications@github.com mailto:notifications@github.com> Reply-To: sacmwg/draft-ietf-sacm-requirements <reply@reply.github.com mailto:reply@reply.github.com%3cmailto:reply@reply.github.com mailto:reply@reply.github.com> Date: Wednesday, May 20, 2015 at 9:39 PM To: sacmwg/draft-ietf-sacm-requirements <draft-ietf-sacm-requirements@noreply.github.com mailto:draft-ietf-sacm-requirements@noreply.github.com%3cmailto:draft-ietf-sacm-requirements@noreply.github.com mailto:draft-ietf-sacm-requirements@noreply.github.com> Cc: "ncamwing@cisco.com mailto:ncamwing@cisco.com%3cmailto:ncamwing@cisco.com%3e mailto:ncamwing@cisco.com" <ncamwing@cisco.com mailto:ncamwing@cisco.com%3cmailto:ncamwing@cisco.com mailto:ncamwing@cisco.com> Subject: Re: [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them. As long as we have defined our terms we should be fine.

The terms I would recommend are: Integrity Origin of Data Confidentiality Authentication Authorization

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

— Reply to this email directly or view it on GitHubhttps://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104518806 . https://github.com/notifications/beacon/AKbE0XquzXvdstVOdkCSbn3y4CBzcMT3ks5oLrk5gaJpZM4EavIS.gif

sacm commented 9 years ago

Sent from my iPhone

On May 21, 2015, at 12:39 AM, Jim Schaad notifications@github.com wrote:

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them. As long as we have defined our terms we should be fine.

The terms I would recommend are: Integrity Origin of Data Confidentiality Authentication Authorization

I agree and having origin of data is achievable as opposed to non-repudiation.

Thanks, Kathleen

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

— Reply to this email directly or view it on GitHub.

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

llorenzin commented 9 years ago

Discussed at 6/29 virtual interim, done in -07