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

Non-member submission from ["Narayanan, Vidya" <vidyan@qualcomm.com>]



 


 

-----Original Message-----
From: owner-aaa-doctors@ops.ietf.org
[mailto:owner-aaa-doctors@ops.ietf.org] 
Sent: Wednesday, September 20, 2006 9:10 PM
To: aaa-doctors-approval@psg.com
Subject: BOUNCE aaa-doctors@ops.ietf.org: Non-member submission from
["Narayanan, Vidya" <vidyan@qualcomm.com>] 

From vidyan@qualcomm.com Wed Sep 20 18:10:21 2006
autolearn=ham 
	version=3.1.1
[129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
k8KIAA5k012202
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=FAIL);
	Wed, 20 Sep 2006 11:10:12 -0700
[129.46.134.172])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
k8KI8mAD012036;
	Wed, 20 Sep 2006 11:10:07 -0700 (PDT)
NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 20 Sep 2006 11:09:59 -0700
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New Radius/Diameter authentication and key delivery for
FMIP application
Date: Wed, 20 Sep 2006 11:09:58 -0700
Message-ID:
<C24CB51D5AA800449982D9BCB90325131A285C@NAEX13.na.qualcomm.com>
In-Reply-To: <tslzmcu7ejl.fsf@cz.mit.edu>
FMIP application
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: "Sam Hartman" <hartmans-ietf@mit.edu>, "Jari Arkko"
<jari.arkko@piuha.net>
Cc: "AAA Doctors" <aaa-doctors@ops.ietf.org>,
        "Russ Housley" <housley@vigilsec.com>, <dromasca@avaya.com>,
        <david.kessens@nokia.com>, <mipshop-chairs@tools.ietf.org>
FILETIME=[FC4F21E0:01C6DCDF]

Hi Sam,
It is not a matter of whether Kerberos can do this - it surely can. It
is a matter of what systems we are targeting and whether Kerberos is
deployed there. And, in the systems under consideration, Kerberos is not
typically supported (not at the AR or deeper in the network) and not
even required at the end hosts.=20

So, a kerberos-based approach, while perfectly capable of providing a
solution, will simply not work for the systems under consideration.=20

Thanks,
Vidya

> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20
> Sent: Wednesday, September 20, 2006 8:18 AM
> To: Jari Arkko
> Cc: Narayanan, Vidya; AAA Doctors; Russ Housley;=20  
>dromasca@avaya.com; david.kessens@nokia.com;=20  
>mipshop-chairs@tools.ietf.org
> Subject: Re: New Radius/Diameter authentication and key=20  delivery 
>for FMIP application =20 =20 =20  I'd actually like to see if we can 
>get someone from the=20  Kerberos space involved to look at the 
>proposal because it=20  seems like it is duplicating a lot of the 
>mechanisms from=20  both Kerberos and Kerberos cross-realm.
>=20
> I see that as potentially problematic for two reasons. =20  First, I'd

>rather not have a new authentication protocol if=20  we don't need one.
>=20
> Second, and more importantly, I want to make sure that if=20  radius 
>and diameter are going to get involved in these=20  transactions, and 
>if this is duplicating a lot of the work of=20  Kerberos, we at least 
>do as good of a job as Kerberos.
>=20
> So, my recommendation is that we recruit a review from the=20  
>Kerberos community to look at two separate questions:
>=20
> 1) Could parts of Kerberos be reused.
>=20
> 2) If for whatever reason we choose not to reuse Kerberos, what are
>    design principles we should take away from it.
>=20
>=20