Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Oct 4, 2017 at 9:40 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
You seem to be making some unstated assumptions.

If by "Provider" in "Provider based AUTH" you mean the last hop communications service provider, then I would fundamentally disagree with you.  The communication service provider has no role in creating or authenticating identifiers.  Their job is to provide locators.

<Padma> There is no disagreement in that the access provider role is to provide locators.

 
Now, those service providers may have an authentication relationship, based on some identifiers, in order to provide communications services.

<Padma> Again no disagreement that the access provider have an authentication mechanism. An example would be  "A device connects to a wifi, uses some authentication to get a locator."
 
But the identifiers for that are completely uncoupled from and unrealted to the identifiers need for an ID / Locator system.


<Padma> Still in agreement with you here and this is like a <wifiname,passwd> and has nothing to do with ID/LOC. I might also add that this is orthogonal to the discussion. The access provider can be provider of identifiers or not it would not have any bearing.


At this point, the device has a locator and next step is to update its locator in the mapping system.



Yes, if there is a provider of identifiers (not all systems even require that), then the user of the identifier needs to have an appropriate relationship with the provider of the identifier.  And that needs to be related to the authentication needed to update the mapping system.

<Padma>

(1) The "appropriate relationship with the provider of identifier"  or what you call the "user of the identifier" (for clarity - user is NOT a person) is what in this context is called "identity". May be some people would prefer some other term (pseudonym?) but let's stick to this one for the moment.

 

Now regarding who can update the locators?

(2) There is agreement that there is a need for the "user of the identifier" (again user is NOT a person)  to be authenticated to update the locator of an Identifier.

 

(1) + (2)  actually shows de facto a relationship between "user of identifier"(aka identity here)  and the "identifier". 


This is all that what is formalized in this charter as the identity-identifier relationship.

 
But neither of those require anything other than the identifier and suitable keying.  I gave several examples of this in earlier emails to the list.


<Padma> Here is where we have some difference of opinion ...


Well depending on the functionalities, it might be that keying is not sufficient or they may be alternatives to keying. As mentioned in the thread earlier ... there are 2 operations with require some authentication or access-control

- update

- lookup

 

Access control or "policies" on look up for one may be challenging using keying. Some notions of closed user groups are interesting use cases and it is worthwhile to evaluate other alternatives.

 

Now if we want an open system with no authentication for updates or lookups and no close user group kind of features ... Then, as you said earlier not all system require that and we do not need "user of identifier".

Precisely, this is why the identity concept is optional. 

However it can be useful in some cases such as in enterprise space where IoT devices may need finer access control

Regards
Padma  
 
Yours,
Joel


On 10/4/17 11:24 PM, Uma Chunduri wrote:
Hi Joel,


        >Yes, authentication is necessary to modify the entries.  (Whether one should be authenticated before reading varies from case to case.)
        >But authentication does not require a separate identity.  Exactly what it requires depends upon how the system is constructed.

IMHO, provider based AUTH is needed in lot of cases if we really want to build a solid system which enables mobility.
I responded to Jari, who is a pioneer and who helped spec out one of the best AUTH methods  & systems successfully deployed ever with his https://tools.ietf.org/html/rfc4187
(but he did it for another most successful SDO, with all constructs like Pseudonyms and fast-re-auth-ids) didn't see the need for the same here.
May be as you indicated there is something missing in the charter that didn't reflect the need.

--
Uma C.


_______________________________________________
Ideas mailing list
Ideas@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ideas


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]