Re: [dane] [saag] Need better opportunistic terminology

[Paul Lambert <[e-mail]>]

On 3/12/14, 2:47 PM, "Stephen Kent" <[e-mail]> wrote:

>Joe,
> >
>>> yeah, I like OK (and I like IKE too, for those of us old enough to
>>> appreciate that election slogan)
>>
>> I'm still a little hesitant, thinking on it further, about the term
>> "opportunistic" in this sense at all.
>>
>> BTNS uses unsigned key exchanged, and there's nothing "opportunistic"
>> about it. Unsigned authentication is the goal from the start.
>>
>> OE as defined in RFC 4322 isn't about using unsigned key exchange; the
>> "opportunistic" sense is derived from using keys retrieved from DNS
>> without prior agreement. That's not what happens in BTNS.
>agreed.
>> Paul just noted:
>> "Opportunistic keying does provide authentication, it's just that
>> the authentication is only to the public key and is not
>> tightly bound to any other type of identification (address, name, etc.)"
>Public keys are not principles. We went through that long and painful
>discussion
>during the SPKI days.

> 
Your level of pain in a discussion is not a measure of a concepts validity
:-) 

Public keys and the hashes of public keys are the fundamental identifier
of a Œprincipal¹ when we are using public key based authentication. The
principal is the end user or computer that controls the use of the public
key.  The public key is authenticated in a key exchange or signature
validation process and is the primary connection in the process to the key
holder (principal).  Other information may be associated with the key
locally or through a trusted path (out-of-band, signed, etc.) that can be
used for authorization decisions.  The other information may even include
information associated with the key in a X.509 or other form of
certificate.

The public key and associated key hash for a principal may change.
Changing keys could be viewed as either a new identifier for the same
principal or a new principal with the same associated attributes as a
previous principal.  Either way, the public key (or hash) is a unique
identifier of a principal which can then be usefully processed in a
security policy.   

There are several usages of ³opportunistic² in this thread.  Clearly new
terms are needed.  I¹m primarily interested in Œkeys as identifiers¹ where
longer term keys are used to identify principals. Security policies are
built on hashes of keys and optionally other associated information that
may include names, labels, group membership, etc.

This may be getting a little far afield of the TLS-DANE or IPsec
opportunistic specific usage.  Still, the deferred binding and the TOFU
model are compatible with a perspective of keys as identifiers of
principals.


>So, saying that OE provide authentication of a key
>seems
>meaningless to me, especially if the key is ephemeral.
Yes, ephemeral keys do not provide any long term identity. This can also
be a feature.  A Œprincipal identifier¹ with no associated information
would only be authorized for actions that have no restrictions on specific
principals.  

Paul



>> I.e., fundamentally, opportunistic approaches are completely different
>> from those that don't ever bother to authenticate. I don't think it's
>> useful (and could be confusing) to confuse the two by overlapping
>> terminology.
>We'll, we don't have an agreed upon definition for O* yet. My view is
>that the primary goal of
>this effort is to remove barriers to using encryption. Since
>authenticating the identity or a
>peer or server has tended to be a barrier, we seem willing to make that
>form of authentication
>optional. But, we still prefer authentication, because we'd like to
>avoid MiTM attacks. That suggests
>that O* refers to techniques that emphasize encryption, prefer that it
>be authenticated, but are
>willing to fall back to un-autnenticated encryption if that's thbe best
>we can do. (And to fall back
>to plaintext if the peer/server is not capable of our new-fangled O*)
>> I don't like the term "optimistic" either; it too implies something
>> that you "hope works". There's no "hope" associated with unsigned key
>> exchange; you do it (IMO) because you know what it is and you know its
>> impact (e.g., raising the bar of an attacker to performing a full key
>> exchange, vs. just tossing single packets like RSTs around).
>I'm not wedded top either term, but I'd like to emphasize that the
>encryption process is
>the same in all cases; it's the key management that's different.
>>
>> Is there a reason not to just call unauthenticated key exchange what
>> it is - unauthenticated key exchange?
>I think we want more than that, as I described above, hence the desire
>to coin a new term.
>
>Steve
>
>_______________________________________________
>saag mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/saag