Subject: RE: [AAA-WG]: Issues 188, 189 and 190

From: [email-masked]
Date: Wed, 3 Oct 2001 10:18:25 +0300

Hello Glen,

Issue 190 (session master keys):

> > Perhaps the NASREQ document could simply say that the 
> > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as 
> > a session master key from which the NAS derives the actual 
> > cipher keys (integrity keys). 

> From: ext Glen Zorn [mailto:[email-masked]]
> I think that that goes w/o out saying.

I don't think this is obvious especially regarding the transport of
a session master key from which IV's are derived. I'd still like to 
have a clarification that says this explicitly.

Issue 188 (ciphersuite negotiation):

> From: ext Glen Zorn [mailto:[email-masked]]

> I think that this is a red herring: it doesn't matter if the 
> ciphersuite is
> negotiated _after_ authentication, because the Diameter 
> server is _telling_
> the NAS or AP which ciphersuite to choose.

OK, I can see this can be done with ECP and possibly with
other ciphersuite negotiations. But it still doesn't make sense
to include the key binding AVP if the keying material will be used
as session master keys.

Can we just we make the key binding AVP optional? Then it could 
be included when ciphersuite negotiation inside EAP has been 
performed, or when the keying material is intented for a certain
ciphersuite only, and omitted in other cases.

> "Even if the ciphersuite hasn't been selected, the AAA server
> can still transport keying material to the NAS in the
> NAS-Session-Key AVP. For example, it can include large
> session keys which the NAS can truncate as necessary for use
> with a given ciphersuite."
> 
> Isn't there more to it than just transporting & truncating 
> keying material,
> though?  For instance, DES, RC4 and other algorithms have 
> so-called "weak"
> keys...

I agree, weak keys can be a problem. It would be nice if the 
NAS and the client could handle them. If the AAA server 
transports enough keying material, maybe the NAS and the client
can check for weak keys and skip them when encountered. Some people 
think that the chance of picking a weak DES key is negligible.
If weak keys are so improbable, then maybe the NAS could even make 
the authentication fail if the transported key is weak. 

Issue 189 (initialization vectors):

> From: ext Glen Zorn [mailto:[email-masked]]
> I contributed some text a couple of weeks ago (see below) 
> that I think deals
> w/these concerns.
> 
> NAS-Session-Key ::= < AVP Header: 408 >
>                     { NAS-Key-Direction }
>                     { NAS-Key-Type }
>                     { NAS-Key-Binding }
>                     { NAS-Key-Data }
>                     [ NAS-Key-Lifetime ]
>                     [ NAS-IV ]
>                   * [ AVP ]
> <...>
> The NAS-IV AVP (AVP Code 410) is of type OctetString.  Its contents
> MAY be used as an initialization vector (IV) by cryptographic 
> algorithms
> (e.g., block ciphers).

I missed your contribution. It seems not to be included in 
the 08-alpha01 version of the NASREQ document either.

The NAS-IV AVP looks good to me, as long as it works for the 
session master key case as well.

Regards,
Henry

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 Oct 2001 08:55:55 -0400

I would prefer defining a new NAS-Key-Type value "MASTER_KEY" for
representing a session master key and not including the
NAS-Key-Binding AVP when the value of the NAS-Key-Type AVP is
MASTER_KEY.  It eliminates ambiguity and seems no harm.

Yoshihiro Ohba

At Wed, 3 Oct 2001 10:18:25 +0300 ,

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 3 Oct 2001 07:26:15 -0700

> MASTER_KEY.  It eliminates ambiguity and seems no harm.

Maybe it's just old age, but I fail to discern the ambiguity in the terms
"ENCRYPTION_KEY" and "INTEGRITY_KEY".  "MASTER_KEY", OTOH seems quite
ambiguous, meaning different things to different people at different times.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 3 Oct 2001 09:05:08 -0700

> have a clarification that says this explicitly.

I'm unfamiliar w/the practice of deriving IVs from secret material.  Since
IVs are often transmitted in the clear, could this not release information
about the master key itself?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 Oct 2001 15:13:23 -0400

At Wed, 3 Oct 2001 07:26:15 -0700,
> > > > I think that that goes w/o out saying.

Sorry for the nested quotation, but if master key itself is ambiguous,
I think the NASREQ document could not simply say that the CIPHER_KEY
or INTEGRITY_KEY can alternatively be used as a session master key.
So are you actually suggesting not using master key?

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 4 Oct 2001 04:00:16 -0700

> So are you actually suggesting not using master key?

What I'm saying is that just saying "MASTER_KEY" w/o further qualification
is by definition more ambiguous that saying either "ENCRYPTION_KEY" or
"INTEGRITY_KEY".  Furthermore, I can't find in the definition of the
NAS-Key-Type AVP any requirement (either explicit or implied) that the key
material therein be used w/o modification or any prohibition of the
derivation of other keys from that material.  So all I can see the
"MASTER_KEY" type adding is the ability to ship arbitrary stuff labeled
w/the cryptographic equivalent of "whatever".  This doesn't seem like a big
plus to me; however, if you insist upon it then I think that the language
around "ENCRYPTION_KEY" and "INTEGRITY_KEY" needs to be tightened up to
state the kind of usage restrictions the Henty seems to have inexplicably
(to me, at least) read into the existing definitions.  If we do that,
though, then we should probably add definitions for "MASTER_ENCRYPTION_KEY"
and "MASTER_INTEGRITY_KEY" as well...

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Oct 2001 08:09:29 -0700 (PDT)

> and "MASTER_INTEGRITY_KEY" as well...

What I think is needed here is some definition of what the "MASTER KEY" is
and how authentication/integrity, confidentiality, IV, etc. are derived
from it. We can then reference this spec, or at least agree that it will
be delivered later. 

I agree with Henry though that the present specification is not
workable. It is not appropriate to require modification of the AAA server
and EAP methods every time we get a new ciphersuite for a Diameter
application. So the keys passed by AAA & EAP need to be generic, and the
logic for converting master keys to specific keys needs to be present in
the NAS, not in the AAA server. This can include logic for checking weak
keys, truncation for the specific ciphersuite, etc. Presumably the NAS is
implementing the given ciphersuite, so it needs to have
ciphersuite-specific code anyway. The AAA server and EAP methods do not.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Oct 2001 11:32:05 -0400

Hello Glen,

At Thu, 4 Oct 2001 04:00:16 -0700,
> and "MASTER_INTEGRITY_KEY" as well...

Thanks for your clarification.  I understand from your standpoint
(i.e., clear separation of encryption key and integrity key) that
adding definitions for "MASTER_ENCRYPTION_KEY" and
"MASTER_INTEGRITY_KEY" is natural.  Anyway, I think the notion of
master key is needed for local re-keying between NAS and user host.

Here I have a question.  If the same key, which is either directly
provided by AAA server or indirectly derived from a master key, is
used for both message encryption and message integrity check, which
class should those keys be categorised into, encryption or integrity?
For example, keys used for 802.11i operating in AES-OCB mode are used
for both encryption and integrity check.

I think explicit statement would be helpful for how to deal with those
two-purpose keys.  Fixed categorization of those keys into encryption
key (or integrity key) is one possibily.  Defining new types such as
(MASTER_)ENCRYPTION_AND_INTEGRITY_KEY is another possibility.

Yoshihiro Ohba