Subject: [AAA-WG]: AAA WG agenda items

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Oct 2002 14:29:45 -0700 (PDT)

AAA WG will meet at IETF 55. We have one slot. If you have agenda items,
please send them to David or myself.

---

From: "Subrata Goswami" <[email-masked]>
Date: Sun, 13 Oct 2002 20:19:48 -0700

A simple question, the MIP-Session-Key AVP is used in the following
AVP's.

  1.    MIP-FA-to-MN-Key ::= < AVP Header: 326 >
                           { MIP-FA-to-MN-SPI }
                           { MIP-Algorithm-Type }
                           { MIP-Session-Key }
                         * [ AVP ]

  2.    MIP-HA-to-FA-Key ::= < AVP Header: 329 >
                           { MIP-Algorithm-Type }
                           { MIP-Session-Key }
                         * [ AVP ]

  3.    MIP-HA-to-MN-Key ::= < AVP Header: 332 >
                           { MIP-Algorithm-Type }
                           { MIP-Replay-Mode }
                           { MIP-Session-Key }
                         * [ AVP ]

It is not very clear how { MIP-Session-Key } are encrypted to provide
privacy in 
transit, what type of keys are used and how are these key's distributed
to the
AAH, HA and FA.  Sharing with MN is handled by the MN-AAA key. 

Subrata

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 14 Oct 2002 08:38:06 +0200

Hi Subrata,

The MIP-Session-Key is encrypted by the hop-by-hop security mechanism (i.e.
ipsec or tls) or if there is more than one hop between any of the nodes
end-to-end encryption may be used if deemed necessary (e.g. CMS when it
becoms standarized).

How you set up the hop-by-hop security like ipsec is out of the scope of the
diameter protocol

/fredrik

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Subrata Goswami
> Sent: den 14 oktober 2002 05:20
> To: [email-masked]
> Subject: [AAA-WG]: MIP-Session-Key
>
>

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 14 Oct 2002 08:27:31 -0700

Fredrik, so you are saying each of the different pair of entities would
have to be
provisioned with a distinct key or a private key/certificate. How is
situation
handled when there is no existing security association ? Also, if you
look into
the following 3 AVP that I mentioned, there is no SPI specified for the
MIP-HA-to-FA-Key
and the MIP-HA-to-MN-Key.  Would not it be better to have a security
association 
between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt the
MIP-Session-Keys ?

Subrata

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fredrik Johansson
Sent: Sunday, October 13, 2002 11:38 PM
To: Subrata Goswami; [email-masked]
Subject: RE: [AAA-WG]: MIP-Session-Key 

Hi Subrata,

The MIP-Session-Key is encrypted by the hop-by-hop security mechanism
(i.e. ipsec or tls) or if there is more than one hop between any of the
nodes end-to-end encryption may be used if deemed necessary (e.g. CMS
when it becoms standarized).

How you set up the hop-by-hop security like ipsec is out of the scope of
the diameter protocol

/fredrik

> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Subrata Goswami
> privacy in transit, what type of keys are used and how are these key's

> distributed to the

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 15 Oct 2002 11:17:41 +0200

> Sent: den 14 oktober 2002 17:28
> To: [email-masked]
> handled when there is no existing security association ?

There MUST be a hop-by-hop security mechanism, either ipsec or tls according
to the protocol

> Also, if you

that's exactly what's used, since the whole message between the FA-AAAF and
HA-AAAH is encrypted with the hop-by-hop security mechanism the keys are
encrypted, if there are several hops between each node a end-to-end security
mechanism should be used (e.g. cms)

/fredrik

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 15 Oct 2002 09:42:10 -0700

Frederik, no that is exactly what is used. IPSec and TLS are totally
different 
protocols and it is not necessary for Diameter MIP Application to set up

point-to-point encrypted links as they do. Setting up these
point-to-point 
links would be a nightmare and frankly  no one is probably  going to use
that 
approach in a large network with many subnets. Take a look at the
Diameter 
Mobile IP application, see how many hops are there.

A better approach is what I suggested, encrypt MIP-Session-Keys with
security
associations between a AAA agent and the entity. I am not sure CMS
handles this
issue. It is not about end-to-end vs. point-to-point, it is more about
how many
shared secrets needs to be deployed per session - in case of Diameter
Mobile IP
application that number is 3 if you include FA-HA in addition to MN-FA,
MN-HA. The
number would double if a unidirectional key is used.  Also, keep in mind
as Diameter Mobile IP Application is a key distribution mechanism, there
could be
other keys that it would have distribute in the very near future.

Subrata

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fredrik Johansson
Sent: Tuesday, October 15, 2002 2:18 AM
To: Subrata Goswami; [email-masked]
Subject: RE: [AAA-WG]: MIP-Session-Key 

> Fredrik, so you are saying each of the different pair of entities 
> would have to be provisioned with a distinct key or a private 
> key/certificate. How is situation

There MUST be a hop-by-hop security mechanism, either ipsec or tls
according to the protocol

> Also, if you
> look into
> the following 3 AVP that I mentioned, there is no SPI specified for 
> the MIP-HA-to-FA-Key and the MIP-HA-to-MN-Key.  Would not it be better

> to have a security association

that's exactly what's used, since the whole message between the FA-AAAF
and HA-AAAH is encrypted with the hop-by-hop security mechanism the keys
are encrypted, if there are several hops between each node a end-to-end
security mechanism should be used (e.g. cms)

/fredrik

> (i.e. ipsec or tls) or if there is more than one hop between any of 
> the nodes end-to-end encryption may be used if deemed necessary (e.g. 
> CMS when it becoms standarized).
>
> How you set up the hop-by-hop security like ipsec is out of the scope 
> of the diameter protocol
>
> /fredrik
>
> > From: [email-masked] [mailto:[email-masked]]On 
> > Behalf Of Subrata Goswami
> > It is not very clear how { MIP-Session-Key } are encrypted to 
> > provide privacy in transit, what type of keys are used and how are 
> > these key's
>
> > distributed to the

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 16 Oct 2002 09:07:07 +0200

Subrata,

> point-to-point encrypted links as they do.

taken from the base draft.
"2.2  Securing Diameter Messages

   Diameter clients, such as Network Access Servers (NASes) and Mobility
   Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS].
   Diameter servers MUST support TLS and IPsec. The Diameter protocol
   MUST NOT be used without any security mechanism (TLS or IPsec).

   It is suggested that IPsec can be used primarily at the edges and in
   intra-domain traffic, such as using pre-shared keys between a NAS a
   local AAA proxy. This also eases the requirements on the NAS to
   support certificates. It is also suggested that inter-domain traffic
   would primarily use TLS. See sections 13.1 and 13.2 for more details
   on IPsec and TLS usage."

So why should you encrypt the mip-session-keys again if the transport is
secured? The only case where you need to encrypt the mip-session-keys would
be if there are several hops between the sender and receiver, if so use CMS

/fredrik

Setting up these

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 16 Oct 2002 09:33:18 -0700

Frederik, I am looking at the problem from a different angle.  Setting
up these TLS/IPSec associations do not scale to large number of nodes.
If there are n AAA nodes, then it is n*n manual configuation. Whereas
what I am suggestin would reduce that to n or linear.

Subrata

-----Original Message-----
From: Fredrik Johansson [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2002 12:07 AM
To: Subrata Goswami; [email-masked]
Subject: RE: [AAA-WG]: MIP-Session-Key 

Subrata,

> different protocols and it is not necessary for Diameter MIP 
> Application to set up
>

So why should you encrypt the mip-session-keys again if the transport is
secured? The only case where you need to encrypt the mip-session-keys
would be if there are several hops between the sender and receiver, if
so use CMS

/fredrik

Setting up these
> point-to-point
> links would be a nightmare and frankly  no one is probably  going to 
> use that approach in a large network with many subnets. Take a look at

> the Diameter
> security associations between a AAA agent and the entity. I am not 
> sure CMS handles this

> > key/certificate. How is situation handled when there is no existing 
> > security association ?
>
> > between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt 
> > the MIP-Session-Keys ?
>
> that's exactly what's used, since the whole message between the 
> FA-AAAF and HA-AAAH is encrypted with the hop-by-hop security 
> mechanism the keys are encrypted, if there are several hops between 
> each node a end-to-end security mechanism should be used (e.g. cms)
>
> /fredrik
>
> >
> > Subrata
> >
> >
> > The MIP-Session-Key is encrypted by the hop-by-hop security 
> > mechanism (i.e. ipsec or tls) or if there is more than one hop 
> > between any of the nodes end-to-end encryption may be used if deemed

> > necessary (e.g. CMS when it becoms standarized).
> >
> > How you set up the hop-by-hop security like ipsec is out of the 
> > scope of the diameter protocol
> >
> > /fredrik
> >
> > > A simple question, the MIP-Session-Key AVP is used in the 
> > > following AVP's.
> > >