Subject: [Dime] New version of draft-wu-dime-local-keytran

From: "Glen Zorn" <[email-masked]>
Date: Tue, 8 Dec 2009 12:08:27 -0800

FYI, http://www.ietf.org/id/draft-wu-dime-local-keytran-03.txt has been
posted; we think that all outstanding comments have been addressed.

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 09 Dec 2009 11:06:58 +0900

Hi Glen, Qin, all,

By quickly looking into the new version, a few additional comments came
to my mind:

In section 3.1, I would like to propose a change to the ABNF. I think
the Key-Type AVP should be in a fixed position (actually I was under the
impression that this was already decided, but anyway), like this:

   Key ::= < AVP Header: AC1 >
             < Key-Type >
             ...

In section 3.1.1 (definition of Key-Type AVP), I think some of the
defined values should be removed, as follow:
- rMSK (4) : As I understand, there is no difference between rMSK and
MSK, so we may not need a different type for this one ? (not sure)
- USRK (2) & DSUSRK (5): RFC5295 defines a generic algorithm to derive
usage-specific keys. The definition alone is not sufficient to create
keying material: we need the usage itself to define the missing parts.
Therefore, having a "USRK" or "DSUSRK" container is pointless, it does
not allow the recipient to understand what is in the key. On the other
hand, rRK and rDSRK make sense, since ERP defines completely the
algorithm (they are instances of USRK and DSUSRK). Anyway, I guess it
would make more sense that the rRK and rDSRK values are assigned in the
registry by Diameter ERP document, if needed. But this is not very
important. As a summary, I believe an initial version the document
should only define MSK and DSRK Key-Type values.

I section 4, maybe a bit of explanation about the Key-Type and Key-Name
AVPs inside DER / DEA would be useful. From the remaining of the
document, I had only guessed that the Key AVP could be present in DEA,
and nothing about the other ones.

I believe the "Security Considerations" section should also reference
RFC5295's security section, especially Section 7.4 (Key Distribution),
and mention that Diameter honors these security requirements. It should
also mention that different key usages may have stronger security
requirements, that must be carefully considered before using the
mechanism defined in this document.

That's all I have for the moment :) Sorry for the long mail!

Best regards,
Sebastien.

Glen Zorn a écrit :
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 09 Dec 2009 11:13:47 +0900

Hi again, sorry for replying to myself!

> and mention that Diameter honors these security requirements. 
Security considerations from draft-ietf-hokey-key-mgm-13 are also
important to mention IMHO.

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 8 Dec 2009 19:20:19 -0800

> MSK, so we may not need a different type for this one ? (not sure)

How would you deliver an MSK and rMSK in the same message, then?

...

---

From: Qin Wu <[email-masked]>
Date: Wed, 09 Dec 2009 11:41:11 +0800

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Glen Zorn" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 09, 2009 10:06 AM
Subject: Re: [Dime] New version of draft-wu-dime-local-keytran

Hi Glen, Qin, all,

[Qin]: The usages for USRK and DSUSRK have been defined in the section 4.2 of draft-ietf-hokey-key-mgm-13.
That is to say, USRK and DSUSRK may be derived in the EAP/AAA server and transported in the message to the same USR-KH.
And then DSUSRK can be further transported from USR-KH to DSUSR-KH.

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 09 Dec 2009 13:40:00 +0900

Hi Qin,

> That is to say, USRK and DSUSRK may be derived in the EAP/AAA server
> and transported in the message to the same USR-KH.
Sorry, I have difficulties to express my idea clearly. What I mean is
that for example the definition of USRK is just a generic method to
derive a class of keys, we will never have a "USRK key" without any
precision on the usage it-self (usage as in the "US" part of USRK). On
the other hand, rRK is an instance of this class, where the algorithm
parameters are specified in the ERP document, and we can effectively
have to transport rRK keys. As I understand draft-ietf-hokey-key-mgm-13,
that document is also talking about generic mechanisms, that can be
applied for instance to the ERP specific usage.

Does this make my point more understandable?

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Wed, 09 Dec 2009 14:49:18 +0800

Hi,Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 09, 2009 12:40 PM
Subject: Re: [Dime] New version of draft-wu-dime-local-keytran

> applied for instance to the ERP specific usage.

[Qin]: According to draft-ietf-hokey-key-mgm-13, USRK and DSUSRK can be used in
Key Distribution Exchange Scenarios, that is to say EAP based key transportation is not limited for ERP
specific usage. Also I am not saying using of USRK and DSUSRK in the ERP scenario. I am wondering 
whether USRK and DSUSRK transportation can be used for other non ERP specific cases like Key Distribution 
Exchange Scenarios.