Subject: Re: WG Last Call on draft-ietf-pkix-tac-03

From: 박상환 <[email-masked]>
Date: Fri, 3 Apr 2009 10:41:41 +0900

Dear Stephen,

Thank you for the comments.

I’ve included my responses inline below.

> A couple of comments:

>#1: Top of p7:

>  "To effect issuance of the TAC, the AI interacts with

>   the BI, over a secure channel, to jointly create the signature on

>   the TAC, and sends the signed TAC to the user.

>   The AI does this without learning the user's real identity

>   (either from the user or from the BI)."

>If the AI sends the TAC to the user, then it will know some

>form of identity for that user, even if that's only an IP

>address. (And with the likes of SAVI, that could well be

>enough to establish a real identity.)

>I'd have thought it'd be much better to return the TAC

>via the BI and not require any user<->AI direct connections?

According to the concept of separation of CA authorities in this document,
BI only identify user’s real identity and AI only issue TAC with the help
of BI without disclosing user’s real identity. As you suggested if we
allow BI to send TAC to users not from AI, BI can trace user’s real
identity unilaterally. It means it is against our concept. And AI can’t
trace their real identity with IP address alone, collected in the issuance
process because AI does not have any identity information for users. For
this reason, it makes sense to require AI to send TAC to users.

>#2: Section 5.2 claims that the AI can't unilaterally fool

>the BI into revealing the real identity. But the only thing

>that stops that seems to be the RP client identity verified

>by the BI when the RP establishes a mutual-auth TLS connection

>to the BI.

>So how can the BI really know that its not the AI making that

>connection?

We have adopted two-way authentication channel, in order for BI to identify
and ensure communicating party’s identity.

It means BI can realize the communicating party is eligible for the request
for user’s real identity. 

For this reason, i don’t think it is necessary to add the notes to imply
BI must reject AI’s request for user’s real identity.

Stephen.

-------------------

SangHwan Park 

Senior Researcher / CISA / CISSP / ITIL

Korea Information Security Agency(KISA)

+82-2-405-5428, [email-masked]

---

From: 박상환 <[email-masked]>
Date: Fri, 3 Apr 2009 11:00:37 +0900

Dear Stephen,

Stephen.

-------------------

SangHwan Park 

 

-------------------

SangHwan Park

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 03 Apr 2009 10:27:27 -0400

I think that Stephen makes a great point.  Stephen's point is that in
many cases it is possible to learn someone's true identity even if one
is only provided the IP address from which the person was
communicating.  So, it would not matter that the TAC protocol does not
provide the AI with any identity information.

I also do not agree that the TAC cannot be sent directly from the BI to
the user.  The protocol could be reworked to address Stephen's
concern.  The basic idea for the protocol would be as follows:

step 1: The user creates a certificate request message and encrypts it
with a session key, which is in turn encrypted using the AI's public
key.

step 2: The user authenticates to the BI and provides the BI with the
encrypted certificate request message.

step 3: The BI creates a Token for the user and sends the Token and the
encrypted certificate request message to the AI over a channel that is
protected using two-way authenticated TLS.

step 4: The AI decrypts the certificate request message and creates the
TBSCertificate.

(If it is considered necessary): steps 5 and 6:  The AI and the BI
jointly sign the TBSCertificate using the blinded, split signature
scheme.

step 7: The AI encrypts the signed certificate (TAC) using the session
key that was created by the user in step 1 and sends the encrypted TAC
and the Token to the BI.

step 8: The BI sends the encrypted TAC to the user.

[Note that to maximize privacy, the encrypted certificate request
message and the encrypted TAC could both be padded to a fixed length to
ensure that the BI could not learn anything from the lengths of these
messages.]

I wrote out this protocol fairly quickly, so I may not have gotten all
of the details correct, but I think the basic idea is correct.  It
seems to retain all of the properties of the current protocol while
also helping to address the flaw that Stephen identified.

Dave

SangHwan Park wrote:

Dear Stephen,

Thank you for
the comments.

I’ve included my
responses inline below.

> A couple
of comments:

>#1: Top of
p7:

>  "To
effect issuance of the TAC, the AI
interacts with

>   the BI,
over a secure channel, to jointly
create the signature on

>   The AI
does this without learning the user's
real identity

>If the AI
sends the TAC to the user, then it will know some

>form of
identity for that user, even if that's only an IP

>address.
(And with the likes of SAVI, that could well be

>I'd have
thought it'd be much better to return the TAC

>via the BI
and not require any user<->AI direct
connections?

According
to the concept of
separation of CA authorities in this document, BI only identify user’s real
identity and AI only issue TAC with the help of BI without disclosing
user’s real
identity. As you suggested if we allow BI to send TAC to users not from
AI, BI
can trace user’s real identity unilaterally. It
means it is against our concept. And AI can’t trace
their real identity with IP address alone, collected in the issuance
process because
AI does not have any identity information for users. For this reason,
it makes
sense to require AI to send TAC to users.