Re: [core] concerns re draft-oflynn-core-bootstrapping-02

[Rene Struik <[e-mail]>]

Hi Yoshihiro:

It seems that in your example each device identifier is tied to a single 
security manager (e.g., device A and security manager S would yield 
device id [e-mail]).

This seems to imply the following:
(a) entangles the name space and device role space (since tie-ing node A 
to a node S that assumes a security manager role for A);
(b) precludes scenarios where
     (b1) a device may have multiple security managers (example: remote 
control, spare remote under the pillow, central node);
     (b2) a security manager may change over time (example: change of 
security manager, due to malfunctioning device or ownership change);
     (b3) a device may not have a security manager yet (example: device 
is initially taken out of generic box, without any imprinting happening 
yet);
     (b4) a device and security manager may not be in hierarchical 
relationship (example: simple device pairing a la Bluetooth v2.1 EDR).
As such, this seems to preclude many useful deployment scenarios for 
sensor networks.

Hence, my note in my email as of Wed October 27, 2010, 11:04am EDT re 
the latest version of draft-oflynn-core-bootstrapping-02, in which I 
highlighted the importance of facilitating a flexible set of deployment 
scenarios.

Please let me know if I misinterpreted your EAP-style explanation 
(above, I only focus on logical device roles and not on communication 
patterns).

Best regards, Rene

[excerpt email RS as of October 1, 2010, 12:16pm EDT]

In my mind, properties of suitable authenticated key agreement schemes 
should include (a) key establishment; (b) implicit key authentication; 
(c) key confirmation; (d) mutual entity authentication; (e) forward 
secrecy; (f) {perhaps} some more esoteric properties (key compromise 
impersonation resilience, etc.).

Moreover, the "name space" (device identifiers) and the "cryptographic 
space" (public keys, etc.) should be independent, so that this would 
allow trust lifecycle management to be reduced to proper management of 
device identifiers (i.e., ****no** entanglement of concepts from 
different disciplines).


On 28/10/2010 7:20 PM, Yoshihiro Ohba wrote:
> OK, then let me use the term "RADIUS server" to explain.
>
> Any EAP transport protocol such as IEEE 802.1X and PANA works with
> multiple AAA domains in which a single access network may interface to
> multiple RADIUS servers where each RADIUS server serves for a distinct
> AAA domain.  With EAP, RADIUS routing is based on the EAP peer
> identity such as "[e-mail]" and "[e-mail]" in a way that
> authentication messages for EAP peer "[e-mail]"are routed to
> "domainA.com" RADIUS server and authentication messages for EAP peer
> "[e-mail]" are routed to "domainB.com" RADIUS server.  The EAP
> peer identity is extracted from the initial EAP exchange by an EAP
> pass-through authenticator that is co-located with a RADIUS client at
> the border of the access network.  In a large scale RADIUS deployment,
> there may be RADIUS proxies between a RADIUS client and a RADIUS
> server to simplify the AAA routing task for RADIUS clients.  In PANA,
> PAA (PANA Authentication Agent) is the EAP pass-through authenticator,
> and PaC (PANA Client) is the EAP peer.
>
> Hope this helps,
> Yoshihiro Ohba
>
> (2010/10/29 6:21), Carsten Bormann wrote:
>> On Oct 28, 2010, at 22:48, Alper Yegin wrote:
>>
>>> mothership
>> I think other terms are "mother-may-I", "trust center", "RADIUS server", or "Policy Decision Point".  Just guessing, though.
>> I think the use case of interest here is a single constrained network that simultaneously serves multiple trust domains, so being authorized by any one of them should give you access.
>>
>> With that potential explanation, can you elucidate whether (and maybe how) PANA would work in this scenario?
>>
>> Gruesse, Carsten
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core


-- 
email: [e-mail]
Skype: rstruik
cell: [phone]
USA Google voice: [phone]