RE: [dhcwg] identifier for key selection

"Bernie Volz" <volz@cisco.com> Thu, 08 July 2004 15:06 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28985; Thu, 8 Jul 2004 11:06:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZz8-0003GE-Ja; Thu, 08 Jul 2004 10:34:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZBZ-0007QL-Hy for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 09:43:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21263 for <dhcwg@ietf.org>; Thu, 8 Jul 2004 09:43:30 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZBT-0005ir-Su for dhcwg@ietf.org; Thu, 08 Jul 2004 09:43:31 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiZAY-0005OQ-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:42:34 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BiZ9W-0004lg-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:41:30 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2004 06:42:06 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i68Deu4N023549; Thu, 8 Jul 2004 06:40:56 -0700 (PDT)
Received: from volzw2k (rtp-vpn2-158.cisco.com [10.82.240.158]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AJZ20184; Thu, 8 Jul 2004 09:40:54 -0400 (EDT)
From: Bernie Volz <volz@cisco.com>
To: 'Mayumi Yanagiya' <yanagiya.mayumi@lab.ntt.co.jp>, dhcwg@ietf.org
Subject: RE: [dhcwg] identifier for key selection
Date: Thu, 08 Jul 2004 09:42:00 -0400
Organization: Cisco
Message-ID: <002501c464f1$58cccfd0$6401a8c0@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <40ED2E92.5070108@lab.ntt.co.jp>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

>I want to authenticate not hardware but user.

Well, DHCP is the Dynamic Host Configuration Protocol. In many cases when
DHCP starts there is no user (yet), or DHCP is being used by systems that
are multi-user. But, I understand your desire to do this. And, there's
always the ability to define additional authentication protocols.

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Mayumi Yanagiya
> Sent: Thursday, July 08, 2004 7:23 AM
> To: Bernie Volz; dhcwg@ietf.org
> Subject: Re: [dhcwg] identifier for key selection
> 
> 
> Hello Bernie,
> 
> Thank you for your comments.
> 
> Bernie Volz wrote:
> 
> > Hi:
> > 
> > Regarding the first question:
> > 
> > As defined in RFC 3315:
> > 
> >       DHCP realm                A name used to identify the DHCP
> >                                 administrative domain from 
> which a DHCP
> >                                 authentication key was selected.
> > 
> > So, both the realm and the client's DUID would be used to 
> obtain the 
> > key. If the received realm doesn't match the server's or one of the 
> > server's, the server needn't bother looking for a key?
> > 
> > Instead, it might send its realm to the client in an Advertise?
> 
> I see.
> 
> > Regarding the second, where do you want to put this identifier? The 
> > Client Identifier must be a DUID that follows one of the 
> formats given 
> > in the document. New formats could be defined. The Client 
> Identifier 
> > is supposed to represent the client (hardware), not the 
> user (though 
> > often there is only one user for each client). There's also the 
> > possibility of defining new options to carry user, subscriber, etc 
> > information similar to what has been done for DHCPv4 (see 
> the various 
> > Relay Agent suboptions).
> 
> I want to authenticate not hardware but user.
> Because, when we authenticate user, users are allowed to 
> change hardware 
> without reporting the change to administrator. I think that 
> it is very 
> convenience for user and administrator.So I'm looking for an 
> identifier 
> that I can use as user identifier.
> 
> When I use suboption such as subscriber-ID specified in 
> draft-ietf-dhc-subscriber-id-06.txt,can I use the suboption to select 
> the client's key?
> 
> 
> Thanks,
> --Mayumi
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg