[Dime] 答复: Questions regarding RFC6924 Diameter Support for ERP
Qin Wu <bill.wu@huawei.com> Thu, 10 April 2014 04:33 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D81A008B for <dime@ietfa.amsl.com>; Wed, 9 Apr 2014 21:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.816
X-Spam-Level: *
X-Spam-Status: No, score=1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ-ygiXLpbzD for <dime@ietfa.amsl.com>; Wed, 9 Apr 2014 21:33:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC41A0425 for <dime@ietf.org>; Wed, 9 Apr 2014 21:33:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCY10282; Thu, 10 Apr 2014 04:33:10 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 05:31:31 +0100
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Apr 2014 05:32:48 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 10 Apr 2014 12:32:45 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Avi Lior <avi.ietf@lior.org>, dime mailing list <dime@ietf.org>
Thread-Topic: [Dime] Questions regarding RFC6924 Diameter Support for ERP
Thread-Index: AQHPU+vPu85QOCj5+EC973FcklW1kZsKQmbQ
Date: Thu, 10 Apr 2014 04:32:44 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA845100B9@nkgeml501-mbs.china.huawei.com>
References: <53453724.9030009@lior.org>
In-Reply-To: <53453724.9030009@lior.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.114]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6dpxrO0Ig-VnqzOebuAmsWYbY6c
Subject: [Dime] 答复: Questions regarding RFC6924 Diameter Support for ERP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 04:33:18 -0000
rRK is equivalent to rDSRK, See section 2:
"
The re-authentication Domain-Specific Root Key (rDSRK) is a
re-authentication Root Key (rRK) [RFC6696] derived from the Domain-
Specific Root Key (DSRK) instead of the EMSK.
"
RFC6942 support transportation of rDSRK. When ER server change, new rDSRK needs to be generated and transported to the new ER server.
The peer in RFC6696 is referred to ER client not Diameter Peer.
Regards!
-Qin
-----邮件原件-----
发件人: DiME [mailto:dime-bounces@ietf.org] 代表 Avi Lior
发送时间: 2014年4月9日 20:04
收件人: dime mailing list
主题: [Dime] Questions regarding RFC6924 Diameter Support for ERP
Hi folks
I was reading 6696 and 6924 (it's been awhile) and I need clarification:
1) It appears that 6924 does not support transportation of DSRK key.
Only rRK and rMSK. Is that correct?
2) According to RFC 6696 - section 4.2:
RFC 6696: Section 4.2:
o The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity.
So why is 6942 transporting the rRK around?
Avi Lior
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime