Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

[Denis <[e-mail]>]

Hans,

This has nothing to do with "private key sharing". Private keys are 
usually protected by some hardware device which does not allow to export 
these keys.
However, a legitimate user can *use* his hardware device which means 
that he can ask to his device to perform some cryptographic computation 
with the private keys
that are stored in it.

In the past, when doing a threat analysis, only external attackers were 
being considered. Collaborative attacks is a different kind of threat 
that should also be considered.
However, it only applies to some specific contexts:

    If the security token contains a sufficient number of attributes
    that allows to fully identify the bearer, the bearer will probably
    refuse to collaborate with anybody else,
    because that other body could fully impersonate him.

    If the security token contains one or more attributes that do not
    allow to fully identify the bearer, the bearer may accept to
    collaborate with somebody else, because
    he cannot be identified. Typical examples of such an attribute are:
    "over 18" or "resident of Florida". Such attributes may allow to
    access to a service.

Any solution using software only is unable to counter collaborative 
attacks. Any solution using hardware devices that are only protecting 
the private keys, /but not their usag//e/,
are also unable to counter collaborative attacks. The topic has nothing 
to do with generic PKI principles and guidelines. However, adding some 
additional explanations into
the security considerations section along those provided above could be 
useful.

Denis

> Can we please stop adding text that says "don't share your private key 
> with others" to IETF drafts? That is an inherent part of PKI and does 
> not need to be repeated everywhere IMO, just like text about how 
> verifying TLS server certificate should work is not repeated in drafts 
> where TLS is a requirement. Perhaps a reference to generic PKI 
> principles and guidelines may be included?
>
> Hans.
>
> On Mon, Sep 17, 2018 at 11:32 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with
>     TLS Terminating Reverse Proxies
>
>     The introduction states:
>
>         An HTTP server issuing cookies or other security tokens can
>         associate them with the Token Binding ID, which ensures those
>         tokens
>         cannot be used successfully over a different TLS connection or
>         by a different client than the one to which they were issued.
>
>     When there are only external attackers, the sentence is correct
>     but is incorrect when there is a collusion between a legitimate
>     client and another client.
>     The sentence should be corrected. Here is a proposal:
>
>         An HTTP server issuing cookies or other security tokens can
>         associate them with the Token Binding ID, which ensures those
>         tokens
>         cannot be used successfully over a different TLS connection or
>         by a different client than the one to which they were issued,
>         as long as
>         there is no collusion between the legitimate client and
>         another client.
>
>     In the "Security Considerations" section (section 4), some
>     explanations should be added. Here is a proposal:
>
>         The token binding mechanism is efficient against external
>         attackers, but, in case a legitimate client collaborates with
>         another client,
>         the mechanism can be defeated since the legitimate client,
>         using the private key which proves possession of the security
>         token, can perform
>         all the cryptographic computations that the other client needs
>         to demonstrate the possession of that security token.
>
>     Denis
>
>>     This message marks the start of a 2 week WGLC on
>>     draft-ietf-tokbind-ttrp-06 as agreed in Montreal but only now effected
>>     by your chair.
>>
>>     Please provide your final comments, voices of support or objections
>>     by COB Fri 28 Sept in any TZ.
>>
>>     	Best R
>>     	Leif
>>
>>     _______________________________________________
>>     Unbearable mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/unbearable
>
>
>     _______________________________________________
>     Unbearable mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
> -- 
> [e-mail] <mailto:[e-mail]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>