Problem Statement for bootstrapping Mobile IPv6 (MIPv6)
draft-ietf-mip6-bootstrap-ps-05

[Ballot comment]
s/man in the middle/man-in-the-middle/

  Section 5.2.1 says:
  >
  > Using certificates may require the MSP to deploy a PKI, which may
  > not be possible or desirable in certain circumstances.
  >
  I suggest:
  >
  > In many deployment circumstances, certificates are not easily
  > supported by traditional AAA infrastructures.

[Ballot comment]
The claim in section 5.2.1 that use of certificates would require
deploying a PKI is false.  I do agree that certificates do not align
well with AAA. I'd recommend rewording as "Certificates are not easily
supported by traditional AAA infrastructures."

[Ballot discuss]
First, thanks for a good job on a well written problem statement.  My
concerns here are concernes about the document but can be interpreted
as early warnings about the direction the WG seems to be taking.
Addressing the concerns against the document can probably be done very
simply, but it is important to discuss the working group's direction
now to make sure that you will not end up with a discuss challenging
something fundamental about your solution when it comes to the IESG.

In section 7.2 you discuss using the authentication to both set up
network access and mobility access.  I don't think this is compatible
with how the EAP working group and security area invision EAP being
used. For example the key management framework requires that all keys
based on the EMSK be generated at the beginning of the exchange. We've
explicitly resisted several attempts to use EAP keying information
used to set up network access to later generate keys for other
purposes.  Both mobility and network access are at least valid EAP
applications.  I recommend that you note that the question of whether
this authentication can be reused is open in your document.  I
recommend that you get together with Russ Housley, Jari, myself and the EAP
community and decide whether this use is OK before designing a
solution that assumes you will be able to do this. 

I'm assuming that this problem statement is for a standards track
solution.  As such, I don't think considering RFC 4285 is appropriate.
In particular I don't think it makes sense for us to base standards
trackrequirements on a protocol we were unwilling to standardize.  It
feels too much like using the informational RFC series as a mechanism
for doing ongoing standards work without meeting our requirements for
review.  If the working group believes that something like RFC 4285 is
needed, then the working group should commit to doing the necessary
work to make a standard in this space: write a service model for
Mobile IP security and then write both the authentication protocol and
the IPsec security solution as architectural blocks that fit that
model.  If the working group does not want to do this work, then RFC
4285-like solutions need not influence requirements here.

[Ballot comment]
From Gen-ART review by Elwyn Davies:

...There are a small number of very minor issues and questions plus a fair number of editorial nits...

The detailed review with these points is posted at
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mip6-bootstrap-ps-04-davies.txt

[Note]: '1/12/06:  Update needed to address mdir reviews that were sent to the WG?  Also, need to send my comments to WG.' added by Margaret Wasserman

[Note]: '1/12/06:  Update needed to address mdir reviews that were sent to the WG?  Also, need to send my comments to WG.' added by Margaret Wasserman