Subject: [Mipshop] Gauging interest in official WG adoption of internet drafts

From: gabriel montenegro <[email-masked]>
Date: Tue, 21 Mar 2006 23:49:36 -0800 (PST)

Folks,

In today's meeting we talked about 4 potential items up for adoption as official working
groups. Talking with folks after the meeting, we've decided to add two more to the list
of items we'll ask the WG whether we should adopt. This is the follow-up email to today's
discussion, to make sure we ask this on the mailing list.

So the question to the WG is: Should we adopt the following documents as official WG
items (based on the individual drafts as noted below)?:

1. draft-ietf-mipshop-fmipv6-rev-XX.txt 
based on draft-koodli-mipshop-rfc4068bis-00.txt

2. draft-ietf-mipshop-handover-keys-aaa-XX.txt 
based on  draft-vidya-mipshop-handover-keys-aaa-01.txt

3. draft-ietf-mipshop-handover-key-send-XX.txt 
based on draft-kempf-mobopts-handover-key-01.txt (currently expired)

4. draft-ietf-mipshop-fh80216e-XX.txt 
based on draft-jang-mipshop-fh80216e-02.txt

5. draft-ietf-mipshop-3gfh-XX.txt 
based on draft-yokota-mipshop-3gfh-02.txt

6. draft-ietf-mipshop-cga-cba-XX.txt 
based on draft-arkko-mipshop-cga-cba-03.txt

Please send comments one way or another through April 4, 2006.

Thanks,

chairs

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 Mar 2006 07:19:20 -0800

I support making these documents into WG documents for the MIPSHOP WG.

            jak

----- Original Message ----- 
From: "gabriel montenegro" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 21, 2006 11:49 PM
Subject: [Mipshop] Gauging interest in official WG adoption of 
internetdrafts

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 22 Mar 2006 21:26:05 -0600

I support a WG adoption of all document. 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 25 Mar 2006 19:25:55 -0500

I have a reservation on draft-vidya-mipshop-handover-keys-aaa-01.txt.

The draft describes a AAA-assisted key management protocol to generate
handover keys for protecting signaling between MN and AR.  I am
viewing the proposal as an application keying for FMIPv6 and possibly
other protocols.  However, in the IETF65 hoakey BOF, Sam Hartman, a
Security AD, raised concern on application keying.  As a consequence,
the hoakey BOF chairs made a decision to exclude application keying
from the BOF charter, expecting application keying to be discussed in
a separate BOF.

Thus, it might be wiser to hold this draft until there is a clear
consensus on how to deal with application keying in the IETF.

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 25 Mar 2006 17:36:46 -0800

Disclaimer: I work with one of the authors (Vidya) of the 
handover-keys-aaa I-D, although didn't contribute to the draft in anyway.

I just read the parts of the I-D that seem to be contentious and note 
that the reference to AMSKs is merely an example and the HMK can be 
established through other means, say by preprovisioning.

That said, I think it is best to remove Appendix A (I am not sure 
about A.1, that probably should stay and resolved later) as it 
reproduces a key hierarchy and key derivation process that is still 
under active discussion.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 25 Mar 2006 21:22:01 -0500

As far as I understand, Sam's concern is not only on application
keying using AMSK but also AAA-assisted application keying in general.
So I am not sure if your suggested remedy really addresses the
concern.  I'd suggest asking Sam's opinon before moving forward.

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 25 Mar 2006 20:36:06 -0800

Hi,

I wonder what gave you that impression.  My understanding of Sam's 
take is (from the HOAKEY BoF and elsewhere going back to ISMS work 
etc) that EAP applicability statement has something to say about the 
use of keying material from EAP for things other than access 
authentication.  (I'll also note that that discussion/debate continues).

That aside, there is no objection to AAA-assisted keying from him.

In addition to what I wrote earlier, I suggest to Vidya et. al., to 
describe desirable properties of the HMK, key length, lifetime, so 
that any mechanism that bootstraps that key can take those properties 
into consideration.

best regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 26 Mar 2006 01:21:52 -0500

I had such an impression because Sam used the term "single sing-on"
and he seems to like to see wider aspect of bootstrapping multiple
applications in a separate BOF not just bootstrapping them from EAP or
AAA.  If the intent of the draft is bootstrapping multiple
applications not just FMIPv6 (there is text in Sectionn 1.2: "Although
this document is focused on FMIPv6, it is applicable to other
protocols as well."), then I believe this could be covered by such a
BOF.  On the other hand, if the intent of the draft is bootstrapping
*FMIPv6 only*, it would be OK, but then I don't see much usefulness of
the draft because I don't believe a sceanario where a AAA server needs
to maintain a shared secret for each application.

In any case, earlier contact to security AD would be much better to
avoid the risk of last minute surprise.

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 26 Mar 2006 02:32:18 -0800

Probably my final email on this.

Sec 1.2 hints on where the protocol might be used.  My guess is those 
notes are merely guidelines for potential reuse.

On the single sign-on vs. maintaining a shared secret at a AAA server 
per application, that is a bigger and more importantly orthogonal 
problem, isn't it?  We don't expect this draft to address that 
problem.  If you think about it, it is not a bad idea for 
applications to define their keying requirements, in parallel to 
solving the problem of scalable key provisioning.  In fact, that is 
what I had in mind for suggesting to the authors to list the 
desirable properties on the HMK in this draft.

Hope that helps clarify how I see things.

best wishes,
Lakshminath

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Mar 2006 14:45:00 +0200

> based on draft-koodli-mipshop-rfc4068bis-00.txt

I support the adoption of this document as WG item, hoping that a good 
plan for advancing it exists.  The plan should take into account 
application-level user experience and implementation experience, and 
rely on quantitative evaluation of benefits the protocol brings in.

I am neutral on the other documents as WG items.

Alex

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 27 Mar 2006 23:07:06 +0300 (EEST)

Hi,

I support making the first two and the last three items WG items.
Concerning the third item, I'd like to mention that the OptiSEND
proposal (draft-haddad-mipshop-optisend-01), while not complete yet,
allows the MN to share a secret with the *first* AR and to use it to
authenticate ND signaling messages *and* mobility signaling messages
exchanged between an AR and the MN during the MN movements and as
long as the shared secret remains valid.

Regards,

Wassim H.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Mar 2006 12:56:20 -0800

Wassim,

As we've discussed offlist, context transfer of keys between ARs has the 
potential to violate the Housley Critera:

http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-02.txt

Russ' draft is written specifically with AAA key management in mind, but the 
criteria apply to other types of key management as well. I skimmed your 
draft, and it seemed to me that there might be a problem.

Rajeev and I have been working on this draft for over a year, and it was 
transferred from MOBOPTS with the recommendation that it become a WG draft. 
If you manage to come up with some way to reduce the amount of signaling 
involved in SEND-based key exchange for handover that is consistent with the 
Housley Critera, I would have no problem incorporating that into the WG 
draft at that time. Gab and Stefano can correct me if I am wrong, but I do 
not believe we are in a hurry to get this draft to the IESG, so there should 
be plenty of time to incorporate enhancements that you or any WG member 
would like to include.

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "gabriel montenegro" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 27, 2006 12:07 PM
Subject: Re: [Mipshop] Gauging interest in official WG adoption of 
internetdrafts

---

From: "James Kempf" <[email-masked]>
Date: Mon, 27 Mar 2006 15:38:57 -0800

Hesham,

Public key crypto is not in the critical path for handover. The SEND draft 
specifies that public key crypto be used for key distribution, not handover 
message authentication. Or was there some other problem you see with the 
SEND draft?

And, like I said, if Wassim or anybody else comes up with some cool 
technology to make key distribution be more efficient, then we can certainly 
incorporate it, that is what a WG draft is all about.

Regarding whether context transfer of keys should be used or not, you need 
to take up that issue with the SAAG. I think it is fair to say that, 
regardless of deployment, they have a low opinion of it. 3GPP would argue 
that their networks are tightly controlled from an administrative standpoint 
so therefore someone breaking into one of their base stations is very low 
probability, and, while that might be true of their networks, it is not true 
of all networks. Internet standards are targetted at a somewhat broader set 
of deployment scenerios, which, I think, would be Russ' argument against 
context transfer of keys in an Internet standard.

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Wassim Haddad" 
<[email-masked]>; "gabriel montenegro" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 27, 2006 2:32 PM
Subject: RE: [Mipshop] Gauging interest in official WG adoption 
ofinternetdrafts

Russ' draft is written specifically with AAA key management in mind, but the
criteria apply to other types of key management as well.

=> Independently of the draft being discussed, I think it's unrealistic
to say that no keys can be transferred. The only alternatives are: a trip to 
AAA
or the use of public keys for each handover. I really don't think either one 
is
better for a handover. However, I'd be open to including them as 
alternatives.
But I certainly wouldn't dismiss CT of keys, I think it's unrealistic. Also,
this is what most cellular systems do today, starting from GSM onwards.

Hesham

I skimmed your

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "gabriel montenegro" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 27, 2006 12:07 PM
Subject: Re: [Mipshop] Gauging interest in official WG adoption of
internetdrafts

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 27 Mar 2006 17:17:30 -0800

The purpose of SEND-based key derivation for handover is to obtain a 
handover key for securing FMIP signaling (Primarily FBU). Whereas a 
general-purpose solution may be desirable, our experience with such 
efforts indicate the pitfalls associated with subtlety. So, I prefer to 
keep the scope of the _current_ WG item to securing FMIP signaling. 
Perhaps in the future, enhancements may be considered.

Regards,

-Rajeev

James Kempf wrote:
> Russ' draft is written specifically with AAA key management in mind, but 
> the criteria apply to other types of key management as well. I skimmed 
> your draft, and it seemed to me that there might be a problem.
> 
> transferred from MOBOPTS with the recommendation that it become a WG 
> draft. If you manage to come up with some way to reduce the amount of 
> signaling involved in SEND-based key exchange for handover that is 
> consistent with the Housley Critera, I would have no problem 
> incorporating that into the WG draft at that time. Gab and Stefano can 
> correct me if I am wrong, but I do not believe we are in a hurry to get 
> this draft to the IESG, so there should be plenty of time to incorporate 
> enhancements that you or any WG member would like to include.
> 
>            jak
> 
> 
> ----- Original Message ----- From: "Wassim Haddad" <[email-masked]>

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 28 Mar 2006 20:01:38 +0300 (EEST)

On Mon, 27 Mar 2006, Soliman, Hesham wrote:

> => Well, the key distribution would need to be repeated every time you
> move unless you CT keys right?

=> This is why I am not sure about it. I mean on one one side, we are trying
to eliminate the use of CGA in OptiSEND as much as possible and IMHO we'll
achieve this goal. And OTOS, we're bringing CGA back *just* for generating
a "handoff key" while we have a symmetric key generated in OptiSEND, which
can be used for different purposes including handoff signaling!

Regards,

Wassim H.

> regardless of deployment, they have a low opinion of it.
>
> => With all respect to SAAG, I think they're being inflexible about this
> and the reasons are not that clear. This is a problem in more than one
> aspect of security in IETF. Everything is being done in isolation without
> providing flexibility for complementing aspects of deployment or even
> describing when things can be "worked around" in a safe manner.
>
>
> Internet standards are targetted at a somewhat broader set
> => Sure, but it's strange IMO to limit everything else by assuming that
> the *only* mode of operation is the one that requires 100% security of
> each protocol independently of the deployment scenario. That's what SHOULDs
> are for, as opposed to MUSTs.
>
> Hesham
>
>
>             jak
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 27 Mar 2006 14:32:25 -0800

=> Independently of the draft being discussed, I think it's unrealistic
to say that no keys can be transferred. The only alternatives are: a trip to AAA
or the use of public keys for each handover. I really don't think either one is 
better for a handover. However, I'd be open to including them as alternatives. 
But I certainly wouldn't dismiss CT of keys, I think it's unrealistic. Also, 
this is what most cellular systems do today, starting from GSM onwards. 

Hesham

I skimmed your 

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "gabriel montenegro" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 27, 2006 12:07 PM
Subject: Re: [Mipshop] Gauging interest in official WG adoption of 
internetdrafts

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 27 Mar 2006 20:22:51 -0800

Hesham

            jak

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Wassim Haddad" 

Hesham

I skimmed your

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "gabriel montenegro" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 27, 2006 12:07 PM
Subject: Re: [Mipshop] Gauging interest in official WG adoption of
internetdrafts

---

From: "James Kempf" <[email-masked]>
Date: Tue, 28 Mar 2006 13:45:41 -0800

Regarding draft-ietf-mipshop-handover-keys-aaa-XX.txt, I'd like to propose 
that the WG adopt the draft as a WG draft and then request an early review 
from the Mobility Directorate. This should address any architectural 
concerns about the use of AAA to distribute application-specific keys, and 
key derivation, which, as Yoshi pointed out, were areas of concern during 
the hokey BOF.

          jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 28 Mar 2006 13:52:21 -0800

jak>> The protocol is set up so that the key provisioning takes place as a 
side effect of the RS/RA that the MN and AR need to exchange anyway for 
movement detection. So there is no separate signaling for key provisioning.

            jak

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 29 Mar 2006 03:26:30 +0300 (EEST)

> movement detection. So there is no separate signaling for key provisioning.

=> That's fine but I assume that the MN has to use CGA with each RtSol
message or am I missing something?

Regards,

Wassim H.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 29 Mar 2006 11:43:36 -0500

This works for me.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Wed, 29 Mar 2006 09:59:14 -0800

The MN uses SEND with the RS/RA for security on the Neighbor Discovery 
messaging, according to RFC 3791, a Proposed Standard.  The FMIP SEND-based 
key exchange protocol uses an extra ND option for an FMIP enabled  router to 
return a shared key for use in securing the FMIP signaling. This is 
accomplished as part of the RS/RA signaling that is used for IP level 
movement detection. RSA encryption is used to encrypt the key, not for the 
actual authentication of the FMIP signaling, that uses AES. The key exchange 
occurs once per IP level handover as a side effect of the unavoidable IP 
level movement detection, so there is no impact on handover latency.

If you have a problem with SEND, I suggest you talk to the INT or SEC ADs 
about starting a working group in order to address it. It seems to me that 
this is what optiSEND is trying to do, it has nothing to do with FMIP. This 
working group, MIPSHOP, has as a chartered work item security protocols for 
FMIP. It does not have on its charter changing SEND. Since FMIP is going to 
become a Proposed Standard, the security must be based on Proposed Standard.

Furthermore, as I've said past emails on this list, if and when the draft 
becomes a WG draft, anyone who has interesting technology that might be 
included is welcome to propose it, we'll discuss it, and we can put it into 
the draft, if the working group approves. That includes CT for key exchange 
*provided* it is acceptable to SAAG and the SEC ADs (which, from my reading 
of draft-housely, it isn't). I think the issue of CT is completely 
independent of optiSEND, it could as well be used with the proposed FMIP 
SEND key provisioning protocol described in draft-kempf.

Anyway, that's really all I have to say on this topic, since we don't really 
seem to be making much progress in the discussion. I'll wait to post further 
comment until Gab and Stefano have tallied everyone's opinion and made a 
concensus call.

            jak

----- Original Message ----- 
From: "Wassim Haddad" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; "gabriel montenegro" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 28, 2006 4:26 PM
Subject: Re: [Mipshop] Gauging interest in official WG 
adoptionofinternetdrafts

---

From: "Junghoon Jee" <[email-masked]>
Date: Thu, 30 Mar 2006 03:37:53 +0900

I am also in the same line.

Thanks,
-Junghoon

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Mar 2006 11:25:21 -0800

I also support James' proposal.
In addition, I would like the chairs to make certain that we are not
entering into the domains of other WGs or BOFs, e.g. Hokeyp.

Regards,

Behcet

Junghoon Jee wrote:

>>------------------------------------------------------------------------
>>