]On 3/11/2014 3:12 PM, Joe Touch wrote:
]> Hi, Steve,
]....
]>> I have
]>> suggested "opportunistic keying" as a preferred term, since its the
]>> key management, not the encryption per se, that distinguishes other
]>> proposed modes of operation for IPsec, TLS, etc.
]>
]> I agree if you're replacing OE with OK ;-)
]
]One clarification: I don't see the use of unauthenticated keying as
]opportunistic in any sense of the word.
]
]Opportunistic would mean making an assumption that might be wrong, but
]when it's right it saves time/effort.
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.)
The binding of the key to other information useful for access control
decisions is deferred. Other mechanisms are used to associate
the key with an appropriate access policy. At this point is
where it seems to get a little trickier to describe a generic model
for multiple protocols. Different applications have different
identifiers and binding requirements.
I'm assuming the intent generally that the first key discovered
for a specific context would be bound to that specific usage.
Without some type of pinning of the key to a context we
end up with unauthenticated encryption.
This implies that we will be creating more applications
that display public keys or hashes of public keys. Human
validation of key ownership is always a good security check
(although not always the best user experience).
The definition should be clear on the necessity of the
additional binding and possible check of the key ownership.
One idea for formalization of such opportunistic mechanisms
would be to clearly define the state of the key binding to
it's use in a particular context. A key newly discovered
and being used for a particular dns address could be
in an invalidated state, while one that was explicitly
checked in some manner would be in a validated state.
Note - I'm working on protocols for bootstrapping
P2P security that are very close to these discusions.
Basic design is that all devices have a public
Key and they are introduced for a particular
set of communications (service). In this application
out-of-band channels can be used to support the
introduction (e.g. NFC, QR Code, label on device, dynamic
label on display). I've been calling aspects of this
bootstrap process 'key centric' versus opportunistic since
we are trying to always have a means to securely bind the
key to the specific usage. Keys are the identity and
are maintained in ACLs and groups for access control.
Usability concerns in products will introduce
implementations that are more promiscuous and
connect opportunistically with minimal human interaction.
The different types of security policies that this creates
is a problem in that it lacks clear user oriented definitions.
Right now, in the Wi-Fi industry the terminology is
either 'open' or 'encrypted' (aka WPA2).
Now there will be new modes like: encrypted but
anyone can connect (e.g. open printer kiosk).
I suspect that that this differentiation in policies
will also occur in other uses of opportunistic encryption.
Paul
]
]There's no savings here; by using unauthenticated key exchange, you're
]really just lowering the bar.
]
]That said, I don't like the term "anonymous encryption" because it
]implies identity hiding, which isn't the purpose either.
]
]Why not just use the term "unauthenticated encryption", when that's
]exactly what's happening?
]
]Joe
]
]_______________________________________________
]saag mailing list
][email protected]
]https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
