Subject: [Ietf-krb-wg] FW: SECDIR review: draft-ietf-krb-wg-anon-05

From: Larry Zhu <[email-masked]>
Date: Sun, 27 Jul 2008 14:12:19 -0700

Document: draft-ietf-krb-wg-anon-05
Reviewer: Phillip Hallam-Baker
Date:     30 April 2008

I have reviewed 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.

ObDisclosure: US Patent Application 20070250704 describes an invention with a possibly related approach. Rather than address the issue of whether there might be an issue here it would be helpful to know the publication history.

1) Abstract, without revealing the client's identity to whom?

The introduction implies that the objective is to avoid revealing the identity to the server while revealing the identity to the KDC 'at least once'

2) Section 6.

Clarification, 'a ticket that is returned is actually anonymous'. A Kerberos server may not return a ticket at all and there are also ticket granting tickets being used so use of the definite article 'the ticket' is somewhat confusing.

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.
-------------- next part
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Sun, 27 Jul 2008 14:23:24 -0700

Hi Philip, thanks for the review comments.

> 1) Abstract, without revealing the client's identity to whom?

The client does so without revealing the client's identity to the server or the KDC. In the anonymous PKINIT variant, the client does not reveal the identity to the KDC either. I would propose to make this clear in the abstract.

> Clarification, 'a ticket that is returned is actually anonymous'. A Kerberos server may not return a ticket at all and there are also ticket granting tickets being used so
> use of the definite article 'the ticket' is somewhat confusing.

The context is that the client is required to examine the ticket in the rely. Kerberos is a request/reply and lock-step protocol. There is only one reply ticket. I believe the text is sufficiently clear. Or please suggest how should I make it better.

> 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 the security considerations section talks about the former (i.e. passive eavesdropping).

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry Zhu
Sent: Sunday, July 27, 2008 2:12 PM
To: [email-masked]
Subject: [Ietf-krb-wg] FW: SECDIR review: draft-ietf-krb-wg-anon-05

2) Section 6.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jul 2008 03:10:57 +0100

--On Sunday, July 27, 2008 02:23:24 PM -0700 Larry Zhu 
<[email-masked]> wrote:

>> 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.
>

I believe the point Phillip was trying to make is that the security 
considerations _should_ call out that a service might be able to do some 
analysis to infer the identity of the client.  I'm inclined to agree, and 
suggest you include some text to this effect.  This could be as simple as 
using some text directly from Phillip's mail message.

-- Jeff