Subject: re-posting message from SangHwan park

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Aug 2008 22:14:38 -0400

The principle author of the TAC I-D,  SangHwan Park, sent this 
message to me, Jim Schaad,  and to the PKIX list, but it does not 
appear to have made it to the list.  I am re-posting it on his 
behalf. I also reformatted it a bit, and highlighted the reply text 
in bold to make it easier to read.

Steve
--------

1.  What is the time length that TAC certificates are expected to be used
for?  Are they onetime certificates, are they supposed to be good for a
short period of time (i.e. months) or are they supposed to be good for
extended periods of time (i.e. years but used infrequently), or all of the
above?

We not not believe that this document should specify limits on the 
duration or frequency with which TACs are used, however they are not 
envisioned as one-time certs. It will be up to each TAC CA (BI/PI 
pair) to determine the lifetime of the certs it issues, and to advise 
subjects of suggested usage guidelines, e.g., via a cert policy. The 
security considerations sections says:
     ... if the user employs
    the same TAC for multiple transactions (with the same or
    different parties), the transactions can be linked through the
    use of the same TAC. Thus the anonymity guarantee is "weak"
    even though the user's real identity is still hidden.
    To achieve stronger anonymity, a user may acquire multiple
    TACs, through distinct iterations of the protocol.

2.  Given the ability to potentially link an identity from other information
on the network (i.e. IP addresses), I would like to see some text describing
the types of protocols that TAC certificates should and should not be used
in.  For example, it could be used for an anonymous TLS client auth
certificates, but would probably not be as useful for a SIP or S/MIME
certificate.  Or maybe you disagree with that.  A description of the types
circumstances that these certificates are used in would helpful in trying to
determine if they are both useful and susceptible to other types of attacks.

This issue was raised in Dublin and as a result we prepared text for 
the next rev of the document that addresses the issue you raise here, 
i.e., repeated use of an anonymous credential provides opportunities 
for linkage. There is also the potential to determine the true 
identity of a user by examining other info outside of what is 
provided by the cert. Here is the text we have for the security 
considerations section, dealing with this topic.

"It also may be possible to determine the identity of a user via
information carried by lower level protocols, or by other,
application-specific means. For example, the IP address of the
user might be used to identify him/her. An analogous problem
might arise if a user visits a site (and does not conceal
his/her identity), the site deposits a "cookie" into the
user's browser cache, and the user later visits a site and
employs a TAC with the presumption of anonymity.  This use
of a TAC is a tool to help a user preserve anonymity, but it
is not, per se, a guarantee of anonymity."

3.  I think the document should strongly suggest that indirect CRLs are used
by TAC CAs.  This would almost be a requirement for OCSP.  The protocol
needs to have a way for a communication to occur between the AI and BI to
allow for signing of CRLs in any event.  What is this going to look like.
Does the BI simply trust the AI to hand it a correct hash?  Does the AI sign
the CRL, pass it to the BI to finish signing and then verify, does the AI
give the TBS to the BI, have the BI sign it and then return the signature to
the AI to finish signing and publish?

In section 5, the text says that an AI unilaterally manages the CRL 
for a TAC CA:
      "If AI determines that there is sufficient
evidence of abuse to trace the TAC to the user, the AI revokes
   the TAC, by listing its serial number on the next CRL issued
   by the AI.

But the text failed to say how the AI does this.  Use of an indirect 
CRL may be the simplest approach to address this issue.

4.  Information should be placed in the document (Security Considerations is
fine) about the financial model associated with this issuing model.  All
user financials need to be done with the BI and not the AI, the AI would
have to get compensated by the BI for issued certificates.  An associated
item with this is the question of should the BI be able to influence
contents of the certificate, specifically the lifetime of the certificate to
correspond to the money paid.

There is no requirement that the Ai and BI be operated in a 
financially-separate fashion, but there also is no prohibition. Your 
suggestion is a good one, i.e., adding some text to the security 
considerations section to note that IF the AI and BI are financially 
independent of one another, THEN the user MUST pay the BI (who 
already knows the user's true identity), and the BI will compensate 
the Ai for each cert it issues. We can probably leave it to AIs and 
BIs to coordinate the issue of cert lifetime, for financial purposes. 
After all, the management of the CA is a joint matter for the AI and 
BI, and we should assume they will be able to work out these details.

5.  Renewal/Rekey operations are not covered by this document.  Either you
need to state that these operations are never done, or you need to have a
secure method of allowing the operation to be completed.  In this case the
Token no longer exists (or at least is no longer valid) and so the AI would
need to prove to the BI that the BI should sign the certificate.  One
possible method would be to send the BI the TBSigned of the new certificate
along with the old certificate allowing it to see that it had previously
signed a certificate for subject name.  It would still not be traceable back
to the user's Token, but would give assurances that the certificate should
be issued.

Good point. Renewal/Rekey should NOT be supported. We will revise the 
text accordingly.

6. The document does not discuss the fact that a TAC certificate should only
issue TAC certificates.  If this statement is incorrect, then the document
needs to discuss how non-TAC certificates are to be issued.  In this case
the BI would be signing certificates for people it has never seen before and
has no information about.

The simplest approach seem to be to require that a TAC CA issue only 
TAC EE certs. We will insert text to make this restriction clear.

7.  Guidance needs to be supplied about how long items are to be kept in the
respective databases.  Are these database entries expected to be kept
forever once a certificate has been issued?  Or are they only kept for
approximately the life of the certificate.  This is really impacted by the
answer to question #5 on rekey/renewal, but has some additional tracing
implications beyond that.

Since TACs are not suitable for NR (a detail than can be added to the 
text), there does not appear to be a need to retain data about TAC 
certs beyond their lifetime.

8.  How much is the following considered to be a potential attack on the
scheme.  The BI collects and remembers the time at which it issued a
signature on a certificate, it then stores that information in its database
and trolls for certificates that are issued at about the same time to match
up with the user information it has in the database.  Actually this attack
could potentially be expanded in a more general way.  If an attacker looks
for IP addresses talking to the CA, and then looks for certs from the CA
that were issued about that time, if the number of certificates issued is
small it might be possible to tie an IP address to a certificate.

The first attack is a valid concern, the second is covered, 
indirectly, by the new SC text cited above. We can add text to the SC 
to note that IF the TAC CA wants to counter this sort of attack, the 
cert issuance (vs. request) can be delayed, either by the user or by 
the AI. The timeout value needs to be set accordingly. We can add 
text noting the second concern as another example of the potential 
for using lower layer data to tie users to TACs.

9.  If you believe that TAC permits both signature and encryption
operations, then you need to address an additional problem.  If a DSA
signature certificate and a DH encryption certificate pair are needed, it is
some protocols may require that they contain the same subject name, and thus
would need to be issued at the same time.  The current TAC protocol makes no
allowances for the ability to have the BI sign two independent certificates
at the same time.  This could be done by allowing the protocol to present
multiple blinded hashes to the BI to be signed for a single token.

The primary focus of the TAC work has been web access. For that, a 
single cert is enough. But, you make a good point that if one wants 
to use TACs with S/MIME, for example, dual cert issuance needs to be 
supported. For now, we will stick with single cert issuance, with 
it's implied limitations.

10.  Suggest addition of text to "Step 1" in section 5.1.  "Hashing of the
user's name, without the additional of additional random material MUST NOT
be used for to create a UserKey.  It must be assumed that an attacker could
obtain the user's name."  The reason for this is that people may assume that
doing a hash will create a user key that satisfies the condition that it not
be associable with the user's name since it is a one-way function and could
not be reversed.

Good suggestion. We will add that warning to Step 1.

11.  In section 5.1 Step 2, the statement is made that a TLS certificate
should be used for doing the signature operation on a CMS object.  You might
want to rethink this statement.  While there is nothing technically wrong
with this, some CMS validators would reject the signature since the EKU
would not be correct.

Does CMS specify a set of EKUs that are acceptable for any use of 
CMS, or are you saying that the presence of any EKU associated with 
TLS use might cause rejection because software (e.g., OpenSSL) has 
some non-standard restrictions embedded in it?

12.  CRMF (and PKCS#10) are certification message request formats, they are
not protocols.  The certificate request protocols that the PKIX working
group has standardize are CMC and CMP.  The text needs to be written to
reflect this.  Either talk about the formats or talk about the protocols I
don't really care which, just don't confuse the two.

Good point. We will change the text accordingly.

13.  I would like to see for each of the steps in 5.1, an explanation of who
needs to be protected against for the communication.  This will better allow
others to decide on how to implement this with non-TLS communications.  For
example, could this be done with e-mail or are the security requirements not
met?

Not sure what you mean by "who needs to be protected against for the 
communication." We can explain in more detail what security features 
are required at each step, but there is already some text addressing 
this, for at least some steps. For example, in step 2, the document 
says:

"The secure channel is required here to prevent a wiretapper from
being able to acquire the Token. For example, if the user
establishes a one-way authenticated TLS session to the BI in
Step 1, this session could be used to pass the Token back to
the user."

14.  I am not sure how detailed this topic needs to be covered, but the
document needs to discuss the fact that obtaining this certificates may take
time and  the transaction may not be completed in one round trip from the
user to the AI.  One question that comes about is does this increase any
security considerations?

We can add text to note that this step might not complete quickly. 
The UserToken and the database timeout scheme should allow allow safe 
resumption of an interrupted user/AI interaction, without permitting 
duplicate cert issuance or session hijacking.

15.  I would strongly recommend that a Token be a CMS ContentInfo object.
All CMS implementations will accept a ContentInfo object to be decoded, not
all of them will accept a SignedData object to be decoded.  Additionally if
you use a ContentInfo object, the BI could apply encryption to the token so
that only the AI can understand the contents.  Thus either Signed(content)
or Signed(Encrypted(Signed(content))) would be returned to the user.

Good suggestion, we will make that change, and look forward to your 
proposed details for the profiled for the ContentInfo object.

16.  The numbering of steps on Figure 1 is incorrect starting with step #4.
One of the steps does not include a transmission step (or the transmission
is part of two steps).

We'll review the text and mapping to the diagram and make the necessary fixes.

17.  In section 5.2, step C - should the BI also conduct its own assessment
of the fact that the aggrieved party's case before releasing the
information?

BI could do so. We can add text to say that is an option, but it 
would be something that each TAC CA decides for itself, and declares 
in its CP and details in the CPS.

18.  In section 6, does there need to be any comments about the possible
problem of BI trying to attack AI share of the key?  I have not read any
threshold crypto work recently, but it seems to me that a shorter half key
might be easier to break.

We have tried to make the design independent of the specific 
threshold crypto algorithm used. Noentheless, we can add a sentence 
noting that the parties need to ensure that the selected scheme is 
secure against this sort of "insider" attack.

19.  I am not an expert here, however you probably need to explain how the
communications over the TLS link are being made.  I assume that you are
using HTTPS, but that is not clear.

Good point. An Appendix describing how to use TLS for communicating 
these messages needs to be added.

I'll make a pass over the ASN.1 after these issues have been resolved.
Questions of what the content of various items looks like will change based
on some of the above questions.  At a minimum however we will need to get a
CMS content type to be used in the token.

yes, thanks.

-------------------
SangHwan Park
Senior Researcher / CISA / CISSP / ITIL
Korea Information Security Agency(KISA)
+82-2-405-5428, <mailto:[email-masked]>[email-masked]

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Aug 2008 22:02:48 -0500

Comments inline.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Thursday, August 28, 2008 9:15 PM
To: [email-masked]
Subject: re-posting message from SangHwan park

The principle author of the TAC I-D,  SangHwan Park, sent this message to
me, Jim Schaad,  and to the PKIX list, but it does not appear to have made
it to the list.  I am re-posting it on his behalf. I also reformatted it a
bit, and highlighted the reply text in bold to make it easier to read.

Steve

--------

above?

We not not believe that this document should specify limits on the duration
or frequency with which TACs are used, however they are not envisioned as
one-time certs. It will be up to each TAC CA (BI/PI pair) to determine the
lifetime of the certs it issues, and to advise subjects of suggested usage
guidelines, e.g., via a cert policy. The security considerations sections
says:

    ... if the user employs

I understand that you are not specifying the lifetime.  That is part of the
problem.  If they can be used for a long time, i.e. past the time that the
certificate would "normally" expire or worse past the time that you have
some type of contractual relationship with the BI, then you have a security
problem.  Do you renew a current certificate, and how do you decide if that
certificate has been paid for, or do you issue a new certificate with a new
identity and lose any history of the identity with existing relationships.
In one case you are requiring a restart of a relationship with a partner, in
the other case you are potentially leaking information to either the AI or
BI about who you are.

This issue was raised in Dublin and as a result we prepared text for the
next rev of the document that addresses the issue you raise here, i.e.,
repeated use of an anonymous credential provides opportunities for linkage.
There is also the potential to determine the true identity of a user by
examining other info outside of what is provided by the cert. Here is the
text we have for the security considerations section, dealing with this
topic.

This text does not address the issue that I raised.  Specifically what type
of protocols is this good for, and what type should it not be used for since
more information is available to potentially more people.  You have
discussed issues dealing with one specific type of protocol - http/https.
This does not look at other protocols and type of issues that these
protocols raise.

Here is an example, do you believe that a TAC certificate should be used for
sending and receiving e-mail?  I think that this raises all sorts of problem
with a store and forward architecture.  It is much simpler for people to
obtain information by eavesdropping in this case than it would be for the
case of TLS - especially if you deferred client certificate validation until
after the secure channel has been established.

In section 5, the text says that an AI unilaterally manages the CRL for a
TAC CA:

  by the AI.

But the text failed to say how the AI does this.  Use of an indirect CRL may
be the simplest approach to address this issue.

Requiring TACs to use indirect CRLS is the simplest way to address this
problem, however rfc5280 implementations are not required to process
indirect CRLs.  This means you are going to either specify a protocol to
allow for direct CRLs to be jointly issued, or you are going to be
non-rfc5280 compliant.

There is no requirement that the Ai and BI be operated in a
financially-separate fashion, but there also is no prohibition. Your
suggestion is a good one, i.e., adding some text to the security
considerations section to note that IF the AI and BI are financially
independent of one another, THEN the user MUST pay the BI (who already knows
the user's true identity), and the BI will compensate the Ai for each cert
it issues. We can probably leave it to AIs and BIs to coordinate the issue
of cert lifetime, for financial purposes. After all, the management of the
CA is a joint matter for the AI and BI, and we should assume they will be
able to work out these details.

The first issue is that you cannot pay the AI for your certificate.  If you
do, then you need to pay with some type of anonymous cash, and you must pay
using a completely anonymous protocol.  I don't know of any way to currently
do this except in the realm of academia.  

I don't believe that you can leave the issue of things like lifetime out.
Let's say that the BI can allow for issuing of certificates for a period of
three months, one year and five years.  The BI would need to communicate
this information as part of the token, or the BI and AI would need to have
an additional conversation before the AI builds the certificate in order to
get this piece of information.  

As an alternative, you could have different AI's for different length
certificates.  This would imply that the BI cannot directly influence the
contents of the certificate, but would require that the BI tell the user
what the name of the AI to be used to issue the certificate.  (Which might
not be a bad idea anyway.)

be issued.

Good point. Renewal/Rekey should NOT be supported. We will revise the text
accordingly.

This has some implementations for item 1.

The simplest approach seem to be to require that a TAC CA issue only TAC EE
certs. We will insert text to make this restriction clear.

This sounds good

Since TACs are not suitable for NR (a detail than can be added to the text),
there does not appear to be a need to retain data about TAC certs beyond
their lifetime.

An aggrieved entity may want to get the identity information about a signer
after the certificate has expired.  This implies that there is at least some
minimum duration that the information needs to be kept for traceability
reasons.

The first attack is a valid concern, the second is covered, indirectly, by
the new SC text cited above. We can add text to the SC to note that IF the
TAC CA wants to counter this sort of attack, the cert issuance (vs. request)
can be delayed, either by the user or by the AI. The timeout value needs to
be set accordingly. We can add text noting the second concern as another
example of the potential for using lower layer data to tie users to TACs.

The primary focus of the TAC work has been web access. For that, a single
cert is enough. But, you make a good point that if one wants to use TACs
with S/MIME, for example, dual cert issuance needs to be supported. For now,
we will stick with single cert issuance, with it's implied limitations.

This needs to be made explicit.  

not be reversed.

 

would not be correct.

Does CMS specify a set of EKUs that are acceptable for any use of CMS, or
are you saying that the presence of any EKU associated with TLS use might
cause rejection because software (e.g., OpenSSL) has some non-standard
restrictions embedded in it?

If there is an EKU in the certificate, and it is not one of the "acceptable"
EKUs for CMS, it is possible that some implementations might reject the
certificate.  This is highly dependent on the implementation.  I don't know
if this is a problem, but it potentially could be.   One possible solution
would be to create an EKU specifically for this operation.

 

met?

Not sure what you mean by "who needs to be protected against for the
communication." We can explain in more detail what security features are
required at each step, but there is already some text addressing this, for
at least some steps. For example, in step 2, the document says:

the user."

There are cases where you need to explicitly prevent either the AI or BI
from getting the information, but may not need to protect against a general
wiretapper.  For example, if the client and BI transaction is open (except
to the AI), this may not help an eavesdropper as long as the client/AI
transaction is completely sealed.  The eavesdropper would be in same
situation in this case as BI, it knows some information but not enough to
complete the trace without the cooperation of the AI.

security considerations?

We can add text to note that this step might not complete quickly. The
UserToken and the database timeout scheme should allow allow safe resumption
of an interrupted user/AI interaction, without permitting duplicate cert
issuance or session hijacking.

Good suggestion, we will make that change, and look forward to your proposed
details for the profiled for the ContentInfo object.

is part of two steps).

We'll review the text and mapping to the diagram and make the necessary
fixes.

information?

BI could do so. We can add text to say that is an option, but it would be
something that each TAC CA decides for itself, and declares in its CP and
details in the CPS.

Not requiring this would allow for a rouge AI to get the information.  It
would create a pretend aggrieved party, provide the details to that party
and query the BI.  The BI doing no checks would hand over the information no
questions asked.

We have tried to make the design independent of the specific threshold
crypto algorithm used. Noentheless, we can add a sentence noting that the
parties need to ensure that the selected scheme is secure against this sort
of "insider" attack.

Good point. An Appendix describing how to use TLS for communicating these
messages needs to be added.

yes, thanks.

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

SangHwan Park

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