Subject: Re: [mobile-ip] IESG feedback on AAA keys doc

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 08 Oct 2001 18:42:54 -0700

Hello folks,

After a few weeks of discussion, I have prepared a new
version of the document, "AAA Registration Keys for Mobile IP".
Except for proofreading, it's almost ready to be sent in as a
revised Internet Draft, and it's available at:
	http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt

I'll hold off for a little while, in case someone can tell me how
to resolve the IESG comment about security algorithm IANA namespaces,
which to expedite discussion I have moved first in the discussion
below, but which is out of order from the original e-mail from the
IESG.

Here, starts the follow-on from the IESG comments.

>>       Algorithm Identifier
>>                  This field indicates the algorithm to be used for
>>                  future computations of the MN-FA Authentication
>>                  Extension (see section 3)
> 
> It would be good to state explicitely state that this is the same
> algorithm identifier as defined in XXX (section 3 doesn't seem to do
> this either). This document doesn't say. I.e., this presumably points
> to an existing name space managed by IANA. What is it? [hmm I later
> see that this is a new name space.. see comment below.]

I am happy to use another existing name space, but the only
one I find doesn't have HMAC-MD5 in it:

========================================================================
  Hash Algorithm                     Value            References
  --------------                     -----            ----------
  MD5                                  1               [RFC1321]
  SHA                                  2              FIPS 180-1
  Tiger                                3              See Reference [TIGER]
  SHA2-256                             4                 [Leech]
  SHA2-384                             5                 [Leech] 
  SHA2-512                             6                 [Leech]
========================================================================

Should we define some more values?  How do I find out the up-to-date
list?  Is this list being actively maintained?  If we use this list,
do we have to wait until someone actively figures out the right way
to keep this list up-to-date (assuming that it is not now). (***)

............  (now, from the top) ..............

> This is a comment that probably applies to lots of MIP
> documents. Please define "security association" in the MIP context. In
> IPsec terminology, for instance, it means something very
> specific. I.e., keys, SPIs, etc., and works only between a pair of
> nodes. Once an association exists, encrypted packets can be sent. No
> further negotiation is needed. Also, one can have multiple (different
> SAs between the same set of machines). This document says:
> 
>    node and its home agent.  When the mobile node shares a security
>    association with its home AAA server, however, it is possible to use
>    that security association to create derivative security associations
>    between the mobile node and its home agent, and again between the
>    mobile node and the foreign agent currently offering connectivity to
>    the mobile node.  This document specifies extensions to the Mobile
> 
> The MN talks to its HA, not a AAA server. So I'm not clear what is
> meant by "shares a security association". From my perspective, it
> seems like "security relationship" would be more accurate terminology.

The mobile node is expected to produce authentication data according
to the security algorithm configured for its use with AAA.   I think
this corresponds exactly with the typical use of the terminology.
A security relationship would be more general than is intended here.
But since I don't know exactly what that term means, it's hard to
be sure.  Maybe the security relationship is the thing that precedes
and enables the creation of the security association.

> Note that the above paragraph also talks about "security associations"
> between the MN and HA. Here, the terminology  (I suspect) corresponds
> more closely to the IPsec usage. But I'm not sure.

I've included a Terminology section.  I hope this isn't opening another
huge can of worms, but I'm very happy to accept suggestions on how
to make appropriate and succinct defintions.

> General comment. This document is very loose about whether a MN is
> talking to a FA/HA or a AAA server. This should be made explicitly
> clear throughout. Indeed, my assumption is that conceptually, if not
> in reality, a MN NEVER speaks to an AAA server directly. Rather, it
> speaks MIP protocols with an HA/FA, and that HA/FA has a side
> conversation with the AAA server. This should be made much more clear
> throughout.

O.K.  I will try to do this.

>> 2. Scope of Protocol
>>
>>    The protocol and messages in this document are intended to facilitate
>>    the following operations which may occur between the mobile node, AAA
>>    server, home agent, and foreign agent.
> 
> Throughout this section, it should be made explicitly clear *who* is
> sending a message, and *to* *whom* the message is being sent. Also,
> when someone processes an extension *who* is doing the
> processing. This isn't clear from just reading the text.

I'll give it a shot.  Let me know if I succeed -- or fail.

> Also, it might make sense to change the section heading to "overview"
> rather than Scope, since it does seem like an overview. Assuming this
> is an overview, I think it would help the reader if the text included
> steps such as as "FA sends message to AAA server ..." "AAA server does
> X and returns Y to the FA", "FA generates reply and sends to MN"...

O.K.  I have attempted to do this.

>     2. If the mobile node does not have a Mobility Security Association
>        with the foreign agent, it SHOULD include an MN-FA Key Request
>        extension.
> 
> In what message, and sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

> What is the RFC reference to the key request extension?

It's defined later in the document.  I've added a cross reference.

>     3. Similarly, if the mobile node does not have a Mobility Security
>        Association with the home agent, it MUST add an MN-HA Key Request
>        extension.
> 
> In message sent to whom?

As part of its Registration Request that it sends to the Foreign Agent.

>     4. If one or more Key Request extensions were added, the MN-AAA
>        Authentication extension is added to the Registration Request.
> 
> Added by whom?

The mobile node.

>     5. At the time the information within the MN-AAA Authentication
>        extension is verified by the AAA server, the AAA server also
>        generates Key Material for the keys requested by the mobile node,
>        and causes insertion of the Key Material fields along with the
>        Registration Reply.
> 
> So there is an implied step here in which the FA exchanges messages
> with its local AAA server? Would be good to explicitely say that here.

I have made it more explicit.

> Is that AAA protocol already in place? What RFCs are used? I.e, is
> there a potential normative reference problem buried here? (I suspect
> the answer is no, but am not sure.)

The intention was to keep the formulation general, and not dependent
on the specifics of the AAA protocol.

>     6. The respective AAA keys are distributed to the Home and Foreign
>        Agent via the AAA protocol.
> 
> Where are the details of this described?

It is out of scope for this document, and I hope it does not have
to be specfied as part of a normative reference.  All that we
should have to do is to specify how the Mobile IP extensions work.

According to this philosophy, some of the steps in the Overview
amount to over-specification, but I don't think there is any
serious problem so O.K.

> step 6b) FA sends a reply to the MN
> 
>>    extension.  In order for the mobile node to make use of key
>>    information sent to it by the AAA server, the mobile node also has to
>>    be able to select the appropriate cryptographic algorithm that uses
>>    the key to produce the authentication.  The following table contains
> 
> I doubt the AAA server is sending messages to the MN. Isn't it the FA
> that does this (i.e., it relays this info)? Text could be more
> precise.

I reworded this to say that the AAA server "creates" the
key information.

>    Dynamic Mobility Security Associations shared between mobile nodes
> 
> What is a "Dynamic Mobility Security Association"? Is it different
> than other types of security associations?

Well, it's not manually configured.   Isn't this well-known usage?
Do we have to say "dynamically created"?  Otherwise, it is the
same as the mobility security association defined in RFC 2002.

> Note: IMO, it would be better to move the description formats of the
> extensions here, rather than at the end. It is a bit confusing to talk
> about the contents of packet fields prior to having shown the format
> of the option with all of the fields together.

I didn't see where the packet fields were mentioned.  We used
the name of some extensions that were defined in RFC 2002.
The tables supply parameter values for some fields in the
extension formats, but that's as close as I could get to
understanding your request here.  Maybe we should move the
tables after the formats?

>> 4. Key Material Creation and Derivation
>>
>>    This section contains the procedures followed in the creation of the
>>    Key Material by AAA servers, and the key derivation procedures used
>                                 ^
>>    by mobile nodes.  Note that the AAA servers will also make use of the
> 
> insert "extension" as indicated above? Also, better to say "contains
> the procedure a FA/HA follows when creating ..." (or is the procedure
> aimed at AAA servers?)

The procedure is aimed at AAA servers, and I couldn't parse the result
when I put "extension" where you indicated.  The idea is that AAA
servers will do something that is able to be understood by mobile
nodes, and that mobility agents (home agent, foreign agent) will
faithfully transcribe the results into the appropriate Mobile IP
extensions.  I have added those words to this introductory
paragraph.  It is still intended to avoid normative references
here for any AAA protocol.  If necessary, we could create an
applicability statement and use it along with the introductory section.

>    The example that follows makes use of MD5 in prefix+suffix mode,
>    whose support is mandatory in Mobile IP [11].  Other cryptographic
>    functions, such as those listed in 3 MAY also be used.
> 
> Might be better to make HMAC-MD5 the example. Also, what is meant be
> "listed in 3 MAY". Should that be "listed in [3] MAY"??

That was supposed to be Section 3.

>     1. The AAA server identifies the mobile node's via a
>        ``node-address''.  If the Home Address field of the
>        Registration Request is zero (0), the Mobile Node's NAI is used
>        instead.
> 
> First sentence doesn't parse.

Fixed!

> I'm confused by the description above in the sense that it implies
> that the MN Registration Request is sent to a AAA server. I thought it
> was sent to a FA.

Here, one has to understand the contents of RFC 2977.  I have added
a lot of text to that effect in the Introduction.  I hope that's
sufficient.  Otherwise, we would have to start copying text from
that document.

> Also, why use the term "node-address"? Don't you really mean the home
> address? (the term node-address isn't defined anywhere).

Fixed.

>  Maybe you mean to say:
> 
>     1. The AAA server identifies the mobile node via a
>        ``node-address''.  The node-address is taken from the Home
>        Address field of the Registration Request, or the NAI, if the
>        Home Address field is zero (0).
> 
> Note again how the text blurs the distinction between the FA and the
> AAA server. Does the AAA server see the registration request? I would
> think not. It sees information the FA sends to it, which includes
> portions of the registration request. The document should really make
> this clear throughout

I fixed this, I hope.  I also hope it would be clear to someone
who went through the discussion in RFC 2977.

>>    2. The AAA server generates a random [5] value of at least 64 bits.
> 
> 64 bits seems short. I'd like someone with security background to
> comment on this. But I guess this is sent in the clear, so the length
> may not matter?

That makes sense to me.

>     3. The AAA server inserts the random value into the Key extension in
>        the ``Key Material'' field.
> 
> Presumably this field is part of a message or an extension within a
> message. Which message or extension? Make explicit.

The example is supposed to work for any Key Material extension.

> Note steps 1-3 are done on the server, steps 4-5 on the mobile
> node. It might be good to make the more clear here, perhaps by having
> subsections?

O.K.  I did it, but I don't know if it's an improvement or not.

>     4. The mobile node calculates
> 
>           key = MD5(AAA-key | Key Material | node-address | AAA-key)
> 
> what is AAA-key? Where does it come from? Ditto for "Key Material" How
> does the mobile node know which AAA-key to use? Can there only be one
> (I hope not...)

The AAA-key is what the mobile node shares with the AAA server.
The Key Material is the 64 random bits.

>       Key Material
>                  A random [5] value of at least 64 bits.
> 
> Keying material of only 64 bits? Would this pass security muster??

I reckon it will, but I'm not betting my house on it.  The cryptographic
strength of the algorithm doesn't depend on this number.

>>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
>>                  mobile node must use to determine the algorithm to use
>>                  for establishing the FA security information.
> 
> How does the mobile node create this SPI? Is this preconfigured?

Yes, or at least out of scope for this document.

>>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the FA security information after it is decoded.
> 
> Might be better to say something like:
> 
>        FA SPI     The SPI for the Security Association to the FA that
>                   the MN creates as a result of processing this extension.

Done.

>>    The Unsolicited MN-FA Key Material From AAA extension, shown
>>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
>>    Extension [12].
> 
> Shouldn't this be moved to the beginning of section 5. (e.g., as it is
> in Section 6?)

Done!

>>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
>>                  to index all the necessary information established for
>>                  the HA security information after it is decoded.
> 
> Same comment as above w.r.t FA SPI. Ditto for key material.

Done.

>>    the Key Material provided by the home domain AAA server (AAAH). The
>>    key is intended for use the mobile node to secure future Mobile IP
>>    registrations with its home agent.  The MN-HA Key Reply MUST appear
> 
> sentence doesn't parse.

Fixed.

>>    The mobile node uses the Identification field data from the
>>    Registration Request as its initial synchronization data with the
>>    home agent.
> 
> What is the field referred to in this sentence?

If you look at the Registration Request format, there is a field
called the Identification field.  It allows entities using Mobile IP
to associated a Registration Reply to the appropriate Registration
Request.

I don't know if you meant to suggest adding text or not, but I wouldn't
feel it was appropriate to copy text from RFC 2002{,bis} here.

>> 7. MN-FA Key Request From AAA Subtype
>>
>>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
>>
>>
>> 8. MN-HA Key Request From AAA Subtype
>>
>>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
>>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
>>    From AAA extension MUST appear in the Registration Request before the
>>    MN-AAA Authentication extension.  The subtype data field is zero in
>>    length.
> 
> Hmm. What are the above two sections about? The first sentence in each
> seems redundent. Can't the remaining text just be put in the previous
> sections that describe the extension?

The extensions, which are Request extensions (not Reply extensions),
are defined in the Generalized Keys document, and don't have any
additional format that needs to be specfied.

> Also, why is the ordering important?

The MN-AAA Authentication extension is an "authorization-enabling"
extension, in the language of RFC 2002bis.  Such extensions have
to be last.

>> 10. IANA Considerations
> 
> This document requests certain numbers be assigned. Is this required,
> i.e., are their implementations that already use the numbers? This
> section should really say TBD for any assignments that it  doesn't
> care what the  actual value is, and let IANA pick. If it really does
> care about the value, the text should suggest a certain value be used
> and mention that the numbers are already in use by existing
> implementations. That way, IANA has some context for deciding what to
> do.

The numbers are already in use by implementations.   I have added text
to the IANA Considerations to that effect.

>>    Section 3 introduces the Algorithm Identifier namespace that requires
>>    IANA management.  This specification makes use of 1-3; all other
>>    values other than zero (0) are available for assignment, pending
>>    review and approval by a Designated Expert [9].
> 
> Can't you just leverage off an existing MIP name space (i.e, the one
> used by other extensions?) rather than creating a new one?

See above (***).

Regards,
Charlie P.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 10 Oct 2001 18:28:33 +0200

Thanks Charlie,
the draft look a lot better, However there are still some questions.

Section 2 second bullet.
"2. If the mobile node does not have a Mobility Security Association
       with the foreign agent, it SHOULD include an MN-FA Key Request
       extension 7 as part of its Registration Request that it sends to
       the Foreign Agent."

it SHOULD include an MN-FA Key Request extension 7 as part...
what do you mean by extension 7, I guess it has something to do
with subtype 7, defined where?

Section 2 bullet 3.
same applies here for MN-HA Key Request extension 8...

section 2 bullet 8.
"8. If the Reply passes authentication and contains the Unsolicited
       MN-HA Key Material From AAA extension (see section 6), the mobile
       node generates the key using the Key Material provided, according
       to its security association with the AAA. The resulting key is
       used to establish the mobile node's security association with its
       home agent, and is used to authenticate the MN-HA authentication
       extension."

If the reply passes authentication... the mobile node generates the key
using the Key Material provided...

The key has to be generated first in order to verify authentication since
the key is used in the verification process.

Section 3.
SHA-1 is missing in the table, in 08.txt it was SHA-1 but I believe it
should
be HMAC-SHA-1 that should be used.

Section 4 last paragraph.
"The AAA-key used here is the key that has been previously configured
   as the basis of the security assocation between the mobile node and
   the AAA server creating the key."

The AAA-key used is the one pointed to by the AAA SPI, i.e. the AAA SPI
points
to what algorithm to use and what key to use to create the key.

IANA Considerations.
The number 7 is assigned to several of hte subtypes. Both MN-FA and MN-HA
Key
Request from AAA Subtype. Probably a cut'n'paste error

/Fredrik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 10 Oct 2001 11:02:49 -0700

Hello Fredrik,

Thanks for your comments.

> same applies here for MN-HA Key Request extension 8...

These were meant to be cross-references to the appropriate
section, not type numbers!  I've fixed this now.

> the key is used in the verification process.

Good point!   I have reworded this paragraph.

> be HMAC-SHA-1 that should be used.

O.K.  I made an entry in the table for both SHA-1 and HMAC-SHA-1.
However, this may become a moot point, depending on what is decided
about where this table should most appropriately be specified.

Maybe the right thing to do is to delete the table, and ask for
some new numbers to be allocated in the IKE table.  What do you
think we should do?  Shouldn't we also add something for AES and
maybe for the recently mentioned PRF variants?  But why should
Mobile-IP be in charge of such a table?

> to what algorithm to use and what key to use to create the key.

Thanks.  I made the clarification you suggested, while also keeping the
more explanatory text.  I could also delete the explanatory text if
you think that would be better.

> Request from AAA Subtype. Probably a cut'n'paste error

These numbers were supposed to be whatever was already in use.
They could both be 7, since they are subtypes of different
generalized extensions.  However, if there isn't any real
problem with changing the numbers, then we probably ought to
leave it as TBD, and let IANA pick the numbers.  What do you
think?

Regards,
Charlie P.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 11 Oct 2001 17:40:53 +0200

Thanks,

see coments inline

/Fredrik
>Mobile-IP be in charge of such a table?

How do you mean when you say allocate new numbers in the IKE table? do you
mean
reuse the numbers already specified for these algorithms in some other table
or to use another table and just specify that table in this draft.

I believe that by having a table in the aaa-key draft we can easier prohibit
some
algorithms to be used (e.g. if they are considered unsecure, btw,
is md5-pre/suff considered safe? or should/can we remove it?) On the other
hand
it's harder to add new algorithms and it's yet another table to maintain.
I'm not realy sure what's best.

>you think that would be better.

I believe it's good to have some explanatory text

>leave it as TBD, and let IANA pick the numbers.  What do you

We can probably leave them as TBD, the only implementations available should
be a limited number of prototypes (as far as I know)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Oct 2001 09:53:53 -0700

Hello Fredrik,

Some minor clarification here, and follow-on comments.
Plus, a solution may be available, thanks to some mail from
Phil Roberts.

> mean reuse the numbers already specified for these algorithms in some other
> table or to use another table and just specify that table in this draft.

I meant the latter.

> some algorithms to be used (e.g. if they are considered unsecure, btw,
> hand it's harder to add new algorithms and it's yet another table to maintain.

On general principles, with everything else being equal, I would always
prefer to use a pre-existing table.  This is even more true when the
items to be tabulated are properly in the domain of another working group.
However, in this case, not everything else is equal:
- The tabulation has to include HMAC-MD5, since that is mandated
- The tabulation has to be "live", which means that it's a table
  which has not been obsoleted for some reason.
- There has to be some reasonable expectation that as our needs
  change, the table can be updated

The original table I found was in:
	http://www.iana.org/assignments/ipsec-registry
It does not have HMAC-MD5.

Phil pointed me to tables in IANA's registry for ISAKMP:
	http://www.iana.org/assignments/isakmp-registry
Turns out there are _two_ relevant tables there.
One is a list of "Transform ID"s for AH:

==================================================================

Transform ID            Value                           Reference
------------            -----                           ---------
RESERVED                0-1                             [RFC2407]
AH_MD5                  2                               [RFC2407]
AH_SHA                  3                               [RFC2407]
AH_DES                  4                               [RFC2407]
AH_SHA2-256             5                                 [Leech] 
AH_SHA2-384             6                                 [Leech]
AH_SHA2-512             7                                 [Leech]
AH_RIPEMD               8                               [RFC2857]

==================================================================

That does not have HMAC-MD5.

The other table at the same URL is a list of Authentication
Algorithms allowable as values for the "Attribute Type" (5)
(i.e., "Authentication Algorithm").  Type (5) is one of the
classifications in the tabulated Attribute Types for
"IPSEC Security Association Attributes".

=================================================================

  Authentication Algorithm

        Name            Value                   Reference
        ----            -----                   ---------
        Reserved        0                       [RFC2407]       
        HMAC-MD5        1                       [RFC2407]       
        HMAC-SHA        2                       [RFC2407]       
        DES-MAC         3                       [RFC2407]       
        KPDK            4                       [RFC2407]       
        HMAC-SHA2-256   5                         [Leech]
        HMAC-SHA2-384   6                         [Leech]
        HMAC-SHA2-512   7                         [Leech]
        HMAC-RIPEMD     8                       [RFC2857]    

=================================================================

This table has HMAC-MD5.  I think that maybe it could also
fulfill the other needs - basically for future extensibility
and continued compatibility with the need for authenticating
registration messages as part of the extensions in our document.

My current suggestion is that we use this table, and delete the
new table specification from within the AAA keys draft.  But, I am
really neutral, and I only make the suggestion as a positive
response to the IESG feedback which we have received.  I will
happily do whatever others suggest here.

In case this all seems to be tedious and hard to follow, my
apologies.  I don't know how to make a clearer explanation.
If anyone here knows why there are three different but seemingly
related tables of the "same thing" (with different entries),
I would be curious to know the answer.

Regards,
Charlie P.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 12 Oct 2001 15:24:42 +0200

Hi Charlie,

I agree that not specifying a specific MIP table would be the best.
However, the IPsec DOI doesn't support md5 prefix/suffix mode, can 
we get ride of this?

If so, we can probably use the IPsec DOI as a normative reference

/Fredrik

---

From: FUKUMOTO Atsushi <[email-masked]>
Date: Fri, 12 Oct 2001 15:34:20 +0900

> One is a list of "Transform ID"s for AH:

I wasn't following this discussion closely, so, please forgive me if
I'm missing point.  To specify a security association for AH, you MUST
specify Authentication Algorithm attribute along with Transform ID.
AH_MD5 for Transform ID and HMAC-MD5 for Auth Alg means HMAC-MD5-96.
AH_MD5 for Transform ID and KPDK for Auth Alg means Keyed MD5.

(It is for historical reason, I believe...  When ESP incorporated
authentication, ISAKMP needed Auth Alg negotiation.  Then found the
KPDK is weak and HMAC should be used, so Auth Alg is used for AH to
choose KPDK and HMAC.)

I think an algorithm and a protocol definition should be distinguished
more clearly.  For example, RFC2104 defines HMAC algorithm.  RFC2403
defines HMAC-MD5-96 as a part of communication protocol using HMAC and
MD5 funciton algorithm.  That means I think Mobile-IP specification is
slightly ambiguous about it, although it was minor enough that it did
not cause interoperability problem, I guess.

					FUKUMOTO Atsushi
					[email-masked]