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

[Yoshihiro Ohba <[e-mail]>]

Hello Rene,

Thank you very much for expressing your concerns in detail.

Basically there is no implications such as (a) and (b1) to (b4) in the
general framework of PANA, EAP and AAA.  Let me explain this in
details below..

(2010/10/29 12:38), Rene Struik wrote:
> 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);

In the case where the EAP peer identity is tied with the device in
which the EAP peer resides, you are right.  However, the EAP peer
identity is not necessarily tied with the device.  It can be also tied
with the user who uses the device.  Or when a tunneling EAP method
such as EAP-TTLS is used, it is possible to tie the EAP peer identity
for the outer EAP method with the device *and* tie the EAP peer
identity for the inner EAP method with the user.  So in general EAP
framework, there is no fixed binding is assumed between the device and
security manager.

> (b) precludes scenarios where
> (b1) a device may have multiple security managers (example: remote 
> control, spare remote under the pillow, central node);

When PANA is used, it is possible to have multiple PANA sessions
between a PaC and a PAA, and different EAP peer identities can be used
for those PANA sessions where each EAP peer identity may be tied with
a distinct security manager.  OTOH, this kind of scenario is difficult
to be supported by IEEE 802.1X which allows only one authentication
session between a pair of 802.1X Supplicant and Authenticator.

> (b2) a security manager may change over time (example: change of 
> security manager, due to malfunctioning device or ownership change);

I think this is basically a provisioning issue.  If a deployment uses
a provisioning mechanism that allows dynamically changing the EAP peer
identity associated with a particular device, it is possible to change
a security manager over time under the EAP framework.

> (b3) a device may not have a security manager yet (example: device is 
> initially taken out of generic box, without any imprinting happening 
> yet);

Again I think this is a provisioning issue.  If a deployment uses a
provisioning mechanism that supports a standalone bootstrapping
mechanism during the provisioning phase, it is possible not to use a
security manager in the provisioning phase.

> (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.

Since the EAP framework does not require to use the AAA
infrastructure, a P2P relationship can be supported by the EAP framework.

We can clarify these things in the core-bootstrapping draft if it helps.

Best Regards,
Yoshihiro Ohba


> 
> 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
> 
>