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

[Rene Struik <[e-mail]>]

Hi Yoshihiro:

As already expressed, I would really favor a more fundamental approach,
where deployment scenarios, desired operational behaviors, and required
security properties are guideline to the design. Protocol soup acronyms
are nice, but they could obscure what one is really after here (at
least, that is what this does to me).

That is also what I expressed in my email 4 weeks ago (October 1, 2010),
originally in the context of HIP. Unfortunately, most of the analysis is
still missing.

Best regards, Rene
(again in the office Monday)

On 29/10/2010 3:30 AM, Yoshihiro Ohba wrote:
> 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
>>


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