Subject: [Ietf-krb-wg] anonymityh ID comments VI

From: Larry Zhu <[email-masked]>
Date: Thu, 14 Aug 2008 12:25:02 -0700

* A027 Apr 30 Phillip Hallam-Baker <pbaker at verisign.com> (for secdir)
  > Clarification, although the draft mentions traffic analysis, this is a
  > somewhat broad term and the context seems to imply an interception
  > attack by a third party rather than call out the fact that a service
  > that is authenticated by this mechanism may be able to infer the
  > identity of the party by examining and linking quasi-static protocol
  > information such as the IP address from which a request is received.
  >
  > This is a pervasive problem in privacy protocols. Preventing a party
  > from obtaining irrefutable evidence that a particular party was engaged
  > in a particular transaction is rather easier than preventing a party
  > from being able to infer such involvement with a significant degree of
  > probability.

  @ This specific text in security considerations talks about the former
  @ (passive eavesdropping).
  [[ I believe Phillip's point was that the security considerations
  [[ SHOULD Call out the fact that a service that is authenticated by
  [[ this mechanism may be able to infer the identity of the party by
  [[ examining and linking quasi-static protocol information such as
  [[ the IP address from which a request is received.

Done. Phillip's text will be included in -08.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:11:19 -0400

--On Thursday, August 14, 2008 12:25:02 PM -0700 Larry Zhu 
<[email-masked]> wrote:

>   > from obtaining irrefutable evidence that a particular party was
> engaged   > in a particular transaction is rather easier than preventing
> a party   > from being able to infer such involvement with a significant
> degree of   > probability.
>

Phillip didn't provide any text.  What you appear to have done is taken 
part of his comment verbatim and appended it to an unrelated paragraph. 
You've dropped phrases like "this mechanism" and "the party" into the 
document out of context and with no antecedents, so that it is difficult to 
tell what it means.  While both Phillip's comments and mine are IETF 
Contributions and thus fair game for you to use in an I-D, a simple 
cut-and-paste will not do it here.  You need to provide enough context and 
be at least somewhat consistent with the rest of the document (for 
example(*), instead of "a service that is authenticated by this mechanism" 
you could say "a service to which an anonymous ticket is presented", and 
instead of "the party" you could say "the client").

-- Jeff

(*) read "for example" as "this is not an exhaustive list or a suggested 
edit; do not just make these two changes and consider it done".
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Fri, 22 Aug 2008 13:39:57 -0700

> instead of "the party" you could say "the client").

I did anticipate a simple edit could have such a response.

<t>If the KDC that issued an anonymous ticket were to maintain
records of the association of identities to an anonymous ticket,
then someone obtaining such records could breach the anonymity.
Additionally, the implementations of most (for now all) KDC's respond
to requests at the time that they are received.
Traffic analysis on the connection to the KDC will allow an attacker to
match client identities to anonymous tickets issued.
Because there are plaintext parts of the tickets that are exposed on the wire,
such matching by a third party observer is relatively straightforward. A service
 that is authenticated by this mechanism may be able to infer the identity of the party by examining and linking quasi-static protocol
 information such as the IP address from which a request is received.</t>

I think the last sentence is highly relevant to this paragraph.

>You need to provide enough context and

I personally feel the verbiage I edited is better. This document talks about how anonymous clients authenticate the server, not just merely presenting. The server has to be able to decrypt the service ticket.

I would say the word "client' is probably better than the word "party".

>   [[ the IP address from which a request is received.

Can you or Phillip propose text that I can use directly?

That way it would be more productive for me to add the necessary text into the security considerations section that correctly reflect the reviewers' opinion.

--larry

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2008 16:52:08 -0400

--On Friday, August 22, 2008 01:39:57 PM -0700 Larry Zhu 
<[email-masked]> wrote:

> Because there are plaintext parts of the tickets that are exposed on the
> wire, such matching by a third party observer is relatively
> straightforward. A service  that is authenticated by this mechanism may
> be able to infer the identity of the party by examining and linking
> quasi-static protocol  information such as the IP address from which a
> request is received.</t>
>

Maybe.

>> example(*), instead of "a service that is authenticated by this
>> mechanism" you could say "a service to which an anonymous ticket is
>> presented", and instead of "the party" you could say "the client").
>
> I personally feel the verbiage I edited is better. This document talks
> about how anonymous clients authenticate the server, not just merely
> presenting. The server has to be able to decrypt the service ticket.

Well, there might be a better word than "present"; that was just an 
example, after all.  But I worry a little about the use of the word 
"mechanism".  I also note that the server does _not_ have to be able to 
decrpyt the service ticket in order to be able to infer things about the 
requestor from his IP address.  Just the fact that a request was made from 
a given address may be interesting.

> Can you or Phillip propose text that I can use directly?

I can't, and this wasn't originally my comment in any case.  The text you 
added was a good starting point, but needs a little bit of cleanup IMHO. 
Note that I don't think the exact words are a major issue as long as we get 
the point across.  I do think we need to make sure we get input from 
Phillip.

-- Jeff