Subject: [mobile-ip] Concerns/comments for aaa-keys and gen-key

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Sep 2001 16:18:47 +0200 (CEST)

I've read draft-ietf-mobileip-aaa-key-08.txt and 
draft-ietf-mobileip-gen-key-01.txt and I have some significant comments and
concerns. Most of these comments is about aaa-key - the gen-key document
seems to be mostly a set of option formats without much behavioral protocol
specifications.

Some of these echo and perhaps extend the comments that Thomas generated
and that where forwarded to the mobile-ip mailing list on Aug 30.

High level comments (details below):
1. The scope of the problem and proposed solution isn't very clear.
2. The protocols outlined in the documents are very underspecified.
3. It is unclear what level of careful security review the documents
   have seen.
4. Between the lines there appear to be some architectural assumptions 
   e.g. that AAAh and HA have some high degree of mutual trust, which seem
   to imply that the solution might not be a good fit when the AAAh and
   HA are operated by different entities.

Scope/Applicability
-------------------

While the abstract talks solely of using this to create security associations
between MN-HA and MN-FA there appear to be other documents that appear to
use the same protocol mechanisms such as draft-le-aaa-lsa-tsk-00.txt.
While that draft doesn't specify packet formats it is using similar
techniques to those described in the aaa-keys draft. Currently there
is no way to tell whether the aaa-keys packet formats are intended to
be useful beyond the MN-HA and MN-FA security associations.

Thus what is needed is something indicating the applicability of aaa-keys.
Without knowing the applicability it is not possible to determine what
needs to be supported in terms of algorithms and key sizes, as
well as the constraints on how to negotiate what algorithm and key length
to use for a given SA.

Underspecification
------------------

As Thomas specified in depth there specification doesn't actual
contain message flows showing the interaction between MN, FA, HA, and the
AAA entities. 
(Who sends what to whom when? When processing occurs when a message is
received.)
Without this it is hard if not impossible to do a security analysis of
the specification.

The spec is completely silent on the need for re-keying and the
mechanism used to accomplish this.

The spec doesn't talk about algorithm negotiation?
I would assume that there needs to be at least one mandatory to implement 
algorithm to ensure that there is interoperability.

Does the protocol assume that the AAA exchanges provide confidentiality
or is it sufficient if the AAA exchanges provide integrity of the information
carried in the AAA protocol?

Security review
---------------

The security considerations section point out that there is
an assumption about the strength of the security for AAA being at least
as strong as the attempted security strength for the created security 
associations. Yet there doesn't seem to be a way for the protocol
to extract this information from AAA, in particular when there are
AAA proxies in the path. (If such information exists in a AAA draft
please provide a pointer.)

The document has a section on key derivation.
This section assumes that 64 bit randomness is sufficient, but this
depends on what current and future algorithms will be used (which is
related to the applicability of the protocol).

In general I think key derivation is a tricky thing. For some algorithms
the key derivation process must avoid weak keys. Yet the proposed mechanism
doesn't have a mechanism to do this.

The document talks about using the NAI to identify the user, which
might have privacy implications. While the NAI must have a stable domain
component (the part after the @ sign) in order to route to the right home
AAA server, but that doesn't inherently require that the component
before the @ sign be a fixed string like a user name.
Has there been any privacy review of this?
Are there any thoughts or proposals around using temporary IDs instead
of user names before the @ sign?

Architectural Assumptions
------------------------

Between the lines there appear to be some architectural assumptions 
e.g. that AAAh and HA have some high degree of mutual trust, which seem
to imply that the solution might not be a good fit when the AAAh and
HA are operated by different entities.

This assumption does not exist in RFC 2977 as far as I can tell.
Unless it is implicit in the term "home domain" (which is not defined
in RFC 2977) - that that term is supposed to be to both the location 
of the home AAA service and the location of the home routing service 
(i.e. the home agent).

It would seem unwise to have hard-code the requirement that the AAA home
and the IP address home is the same; folks have suggested scenarios
where the AAA home could be e.g. Visa and the routing home is
a home agent in the house (or elsewhere). Of course there
might also be scenarios when the are provided by the same administration e.g
when the same ISP/operator provides AAA and routing home.
So I think it makes sense to support both.

In the case when the AAAh and HA are different administrations then
I suspect that one needs to be able to have a different chain of trust -
with the MN-HA having the initial trust. But when they are the same 
administration it makes sense to have MN-AAAH be the initial trust that
is used to build the other trust relationships.

Thus I think this architectural issues will have an impact on the 
specification once the specification provides more detail.

----

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Sep 2001 21:41:37 -0700

Hello Erik,

Your comments seem to go right to the heart of what it means for
a working group to create protocol specifications.  Thus, I will
try to make some very general comments.  However, it has to be
other members of the working group that really will have to take
up the argument.  There have been people working with these
documents to produce interoperable implementations that do what
the engineers want to have done.  Their experience is reflected
in these documents.  That is what the IETF is about, it seems to
me.  But now the documents, even though they reflect the combined
wisdom of engineering some useful and interoperable implementations,
are apparently going to be vetoed.

My involvement with these documents is to try to capture codify
the practice of various groups developing authorization
infrastructure components for Mobile IP and AAA.  I'll happily do
whatever the working group and IESG decide, but I am in no position
to lead the effort towards making the decision.  I can only try to
make sure that the two documents in question fit well (enough) with
RFC 2002(bis) and the other documents (e.g., MN-NAI and the FA
challenge) that we have already finished.

Some more comments inline:

> seems to be mostly a set of option formats without much behavioral protocol

Yes, that was exactly the idea, and was considered to be the approach
indicated by MIER, which was also approved as a working group item,
and more recently integrated into RFC2002bis.

> and that where forwarded to the mobile-ip mailing list on Aug 30.

Unfortunately, I didn't manage to respond to those comments yet, given
other time pressures.

> 1. The scope of the problem and proposed solution isn't very clear.

The scope of the problem is to create a way for AAA to authorize network
access and set up the security associations needed for the mobile node
to work with a home agent.  It is supposed to look very much like what
is done today with RADIUS, except for improvements due to DIAMETER.
Building on existing experience seems to help a lot with getting
interoperability.

> 2. The protocols outlined in the documents are very underspecified.

The documents specify extensions for Mobile IP to be used with
a DIAMETER/AAA infrastructure.  The detailed specifications for
the message flows are expected to be in Mobile IP and AAA protocol
documents.

> 3. It is unclear what level of careful security review the documents

The people doing the work would probably state that they're a heck
of lot more secure than RADIUS, but I probably ought to avoid trying
to put any words in their mouths.

>    HA are operated by different entities.

All protocols have particular spheres of applicability.  I think that
most, but not all, people want to have the high degree of trust that
you infer.  However, I also think that the drafts have been written to
allow authorization by a third party.  Again, I am not conversant with
specific implementations that exhibity this behavior, and my only role
has been to try to incorporate the relevant comments that have been
given to me over the last couple of years for this document.

> Scope/Applicability

That draft was written after the drafts under discussion.  I'm not
sure what your point is here.  There are similarities, which is
understandable because the motivations from the authors of the 
document you cite are very similar to the motivations of the people
who suggested the ways for distributing keys according to the aaa-keys
draft -- again, as best I understand the motivations of the people
involved.

> be useful beyond the MN-HA and MN-FA security associations.

Are you asking whether the generalized key definitions are general
enough?  The specific subtypes in the aaa-keys are supposed to be
pretty specific, so I don't know whether anyone would want them to
be useful beyond what is there in the draft.

> well as the constraints on how to negotiate what algorithm and key length

As far as I know, everyone believes this will be determined by
policy at AAAH.  It "should" be legitimate for a vendor to create
a proprietary key distribution protocol and utilize that between
mobile node and AAAH.  Thus, in such a scenario, your suggestion
amounts to a request to determine whether proprietary information
is sufficient for the purposes intended by the vendors.

> Underspecification

The message flows are expected to be determined by Mobile IP and
by AAA.

> mechanism used to accomplish this.

But this would depend on the specific algorithm that was in use.

> algorithm to ensure that there is interoperability.

Maybe it's a proprietary algorithm?  Again, others may be
better positioned to answer this.

> carried in the AAA protocol?

I've never heard anyone ask this question before, and I think it would
indicate that everyone assumes that the key is never passed in the clear.

> Security review

            ............... stuff I don't know about   ..........

> of user names before the @ sign?

I would have expected that the way a node uses the NAI to identify
itself was more a matter for AAAH policy and operator contractual
negotiations.  It would not necessarily have any effect on the
format of the Mobile IP extensions, nor even the DIAMETER extensions,
and almost surely not much effect on the generalized extensions.

> Architectural Assumptions

This was already discussed above, right?

> So I think it makes sense to support both.

I also think it makes sense to support both.  I thought that
the working group review of the document had caused this to be
true, and I am not yet very clear on how the NAI considerations
would work against this.  For instance, company XYZ may somehow
have an agreement with company QWE to allow Mobile IP as long as
the mobile node can pay with a credit card.  But, again, I am
not conversant with the details of any prototype exhibiting that.

> specification once the specification provides more detail.

O.K.  I hope someone will provide the necessary text.

Regards,
Charlie P.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 26 Sep 2001 10:07:35 +0200

Hi Erik,

Please see additions to Charlies comments inline

/Fredrik
>the message flows are expected to be in Mobile IP and AAA protocol

As Charlie points out, the specification of message flows are in
draft-ietf-diameter-mobileip-07.txt. The gen-key and aaa-key drafts
merely specify the format of the specific message.

>>    HA are operated by different entities.

The assumption is that a AAA server (let it be AAAh or AAAf) have a high
degree of mutual trust with the HA. And that AAA servers of different
domains have a mutual trust (Service Level Agreement). If the HA is located
in a foreign network, the AAAh will distribute the keys to the AAAf which
will distribute them to the allocated HA in the foreign network.

>> well as the constraints on how to negotiate what algorithm and key length

It's up to the policy of the AAAh to determine the necessary level of the
keys to distribute.

>> Without this it is hard if not impossible to do a security analysis of

Who sends what to whom and when is all specified in
draft-ietf-diameter-mobileip-07.txt

>> mechanism used to accomplish this.

The keys have a given lifetime, it's also specified in the mobile ip
and diameter drafts how to distribute new keys when the keys expire.

>> algorithm to ensure that there is interoperability.

Since the mobile node and AAAh is in the same administrative domain it can
be
any algorithm that is supported by both nodes. However, HMAC-MD5 is
mandatory to
support in rfc2002-bis and in Diameter so there's one algorithm that always
will be supported.

>> carried in the AAA protocol?

The keys for the mobile node is distributed via key material so there is
really no need for confidentiality, the keys distributed to the FA and HA
is carried in the AAA protocol which requires either TLS or IPsec.

>> of user names before the @ sign?

I would not expect that this is a problem of the aaa-key or gen-key draft,
since they only handle transportation of keying data. The actual
registration
and identification of the user is handled by rfc 2002 and Diameter, thus
that's
where the problem lies (if there is a problem). The key drafts can use any
identifier used by mobile ip and diameter.

>> specification once the specification provides more detail.

I'm not sure that I understand what you mean here, if the AAAh and HA are in
different administrative domains, I would suspect that the initial trust
should
be between the MN-AAAh since it's only the AAAh that can determine if it's
willing
to pay for the user using the requested service. The HA is merely requesting
to
get paid for services provided.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Sep 2001 11:14:50 +0200 (CEST)

> merely specify the format of the specific message.

Thanks for the pointer - I hope this sheads some light.
[Seems like having this pointer in the mobileip drafts would be asking
to much. I should have read all of draft-ietf-mobileip* and draft-ietf-aaa-* 
before asking :-)]

A quick look leads me to believe that aaa-key is still very underspecified
when it comes to how the MN extensions are sent and processed in the MN
packets - diameter-mobileip talks about how/when the diameter messages
are sent and how they are processed on receipt, but nothing about what
the MN does.

> will distribute them to the allocated HA in the foreign network.

I understand they need the appropriate level of trust in order implement
the AAA functionality. But my concern stems from the fact that the AAA
infrastructure is viewed as a way to distribute keying material to be shared
between MN and HA and that this keying material seems to be intended to
be used for more than protecting the AAA exchanges.
So while the MN/HA trusts the AAA infrastructure for those functions
it doesn't follow that they should be trusted with arbitrary keying material.

> It's up to the policy of the AAAh to determine the necessary level of the

I do think we need an applicability to understand e.g. whether only 64 bits
of randomness is sufficient, what is required in terms of re-keying, etc.

> and diameter drafts how to distribute new keys when the keys expire.

Which mobileip draft?
It seems like the MN might need to be able to determine when a key
is about to expire and initiate a re-key, but aaa-keys is utterly silent
on anything about re-keying.

> support in rfc2002-bis and in Diameter so there's one algorithm that always

So it seems like aaa-keys should list this one as MUST implement.

> is carried in the AAA protocol which requires either TLS or IPsec.

I'm told that inventing a new key exchange/agreement protocol is non-trivial.
What the drafts are describing sure looks like a new protocol in this
area. 
If this is the case I expect there to somehow be a critical mass of
experts in this area that will review this protocol, because
I don't think its in our collective interest to create another WEP
debacle.

Alternative, if there are existing proven mechanisms to distribute keys
that fit into this it would seem to be prudent to reuse that.
(The diameter-e2e-sec draft is proposing to reuse CMS for diameter for
instance.)

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Sep 2001 12:25:33 +0200 (CEST)

> a working group to create protocol specifications.

Charlie,

I think the purpose is stated at a high-level in RFC 2026 which talks
about ...
   The goals of the Internet Standards Process are:
   o  technical excellence;
   o  prior implementation and testing;
   o  clear, concise, and easily understood documentation;
   o  openness and fairness;  and
   o  timeliness.

   [...]

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  

One stringest test for verifying the "clear and well-understod" is to
expect that interoperable implementations result from merely reading
the specification without the ability to ask questions of other
implementors or authors.
If such indepedent implementations achieve full interoperability at the first
try we have a pretty good indication that the specs are clear.

But of course we can't mandate that folks provide such implementation efforts
-  in fact most of the implementators have been involved in the standardization
effort in the WG. Thus we rely on members of the community to read the
specifications and try to find issues that would be unclear to a prospective
implementor.

Do you have a different view of how we get interoperable implementations?

> But now the documents, even though they reflect the combined

Whatever gave up that impression?

We need the specs to be clear.

> the message flows are expected to be in Mobile IP and AAA protocol

In separate documents? When will those documents be available for review?
(Thanks to Fredrik I know the answer to my question.)

Which documents should an implementor building just an MN read?
Must such an implementator read the diameter specs or should be
be sufficient to read the mobile-ip specifications?
(My preference would be to have specifications that are structured
so that the the mobile-ip specs are self contained but with additional,
non-required background reading in other documents.)

> All protocols have particular spheres of applicability.
[and later]
> is sufficient for the purposes intended by the vendors.

Do you view that a vendor that takes these extensions and build
a proprietary protocol should be able to say that their protocol
conforms to an RFC?

> better positioned to answer this.

You seem to be missing my point.
How do you expect to get secure interoperability if you allow vendor X to
only implement algorithm A and vendor Y only implement algorithm B?
What is worse that in your view of the standards work, it would be fine
for both vendors to claim "We fully conform to the RFC" yet there is no
hope of interoperability.
I thought the IETF was about interoperability first and foremost.
What am I missing?

> and almost surely not much effect on the generalized extensions.

I think you are probably correct in that the semantics on the local part of
the NAI doesn't affect the packet formats. But I think it has
a profound effect on everything else including
 - the question whether it is important to solve this privacy issue,
 - mechanisms needed in the AAA system if the local part is transient IDs
   instead of user names.
 - a mechanism by which the AAA system and the MN can agree or securely
   exchange which the sequence temporary IDs will be used.

Thus if the IETF thinks it is important to solve this problem (and that is
really my question) then it is obvious to me that some protocol specifications
are needed in order for this to result in interoperable implementations.

> This was already discussed above, right?

Yes, you started commenting on my table of contents for the email at the top.

> not conversant with the details of any prototype exhibiting that.

Good. So all we need is the clear specification of how this works.
I'll see if diameter-mobileip sheds any light on this part.

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 26 Sep 2001 14:56:59 +0200

Hi Frederik,

Since this has been brought up, I have a few questions that I wanted
to ask a while back.  See inline, thanks.

Erik:
> >> 4. Between the lines there appear to be some architectural
> >> assumptions e.g. that AAAh and HA have some high degree of mutual
> >> trust, which seem to imply that the solution might not be a good
> >> fit when the AAAh and HA are operated by different entities.

Frederik:
> domains have a mutual trust (Service Level Agreement).

It looks to me that an (AAAH, HA) must have SLA's with every AAAF's in
whose domains that HA's MN could possibly roam.  Doesn't this boil
down to a scaleability issue similar to Mobile IPv6 (in which MN must
have trust relationships with any possible CN)?

I can understand trust between AAAH and HA, but I suppose that trust
relationship between AAAH and AAAF's, or between HA's and AAAF's, are
difficult.  If I'm missing something, sorry, please enlighten me.

If one can assume trust between an HA and any AAAF then why not using
same method between MN and CN?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Sep 2001 08:29:57 -0700

Hello Erik,

> Whatever gave up that impression?

I'm glad that no such impression was intended.  Thanks!

> non-required background reading in other documents.)

Whenever specifications are written that involve two (or more) other
base specifications, I thought it should be reasonable to expect that
implementers would read those base specifications.  I think that
applies in the case of these documents.  The specific processing
that is required for handling the extensions in the aaa-keys draft
should be in there, but it wouldn't be appropriate to say exactly
how to use DIAMETER I don't think.  In fact, these documents were
written before DIAMETER was selected (even before the working group
was formed, I think).  So an attempt was made to allow the Mobile IP
extensions work with _any_ AAA protocol that met the requirements
outlined in the Mobile IP requirements statements for AAA.

> a proprietary protocol should be able to say that their protocol

Here, I think you meant,  "a proprietary security protocol".
If so, the answer is "yes".

Even so, I reckon it would be fine to mandate a particular security
algorithm, but I didn't build the prototypes, and I don't know which
algorithm people would choose for the default.  Is there something
besides IKE that we can mandate here?  Otherwise, I would worry that
placing the requirement would amount to an indefinite delay while
someone creates a new default choice -- which would then itself have
to undergo months of review and would probably be more complicated
than the whole rest of the AAA-keys document, maybe by an order
of magnitude.

> I thought the IETF was about interoperability first and foremost.

I didn't say you were missing anything, and I'm pretty sure I did
not miss your point.

However, I would emphasize the difference between building
protocols, vs. building systems.  A system has many parts,
and even using interoperable protocols can usually be built
so that there isn't any interoperation.  To take a trivial
example, two systems can implement IP and TCP and UDP and
yet not interoperate because of mismatch at the application
level.  I don't remember any requirement that TCP specify a
guaranteed interoperable application running at a well-known port.
IP itself doesn't require any interoperable transport protocol,
and yet without such a thing, two systems cannot interoperate.
Even so, we all think of IP as being a nice, small. interoperable
network protocol.

Here, the extensions are the interoperable containers for
key distribution data which (I think!) was expected to be
specified in other documents.

>    exchange which the sequence temporary IDs will be used.

No doubt about these points.  And yet, we cannot solve every
such problem in these supposedly simple extension documents.

> are needed in order for this to result in interoperable implementations.

This is exactly right.  The quesion is, whether "some protocol specifications"
will occur in the two documents in question, or in other documents.

> Do you have a different view of how we get interoperable implementations?

No, this is exactly right from my understanding.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Sep 2001 10:14:10 -0700 (PDT)

> it doesn't follow that they should be trusted with arbitrary keying material.

   Right. This has been what my discomfort with these
   drafts have been related too. Currently, AAA (RADIUS) 
   is a one way authentication proxy mechanism. DIAMETER
   brings mutual authentication to the table, but I think
   it's quite a leap of faith to say that AAA should then 
   become a key distribution protocol as well. Key distribution
   protocols are hard, and it is not clear to me that MIP is
   a very good venue to be pursuing them. At the very least,
   keying MN/HA SA's begs the question of why you should
   stop there. Why should AAA not be able to key other 
   protocols as well? How many specialized AAA key distribution
   protocols will there be? Will there be a sufficient amount
   of review by clueful security people to make certain that
   stupid mistakes are not made? Has anybody considered that
   there may be significant wheel-reinvention going on here
   (cf Kerberos).

   My feeling is that if this is done at all, it should
   be done in a new working group and most definitely
   under the security AD's watch.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Sep 2001 11:46:47 -0700 (PDT)

First, I should say that I think that this draft
is the right overall approach, so don't take this
as an indictment.

1) It's not entirely clear to me how general the
   gen-keys draft actual is. According to its
   introduction, it should be possible to use many
   different types of authentication schemes to
   key up the SA. While I'm not saying that it
   isn't possible, it would be nice to see some 
   flows of at least two schemes as an existance
   proof. Preferably, it would sketch out how it
   would be possible to do so using a cert based
   public key scheme (PKCS XX), Kerberos, and
   the AAA proposal. This would go a long way to
   making what is supposed to be a framework more
   understandable.

2) It seems to me that this draft should probably
   define some minimum requirements on whatever
   the payloads are, ie, must provide replay
   protection, mutual authentication, etc.

3) Eric might have already mentioned this, but
   it's not clear to me what the security 
   relationship between MN and HA, HA and FA,
   along with FA to FA. For example, when a mobile
   node moves, can the HA/FA's before it derive
   the secret between MN and it's current
   FA? If so, is that acceptible? How does a MN
   prevent a FA to pass things to another FA 
   that it doesn't want to be a participant? Are
   there any sceanrios where the MN could be 
   compromised without its knowledge?

4) It's not very clear to me why there needs to
   be specific message types for each
   combination of HA, FA, MN. Why isn't it sufficient
   to just have a single suboption and allow the
   context to determine who's talking to whom?
   Have missed something?   

	Mike

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 09:50:30 +0200 (CEST)

Charlie,

> If so, the answer is "yes".

No, I actually meant "protocol".

The question I'm trying to ask was the same as the one about vendor X and Y;
whether you think it is ok that two vendors can correctly implement
a given set of RFCs and conform to them, and there is no chance for them to
interoperate since they've chosen different optional subsets of the protocols.

And you didn't seem to answer that question (see below using TCP FIN/RST
as an example).

> than the whole rest of the AAA-keys document, maybe by an order

I'm a bit lost - the comment was about security algorithms (like HMAC-MD5) -
what does IKE or any other key exchange/agreement protocol have to do
with this?

> Even so, we all think of IP as being a nice, small. interoperable

But those systems that implement UDP, TCP, and IP can in fact,
provided they satisfy the MUST/MUST NOTs in the specs,
interoperate at those layers. Sure, they might not share any applications
which will effect the utility of the system for sure. But that isn't the
point - the point is whether a given RFC specifying a given protocol
is structured so that two implementations of that RFC can interoperate
using the specified protocol ignoring the systems level issues when making the
determination.

But the way I interpret your reluctance to mandating an algorithm for
aaa-keys seems similar in advocating the TCP RST and TCP FIN packets should be
optional resulting in one implementation only being capable of
sending RST (and not FIN) and another implementation only being capable
of processing FIN (and not RST). The way I interpret what you say is that
this would be a system level issue and it is perfectly fine to have a spec
that says MAY or the sending as well as receiving of FIN and RST.
Did I understand your point correctly?

Cheers, 
   Erik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 27 Sep 2001 16:14:28 +0200

>to much. I should have read all of draft-ietf-mobileip* and

:-),

>be used for more than protecting the AAA exchanges.

yes, the key material is intended to protect the MIP signaling, having the
keys/key-material distributed via AAA is just a way to create a more
scalable
solution. The use of the distributed keys is exactly the same as in regular
MIP where the keys are pre-configured.

>> and diameter drafts how to distribute new keys when the keys expire.

draft-ietf-aaa-diameter-mobileip-08.txt (when it becomes available, -07 is
not
updated to reflect the changes to use key material in aaa-key). The AAAh
sets
an Authorization lifetime for the session it authorizes and the same is used
on the keys that are distributed.
The HA will set the registration lifetime so that the authorization lifetime
is a multiple of the registration lifetime. This way the mobile node will
not
update the keys at every periodic tunnel update, but only once in a while.
The mobile node can request new keys when the authorization lifetime is
about
to expire, or the FA can determine to send the registratio request via the
AAA and request that new keys be distributed, i.e. both the network and the
mobilen node can determine when to re-create keys.

>on anything about re-keying.

ok, there might be some more explanations needed in aaa-key. However,
the thought is that it is not only up to the mn to determine when new
keys are to be created, it can also be up to the network to distribute
new keys when appropriate. But I agree that this need to be explained.

>So it seems like aaa-keys should list this one as MUST implement.

I've no problem with this. why not take HMAC-MD5 since it's already
mandatory in rfc2002-bis

>I don't think its in our collective interest to create another WEP

It's not like the different nodes are negotiating what keys to use, the
different MIP entities gets the keys to use via AAA. The keys destined
for the HA and FA are transported in Diameter which have end-to-end
security, and the keys to the MN is not realy a key but key material,
thus no one can re-create the key unless they know the shared secret
between the mn and the AAAh. So there is not such a big difference from
someone manually configuring the different nodes with keys sent via snail
mail
or agreed on over some other media.

But I might be over simplifying the problem here.

/Fredrik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 16:15:10 +0200 (CEST)

> or agreed on over some other media.

It is the assertion that key material being different than keys
that makes the alarm bells start ringing - I think such an assertion needs
to be analysed by folks that are subject matter experts in the protocols
and algorithms used to carry the material as well as constructing
keys from the material.

This approach is quite different that the proposed 
draft-ietf-aaa-diameter-e2e-sec which re-uses an existing mechanism
(CMS) and relies on certificates (by distributing the certificate chains
itself). At least that doesn't seem to invent new stuff that makes my alarm
bells go off.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 27 Sep 2001 09:06:49 -0700

Hello Erik,

Comments inline...

Erik Nordmark wrote:

             ..........

> interoperate since they've chosen different optional subsets of the protocols.

From your note below, it seems that we don't have any major difference
of opinion about what needs to be done here.  But even so, I would like
to clarify that the example in my previous note did not involve selection
of different optional subsets from the aaa-keys extensions.  In the case
I described, it was more like whether or not AAAH and mobile node share
a compatible security association from which they can produce derived keys.

> And you didn't seem to answer that question (see below using TCP FIN/RST

Well, I thought I did.  I think that if two vendors implement the same
aaa-keys protocol, and the nodes are configured with compatible security
associations for this purpose, then interoperability would result.
Since these are Mobile IP extensions, it is already guaranteed that the
mobile node is going to implement a well-known message digestification
algorithm -- in RFC2002bis, HMAC-MD5.  Thus, while I'm happy to put whatever
is needed into the document (e.g., explicitly mandate use of HMAC_MD5 as
the algorithm which is used to derive the key), I also believe that this
process of key derivation is quite a bit different than the kind of
message flow involved in your TCP FIN/RST example.

> what does IKE or any other key exchange/agreement protocol have to do

Now that I see that your comment was about security algorithms like HMAC-MD5,
I can see why my paragraph would be completely irrelevant to your concern.
On the other hand, I think that IKE does qualify as a security algorithm,
so that the terminology can get confusing, which just indicates a strong
need for providing as much context as possible during our discussions.
Furthermore, your comment came after some discussion in my paragraph that
concerned key distribution protocols.  In other words, we seem to have
been talking pretty much right past each other on this point, since
I didn't realize at the outset you were focusing on the choice of
digistification/encoding algorithm.

           ........  points already covered   ...........
 
> Did I understand your point correctly?

In the first place, I am not reluctant to mandate an algorithm -- in fact,
my role is to put in there what others tell me to put in there, since I
was not present at the interoperability tests.  Even more abstractly, as
you have clarified your request, I have no problem at all with putting
in a mandate for, say, HMAC-MD5.  So, for example, I could rewrite
section 4 to use HMAC-MD5, delete references to MD5 in prefix+suffix
mode, and state that the algorithm in section was mandatory to implement,
and that other algorithms MAY be used.  Would that resolve this issue?

To clarify my point further, I would not agree with the interpretation
you suggest FIN and RST.  These are messages that are sent and received,
and they are supposed to initiate actions according to the presumed
state of the communications partner.

The aaa-keys draft does not specify such distinct message components,
but rather containers for material to be managed according to the
security association shared by the parties.

Unfortunately, I have to defer further discussion of these drafts to
the people who are actually doing the work.  I hope that with this
message our positions can be seen as very close, and that someone will
supply the necessary text for me whenever it is agreed about whether
HMAC-MD5 will be mandated.  I'll try to be very responsive in producing
the next draft.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 18:22:33 +0200 (CEST)

> of opinion about what needs to be done here. 

Great.

> But even so, I would like

You're saying "security association" - but I think this is about
the "algorithm", right?

I do think it is similar in the sense that if e.g HMAC-MD5 and HMAC-SHA1
are the defined algorithms and both are optional you can end
up with a case where one vendor implements only HMAC-MD5 and another vendor
implements only HMAC-SHA1 then no matter how hard the customer tries those
boxes can't interoperate using the specified protocol.

> message flow involved in your TCP FIN/RST example.

Requiring one algorithm as MUST be implemented would be the first step.
Assuming HMAC-MD5 provides adequate security I don't see a problem mandating
that one.

But if there are other (current and future) algorithms that are used
it seems like there needs to be a way for the communicating parties to
determine which algorithm to use.
For instance, if 5 years from now HMAC-MD5 is not considered to be secure
enough, when both parties implement the NEW-BETTER-ALG they should be able
to discover that and use it instead of HMAC-MD5.

In MIPv4 HA-MN authentication this is determined when the relationship
between those two boxes is configured (i.e. at "subscription" time).
Do you envision the same here?
Doesn't the AAA server also need to support the same algorithm or do
they "merely" provide a secure communication channel between the HA and MN?

Hmm - perhaps the confusion between the terms "algorithm" and "security 
association" stems from the fact that here (as well as in RFC 2002)
the security associations between MN and HA are pre-configured
i.e. there is no notion of a master key and re-keying creating different
SAs over time. (IKE with pre-shared secrets ends up creating a new SA
when re-keying so that while the new SA is put in place the old SA can
be used for packets in transit.)

I wonder if anybody has been thinking about periodic re-keying in
the RFC 2002 context - it sure seems usefulin general.
I need to read what the AAA docs say about re-keyeing.

> On the other hand, I think that IKE does qualify as a security algorithm, so
> that the terminology can get confusing, which just indicates a strong need
> for providing as much context as possible during our discussions.
> concerned key distribution protocols.  In other words, we seem to have been
> talking pretty much right past each other on this point, since I didn't
> realize at the outset you were focusing on the choice of

Yep - we've had some terminology problems.
I think adding some definitions to aaa-keys would help here (I think Thomas
was asking for this as well).

   Erik

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 20:47:24 -0700

Sorry for the latency... seem to be a tad busy these days :(

> Building on existing experience seems to help a lot with getting

In order to cut down on the spec size, we decided not to copy all the
verbose text from the Diameter Mobile IP application. However, all of the
information you are requesting can be found there.

> to put any words in their mouths.

The latest revisions of the draft made use of key material, which was
suggested by 3GPP2's AHAG chair (their security folks). Since no keys
are sent in the clear, there is no possibility of key compromise (other
than plain text and brute force attacks - which one can always do).

> >    HA are operated by different entities.
Again, all of this can be found in the Diameter Mobile IP application.

> > use the same protocol mechanisms such as draft-le-aaa-lsa-tsk-00.txt.

ok... and?

> > well as the constraints on how to negotiate what algorithm and key length

Mobile IP is a request/response protocol. Unfortunately, it doesn't lend itself
well to negotiations. So, the AAAH (owned by the administrator) will have to
select the algorithm and key length. If the transforms provided are not
sufficient (e.g. hmac-md5), then some guidance would be appreciated.

> > Underspecification

right. again, we decided against redoing all of the work in the Diameter
Mobile IP application. Folks MUST read the other spec anyways to build a
system, so we didn't feel it was all that necessary to redo in this spec.

> > mechanism used to accomplish this.

it states what the key lifetime is. Once a key is expired, one rekeys.
perhaps additional language is needed in that area.

> > algorithm to ensure that there is interoperability.

check. hmac-md5 should be a must (boy.. that didn't sound right)

> > carried in the AAA protocol?

It doesn't matter if AAA doesn't provide confidentiality since the actual keys
aren't passed. Just the key material.

> > of user names before the @ sign?

These very schemes are used universally for dial-up, and the whole AAA
protocol is modeled around this. If this is a genuine concern, it applies
to more than just Mobile IP.

> > Architectural Assumptions

All of these assumptions are clearly defined in the Diameter Mobile IP 
application.

> > So I think it makes sense to support both.

It supports both.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 20:54:36 -0700

> to much. I should have read all of draft-ietf-mobileip* and draft-ietf-aaa-* 

Charlie and I removed these based on a comment on another one of our
drafts that had such a reference. Perhaps now that AAA has selected its
protocol, we can now include the reference.

> are sent and how they are processed on receipt, but nothing about what

ok... perhaps more is needed here.

> of randomness is sufficient, what is required in terms of re-keying, etc.

ok

> on anything about re-keying.

It is in the Diameter Mobile IP draft, but it should also be in this draft.

> So it seems like aaa-keys should list this one as MUST implement.

yes

> I'm told that inventing a new key exchange/agreement protocol is non-trivial.

right, that this is not a key exchange/agreement protocol. It has been
through a security review, but not an IETF one :(

> I don't think its in our collective interest to create another WEP

Although these are two completely different domains, I agree that a 
security review is needed....

> (The diameter-e2e-sec draft is proposing to reuse CMS for diameter for

but cms/mobile ip seems unnecessarily cumbersome, and would now require
a multiple request/reply exchange.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 20:55:47 -0700

>    under the security AD's watch.

Let me see... scrap the work, and start over with new folks... 

very constructive. 

How about we review the work, and then comment.

sigh.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 20:59:03 -0700

> and algorithms used to carry the material as well as constructing

In fact, sending key material is MUCH MORE secure than keys... not sure
why bells are ringing... maybe someone's at your front door

:)

> itself). At least that doesn't seem to invent new stuff that makes my alarm

but cms is not appropriate here. the mobile node doesn't participate
in the AAA transactions.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 21:00:46 -0700

> have trust relationships with any possible CN)?

nope. That's why folks like GRIC (www.gric.com) and IPass (www.ipass.com)
exist, which is to reduce B2B roaming relationships.

> difficult.  If I'm missing something, sorry, please enlighten me.

sure, a top level AAAF can be used to reduce the number of relationships,
or a broker can be used.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 21:06:47 -0700

While on this interoperability talk, I'd like to note that we have 4 
independently developed implementations that successfully interoperated
on many occasions.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 27 Sep 2001 21:11:35 -0700

> to discover that and use it instead of HMAC-MD5.

If that's the case, then a new multi round trip mobile ip protocol is
needed, since the protocol doesn't allow for negotiation.

> I need to read what the AAA docs say about re-keyeing.

it states that once the lifetime has expired, keys are useless and rekey
is mandatory.

> was asking for this as well).

I agree.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 28 Sep 2001 10:06:53 +0200

>> to discover that and use it instead of HMAC-MD5.

There is a way for the communicating parties to determine which algorithm
to use.

>needed, since the protocol doesn't allow for negotiation.

It's true that the protocol doesn't allow for negotiation, but there is
nothing that prevents you from pointing out the NEW-BETTER-ALG when your
AAAh and MN both implement them. The AAAh is the one that tells the MN what
algorithm to use to derive the key from the key-material and what algorithm
to use with the derived key when talking to the HA/FA, i.e. it's up to the
policy of the AAAh to set the right level of security.

/Fredrik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Sep 2001 10:28:42 +0200 (CEST)

> Mobile IP is a request/response protocol. Unfortunately, it doesn't lend
> itself well to negotiations. So, the AAAH (owned by the administrator) will
> have to select the algorithm and key length. If the transforms provided are
> not sufficient (e.g. hmac-md5), then some guidance would be appreciated.

Huh?
Negotiation doesn't require multiple exchanges. It is sufficient
for the sender to list which algorithms it supports (e.g. in priority
order) and the responder to pick the first one it supports in the list.

> system, so we didn't feel it was all that necessary to redo in this spec.

OK. This means that the aaa-diameter-mobileip spec should be listed
as a normative reference in aaa-keys.
And it has the effect that aaa-keys can't move to PS until its normative
references move. I don't know if that is what you want...

An alternative would be to make aaa-keys standalone in describing what mobileip
nodes (MN, FA, HA) need to do without actually getting into the details of
what AAA protocol is used and the encoding in that protocol. An example of how
this could look in aaa-keys:

	Section x.y: FA receiving Registration Requests

	When a FA receives a registration request from a MN, in addition to
	the message validation specified in rfc2002, the FA must verify
	 - ...
	 - ...

	Then the FA takes the information contain in (or in the x and y fields)
	in the registration request and passes them to AAA.

	If the AAA system grants access, the result is that a AAA message
	containing x, y, and z is passed to the HA.
	If the AAA system denies the request, the result is ...

	Section ...: HA receiving logical registrations from AAA

	When a MN registers the result is that the FA causes x, y, z
	to appear at the HA from the AAA. The exact encoding of this information
	depends on which AAA protocol is used.

	The HA, if addition to the verification steps specified in rfc2002,
	must verify:
	 - ...
	 - ...

I hope you get the idea.
I think taking this pass allows implementors to build
a complete MN without needing to read any AAA documents (i.e. no normative
reference) even though such documents can provide background information.
I also allows implementors to build FA and HA functionality assuming
that there is a place to plug in a AAA protocol that passes the needed
information (with the appropriate security provisions).
So I my mind this would get rid of a bunch of diameter documents 
as being normative references.

It is of course up to the WG to decide which path they want to take.

> to more than just Mobile IP.

I agree it applies to more than mobile IP. Where should we have this
discussion?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Sep 2001 10:38:54 +0200 (CEST)

> why bells are ringing... maybe someone's at your front door

I guess it is a difference in approach.
I think that constructing new security protocols (as opposed to
protocols which encapsulate and use existing security) is a darn hard
problem and I do not see how I can judge such protocols. Thus I will
defer to experts in this area.

So while carrying keying material instead of the actual keys might 
appear at first sight, I assume the security of the system actually
depends on the algorithms used to 1) protect they keying material
in transit and 2) the algorithms used to construct
keys from the keying material.

So the bells will stop ringing when either some IETF security experts 
tell me not to worry, or if the problem can be solved using an existing
security protocol.

> but cms is not appropriate here. the mobile node doesn't participate

I didn't actually suggest using cms - I gave an example where a new security
protocol isn't invented but instead an existing wheel^H^H^H^H^Hsecurity
protocol is used.
Which existing security protocols might apply is beyond my expertise.

And just because cms is used by AAA doesn't imply that it can't be used
by other protocols (like email, mobile-ip, etc :-)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Sep 2001 10:41:46 +0200 (CEST)

> independently developed implementations that successfully interoperated

Good, but that doesn't necessarily mean that the specs are clear.

I suspect that all those implementations were done by folks that participate
in the IETF - they might even have asked the authors for clarification.

The goal is to have specifications so that a newcommer actually can implement
the protocol from the spec without asking anybody any questions.

   Erik

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 28 Sep 2001 08:05:05 -0700

> order) and the responder to pick the first one it supports in the list.

then that's not really negotiation, but rather listing the supported algorithms.
If the AAAH didn't like the list, it cannot get into a bidding war with the 
client. That's what I consider negotiation.

sorry I misunderstood.

> references move. I don't know if that is what you want...

not sure there is any way around this one... I'm comfortable with it.

> 	The HA, if addition to the verification steps specified in rfc2002,

yes, but personally prefer the former (don't know what the rest of the WG think).

> It is of course up to the WG to decide which path they want to take.

right

> I agree it applies to more than mobile IP. Where should we have this

We've had these in roamops 5 years ago. We could revive that WG if need be.

PatC

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Sep 2001 08:22:11 -0700 (PDT)

Pat Calhoun writes:
 > > Why should AAA not be able to key other 

   Nobody's said anything about starting over. I notice
   that you don't address my main concern of why *key
   distribution* is being pursued in MIP. It's not even
   in the AAA charter, let alone the MIP charter.

 > How about we review the work, and then comment.

   Fine. This working group has taken a drubbing
   on the security front for something that was 
   clearly in its charter: securing binding updates.
   This was largely not its fault, and just goes to
   prove the obvious: security is hard. It is 
   incomprehensible to me that this working group
   should attempt to take on the task of AAA based 
   key distribution. If that is a useful concept
   at all, it clearly has further applicability 
   than just keying a few specialized security 
   associations in a one-off, poorly reviewed
   manner.

   FWIW, I might even support a properly chartered
   effort, especially if were simpler/lighter
   weight than the other two suspects.

		Mike

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 28 Sep 2001 08:08:15 -0700

> keys from the keying material.

The keying material doesn't need to be protected. Both end points have a 
known secret key, and an algorithm. The actual key used is derived from the keying
material.

yes, the algorithms used to construct the key must be cryptographically strong.

> tell me not to worry, or if the problem can be solved using an existing

Can we get a security review, please?

> by other protocols (like email, mobile-ip, etc :-)

but one size fits all doesn't always exist. btw, we aren't inventing anything
new here. As others stated on this thread, the mechanism described is widely used
in cellular systems today.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 28 Sep 2001 08:16:14 -0700

>    in the AAA charter, let alone the MIP charter.

ok... perhaps I misunderstood, but it sure sounded that way to
me. As some folks (including the IESG) have repeatedly mentioned,
don't expect the security area to secure every other WG's protocols.
That will not happen. They will, however, lend a hand in security
reviews.

I believe that's what we are asking for here. Creating a whole new
WG to look at this problem will delay the work, and waste engineering
resources. We don't need hundreds of folks to look at it (but if they have
time, they are certainly welcomed to do so in the MIP WG), just a review
to get the document out to RFC-dom.

btw, creating keys based on key material is not reinventing the wheel.

We just need a security review.

>    clearly in its charter: securing binding updates.

apples != oranges. I was never involved in the binding 
updates... have for a long time stated this doesn't scale.

Please don't bundle me in that work.

>    associations in a one-off, poorly reviewed

hmmmm.... the draft was recently modified due to comments
following a security review... so poorly reviewed is 
perhaps not the correct term here. Not reviewed by folks
you'd prefer may be more adequate.

PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 28 Sep 2001 09:08:37 -0700

Hello Pat,

> updates... have for a long time stated this doesn't scale.

It seems to me that there is more than one aspect of scalability
that is important here.  In order to have scalable routing, we
need to have Binding Updates.  More recently the task has been
given to us to develop scalable key exchange techniques.

When that's accomplished, I reckon we will see that mobility
management is more scalable, not less scalable, in all the
aspects of interest.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Sep 2001 13:32:22 -0400

Since the following point has been stated twice now...

"Charles E. Perkins" <[email-masked]> writes:

> in these documents.

The single most important purpose of the IETF is to produce Standards
from which interoperable implementations can be built. Note that this
*very* different than having a document that N implementations claim
to conform to. Let me repeat, the goal is to get *documents* that are
clear and from which implementations can be build. That means, the
specs *need* to stand up on their own.

It is common for implementations and draft writing to go on in
parallel (and this is generally good!), but one negative side effect
is that sometimes issues get discussed in e-mail only, and don't get
clearly written up in the specs themselves. But implementors don't
notice, because they've got their implementations working based on
e-mail, hallway conversations, and bakeoffs.

I would think that a WG would find it very valuable to have a detailed
review from someone outside of the WG (i.e., from somone not familar
with the detailed history of what has gone on on the mailing
list). Such a review then really evaluates the spec on its own. I.e.,
much like when a new implementor, one who knows little about MIP
because MIP is a new project for them, starts by reading the RFC for
the first time.

Unfortunately, we do have a long history of documents that in
hindsight were riddled with ambiguities. If only the original language
had been clearer.

Thomas

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 28 Sep 2001 14:53:39 -0700

Hello Thomas,

I ought to say something about this, since my initial foray
into the discussion was based on my understanding that
we were being asked to develop some new key distribution
protocol between AAA and mobile node.  If you read
my initial (probably too long) e-mail in this context, it
probably makes a lot more sense (at least I hope!).
When it became clear that the actual request was much
narrower in scope, then the problem has become very
much smaller.  I've already outlined what I thought would
be a way to satisfy the smaller request which I think is
what was originally requested (e.g., explicitly state that
the mandated RFC2002bis digestification algorithm must
be implemented).  In fact, if the proposal is put that
way, it's practically a no-brainer.  I guess I wasn't expecting
it to be so easy.

> specs *need* to stand up on their own.

Wholeheartedly agree.

> e-mail, hallway conversations, and bakeoffs.

Agreed, with the proviso (with which I am sure you will agree)
that implementation experience is the hugely positive factor and
that the implicit assumptions you allude to are what need to be
brought out and examined (and perhaps on occasion challenged).

> because MIP is a new project for them, starts by reading the RFC for

I definitely agree with this, as long as the new implementor can be
presumed to tackle the implementation tasks roughly "in order".

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Sep 2001 15:24:36 -0700 (PDT)

> sufficient (e.g. hmac-md5), then some guidance would be  appreciated.

   Beyond Eric's clarification, I have a question:
   You clearly must derive new keys from the MN/AAA
   secret which if I remember correctly comes from
   the AAA, encrypted in the MN/AAA key. What prevents
   key reuse, especially for rekeying? Is there a way
   to get the AAA to supply fresh key material on demand?
   If so, is the performance penalty going to be acceptible?
   If not, is the expectation that one or both of the
   ends of the SA supply entropy? If it's only one side,
   what happens if their random number generator is not
   very good, like oh say open("/dev/null")?

   The reason I ask is because key derivation is a pretty
   big preoccupation with crypto types. Generally speaking,
   the safest thing is to have all parties contribute to
   the entropy, though having a trustworthy source of entropy
   like a KDC may be adequate assuming that you don't
   reuse its entropy without adding fresh entropy.

		     Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Sep 2001 16:01:42 -0700 (PDT)

> That will not happen. They will, however, lend a hand in security

   This is not the same creature though; I certainly
   don't want the security area to become an IETF
   sweat shop. However I think it's pretty reasonable
   to say that key distribution protocols are hard 
   enough creatures that it requires a great deal of
   awareness from the right people to ask the right
   questions. Like, for example:

   1) my entropy question I ask in a previous piece of mail
   2) What is the key scheduling policy? On the client? On the server?
   3) How are cross realm relationships maintained?
   4) What are the security implications of cross realm distribution?
   5) How is revocation handled?
   6) What about name canonicalization?
   7) Are there hidden assumptions with other protocols
      which could cause trouble?

   etc, etc.

   A lot of these things are pretty subtle, and not
   always immediately obvious unless you've been 
   through the wars enough times. I know that I've
   had a few eye opening revelations before that are
   pretty obvious in hindsight.
     
 > resources.

   I'm not convinced about that. The WEP debacle
   should make everybody a little more cautious
   about rushing things through.
 
 > We just need a security review.

   And this I'm pretty dubious about. Getting a
   "security review" is no panacea. It takes time
   and energy to understand the system as a whole
   to find where protocol weaknesses are, and I'm
   pretty skeptical that these security reviewers
   actually have the time to really sit down and
   do that. It's *far* better to design something
   where those security reviewers are throwing rocks
   along the way instead of trying to make sense of
   a complicated system in a two week last call
   period.

 > Please don't bundle me in that work.

   I'm not. I'm just trying to point out that lack
   of security people watching along the way has
   already lead to one meltdown. What this is attempting
   is even more ambitious, IMO.

	   Mike

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 30 Sep 2001 07:34:41 -0700

> hindsight were riddled with ambiguities. If only the original language

check. I was simply providing the info as a data point.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 30 Sep 2001 07:39:19 -0700

>    key reuse, especially for rekeying?

no key is ever sent encrypted or otherwise. All that is sent is keying
material, which the mobile uses to create the actual key. The key creation
process does require the long term MN/AAA key.

> Is there a way

Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
to be sent to the mobile. So, using today's protocol, the answer is no.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 30 Sep 2001 07:42:19 -0700

>       which could cause trouble?

I hear your concern. All of the above, with the exception of one, is
handled in the Diameter MIP application. Unfortunately, it is spread out
throughout the spec. Perhaps a recap in the security considerations would
be a good idea.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 30 Sep 2001 07:49:30 -0700

> management is more scalable, not less scalable, in all the

you know what I meant. We talked about PKI scaling at Sun, and how its
reliance in binding updates didn't make me comfortable. I wasn't trying
to address the current work in progress, which I haven't spend one ms
looking at.

I'm sure that the new solution will be much better, and will address
my concerns. I just didn't want to take Mike's BS that I was the one
involved in this one to try to show how AAA keys is bad.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 30 Sep 2001 07:52:46 -0700

well, seems like I did it again. I thought this was a private e-mail from
Charles, and my reply all kicked me in the * again :(

It wasn't meant for global distribution, and hope no one takes offense to
what I said. 

sigh... better get coffee and wake up a little before continuing :(

PatC