Subject: [AAA-WG]: Issue 91: MIP SPI

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 25 Jun 2001 11:10:13 +0200

Submitter name: Martin Julien
Submitter email address: [email-masked]
Date first submitted: 25-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html
Document: mobileip-06
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Requested change:

> > 18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the
> > aaa-key-06 draft? BTW, would it be better that the values assigned to
> > those algorithms match between the 2 drafts? The last comment also
> > applies to the Replay-Mode.
>
> yes, but it really don't matter if there isn't a match. If you think it
> would be useful, include it in your issue.

Not really, it was only a comment. The thing is that since the values in
the Diameter MIP-06 draft are based on the ones defined in the other
document, I thought it would be better to keep the values consistent,
but of course, it does not have to be like this, strictly speaking.

> > 11) If there is a problem in the HA or FA with the SPI generated by
> > the AAAH or AAAF, how could that be reported?
>
> reported by whom? The HA? Or one of the AAA servers?
>
> > 16) Whenever no MIP-*-Preferred-SPI AVP is included in the AMR, can we
> > assume that the SPI generated by the AAAH or AAAF can be completely
> > random or not? Why can't the HA decide the SPI itself?
>
> There's no reason why, really :(

I'm still not quite sure to get the complete picture of how the SPI should
be
handled in the AAA servers. Are we expecting the AAA servers to use the
standard 0-255 SPI defined by IANA?, or are the AAA servers expected to
handle to concept of SA, which normally contains and defines their own
SPI values?

As defined in RFC 2002 (MIP):

      Mobility Security Association
               A collection of security contexts, between a pair
               of nodes, which may be applied to Mobile IP protocol
               messages exchanged between them.  Each context indicates
               an authentication algorithm and mode (Section 5.1), a
               secret (a shared key, or appropriate public/private
               key pair), and a style of replay protection in use
               (Section 5.6).

      Security Parameter Index (SPI)
               An index identifying a security context between a pair
               of nodes among the contexts available in the Mobility
               Security Association.  SPI values 0 through 255 are
               reserved and MUST NOT be used in any Mobility Security
               Association.

I believe that MIP is using the standard CHAP_SPI, when using RADIUS, right?
Should the Diameter server follow the same path or not? I guess not, since
the key AVPs would not contain the MIP-SPI, the algo and the Replay-Mode,
right?

The thing is
that if Diameter needs to support the concept of SA, then it seems to
be difficult for the AAA server to select an SPI on behalf of the MN, the HA
and the FA. Of course, the AAA can count on the Preferred-SPI from the FA
and the MN, in which case the AAA simply agrees with the value. However,
if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to
generate
them, at the risk that they might already be used in the SA defined between
the MN and the HA, or between the HA and the FA, or between the FA and the
MN.
I think that it makes more sense for the HA to select the required SPI
between
the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR.

I guess that the MIP-Foreign-Agent-Host AVP could be useful for creating
the SPI within the SA defined between the HA and the FA.

> > Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess
> > that the FA has chosen a value that what not already already by any
> > of the SAs, right? The thing is that it might not know the HA yet,
> > i.e. the SA.
> >
> > 19) Section 6.1, could you please explain to me what "The Mobile IP key
> > described in [15] refers to the AAA SPI, which MUST be set to the value
> > the AAAH shares with the Mobile Node." Are we talking about a
> > pre-configured shared SPI, or a secret key? Can it dynamically change
> > or not? It is not clear to me how the AAA SPI can help in creating the
> > FA or HA Security Information. Could you please tell me more?
>
> I'd love to explain it, but that would require that I first
> understand it :(
>
> I believe that what I had originally intended to state here is that the
> values created are used in a particular field of the MIP AAA key in [15].
> This needs some major cleaning up.
>
> Thanks,
>
> PatC
>

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 26 Jun 2001 13:45:56 -0700

> but of course, it does not have to be like this, strictly speaking.

hmmmm... I should have read this closer :( SHA-1 is used to encrypt the
session keys, as defined in the aaa-key-06 draft. The transforms listed 
in section 6.2.7 are used to generate the authenticator portion of 
the relevant authentication extension.

So, no change is required. Sorry I missed that one when I first responded :(

btw, -04 (I believe) was changed considerably, and I believe that your
confusion is that you didn't catch all of the changes that occured from -03.

> handle to concept of SA, which normally contains and defines their own

yes, the AAA creates the SPI values used for an SA. The SPI number provided
in the *Preferred-SPI AVPs are recommendations from the Diameter agents on
what values they'd like to see, to minimize the possibility of conflict.
However, the SPI address space is 32bits long, and therefore clashes should
be minimal. 

To address your other question, no we do not touch the reserved SPIs defined by
IANA.

> I believe that MIP is using the standard CHAP_SPI, when using RADIUS, right?

CHAP_SPI is never used in key generation. That is for authentication of the MN-AAA
Auth Ext.

> the key AVPs would not contain the MIP-SPI, the algo and the Replay-Mode,

The SPI generated for the key, which points to the algo and the replay mode,
is completely separate from authenticator computation, so I do not understand
the question.

> and the FA.

but the MN provides its preferred SPI in the Generalized Key Ext, and the FA
provides its own in the MIP-FA-Preferred-SPI AVP. The Home Agent is the only
sticky point, and if the AAAH picks one that causes a conflict on the HA, an
error would be returned, which could include a new SPI, I suppose. The AAAH
would then try again. I suppose this is what needs to be documented.

> Of course, the AAA can count on the Preferred-SPI from the FA

No, IMHO, if not Preferred-SPI is present, then no key is generated. So,
perhaps some associated text in the Feature-Vector is needed?

> the SPI within the SA defined between the HA and the FA.

correct.

> > This needs some major cleaning up.

I think what I meant to say was (proposed text):

"  The AVPs described in this section contain the values inserted in
   the Key Material field of the extensions defined in [15]. The
   Key Lifetime field is set to the same value as the one found
   in the Authorization-Lifetime AVP."

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 26 Jun 2001 15:15:37 -0700

> So, no change is required. Sorry I missed that one when I first responded :(
No, I was right the first time, and wrong last time. You are correct, and
SHA-1 is now added in the next release.

PatC