Subject: Remaining open issues for RFC-2401bis

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 16 Mar 2004 13:29:34 -0500

In an attempt to try to drive rfc2401bis to closure, the following
represent the open issues with the draft.  Please let us know if we have
missed anything.

As you will note, we are starting a working-group last call on the new
process model, and selector name clarification issues for the end of the
week.  For the rest of the issues, we would like to encourage the
working group to focus the discussion and try to come to a consensus as
soon as possible.  

We are am particularly concerned by the fact that there has been
essentially no discussion for issue #91 (Incoming ICMP handling).  If we
do not get any support for issue #91, we propose that we revert to RFC
2401 text with respect to this issue.

					- Ted and Barbara

1.  New processing model (issues #44, #45)

	There appears to be current consensus on the list about the
	overall approach, although there have been some requests to
	clarify the text.  If any disagree with the general direction
	utilized by the processing model, please make your concerns
	known by the end of the week.  At that time, issues #44 and #45
	will be marked as closed in the roundup database.  People who
	have suggestions on how to clarify any part of the specification
	are encouraged to continue make them.

2.  fragmentation handling (issue #92, #88)

        Actively being discussed.  Steve Kent is preparing a five page
	exposition on the issues that will hopefully help to focus the
	discussion.  

3.  Incoming ICMP error message handling (issue #91)

	There has currently been no discussion on issue #91.  If we
	don't get movement, we may need to go back to the RFC 2401 text,
	which makes it be a local matter.  If so, we will need to add
	back the path mtu handling text which was dropped in the -01
	version of the ID.

4.  selector name clarification (issue #93)

        Seems straightforward, and there has been no disagreement on the
        mailing list.  If any disagree with the text suggested by Karen
        on February 25th, please make your conerns known by the end of
        the week.

5.  Defined ICMP response to unprotected inbound packets that require
    protection.  (Issue #83)

	This was initially raised by Steve Kent and Karen Seo, and
	accepted by the working group.  It was later withdrawn by Steve
	because of performance concerns in high-speed applications.
	Possible outcomes: 

	1.  The working group explicitly chooses to drop this issue.
	    In this case, what to do in the case where an inbound
	    packet is dropped is a local issue, with the text being
	    completely silent about what should happen when a packet
	    is discarded.

	2.  The "SHOULD be capable of generating an ICMP message" is
	    changed to "MAY", with the definition of the ICMP packet to
	    be sent (should the implementation so choose and/or is
	    configured to do so) being defined in RFC 2401bis.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 19 Mar 2004 09:53:11 -0800

>         on February 25th, please make your conerns known by the end of
I asked for a clarification for which i got no response. For one of the cases,

d. a user's name in a local system context
   (this corresponds to ID_KEY_ID in IKEv2)

ID_KEY_ID carries opque octet stream. So, why limit this to user's name ?
It looks like RFC 2401 supported OPAQUE values but i could be reading
it wrongly.

-mohan

---

From: Karen Seo <[email-masked]>
Date: Fri, 19 Mar 2004 20:04:45 -0500

Mohan,

I'm sorry.  It's my fault that you didn't get a prompt reply.  I 
wrote up something and then got distracted by other tasks.  Reply 
below....

>It looks like RFC 2401 supported OPAQUE values but i could be reading
	Well, if we allow this to be any octet string,
	then it presents complications for the user/management
	interface.  So we'd like to limit it to a text string
	containing alphanumeric characters, but not a binary
	string, etc.

Karen

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Mar 2004 19:12:39 -0600

> 	containing alphanumeric characters, but not a binary

I thought ID_KEY_ID was supposed to be the public key of the cert...

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 19 Mar 2004 19:00:50 -0800

8bit or 7bit text string?

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 19 Mar 2004 23:15:47 -0500

> 	containing alphanumeric characters, but not a binary

current best practice for ietf protocols is that strings which are
intended for human display in protocols should come with language
tags.  (why do I know?  sshv2 bit this bullet a while ago...).  see
rfc3066

						- Bill

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 20 Mar 2004 07:30:32 -0800

>tags.  (why do I know?  sshv2 bit this bullet a while ago...).  see

That is a mis-reading of RFC 3066. RFC 3066 shows how to do it if 
there is a need for using different languages: it does *not* 
recommend adding language tags to any particular text. Language tags 
should be used on free text that is meant to be read and understood 
by a reader where the ambiguity might cause problems. That is not 
true for names.

Having said that, if we have a field that is supposed to handle 
human-generated names such as "account names" (the words used in 
IKEv2), it needs to handle the names of people whose language is 
other than English. IKEv2 says "octet stream", and it means "octet 
stream"; it does not mean "octet stream where we impose this 
particular text encoding and then limit it further by saying which 
characters are and are not allowed".

This is an exact-lookup field; if the user/management interface can't 
handle all values that might appear, that is a problem with the 
interface, not the protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Sat, 20 Mar 2004 15:36:05 -0500

>>>>> "Bora" == Bora Akyol <[email-masked]> writes:

 Bora> 8bit or 7bit text string?

 >> Well, if we allow this to be any octet string, then it presents
 >> complications for the user/management interface.  So we'd like to
 >> limit it to a text string containing alphanumeric characters, but
 >> not a binary string, etc.

7 bit text string?  Surely you're joking.

If something is supposed to be human-interpreted text then there's
only one answer, namely UTF-8.

     paul

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 20 Mar 2004 13:25:53 -0800

>only one answer, namely UTF-8.

But IKEv2 doesn't say it is text. The exact words from the IKEv2 draft are:
             An opaque octet stream which may be used to pass an account
             name or to pass vendor-specific information necessary to do
             certain proprietary types of identification.
"Octet stream" means "octet stream", not text. If we mean "text", we 
should say "text" and give the one text encoding that all 
implementations must use; obviously, that would be UTF-8. 
"Vendor-specific information" might not be text.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Sun, 21 Mar 2004 14:07:30 -0500

>>>>> "Paul" == Paul Hoffman </ VPNC <[email-masked]>> writes:

 >> only one answer, namely UTF-8.

 Paul> But IKEv2 doesn't say it is text. The exact words from the
 Paul> IKEv2 draft are: An opaque octet stream which may be used to
 Paul> pass an account name or to pass vendor-specific information
 Paul> necessary to do certain proprietary types of identification.
 Paul> "Octet stream" means "octet stream", not text. If we mean
 Paul> "text", we should say "text" and give the one text encoding
 Paul> that all implementations must use; obviously, that would be
 Paul> UTF-8.  "Vendor-specific information" might not be text.

Agreed.  And an "octet string" field will of course serve nicely as a
container for UTF-8 if a particular vendor wants to put text there.

	  paul

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 21 Mar 2004 21:20:21 -0800

> containing alphanumeric characters, but not a binary
The value itself may be generated dynamically and added to the PAD before
the IKE exchange starts. All you need is an exact match of this content with
the content of the ID payload. If an UI cannot support certain strings, then
it won't be used automatically. Why do you have to limit them explicitly ?
It might be simpler to leave it as "opaque octet stream" specifying an
example e.g. user name.

-mohan

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Mar 2004 21:35:54 -0500

Paul,

Since all ID's sent via IKE are used for access control, it seems 
reasonable to assume that, in general, people have interacted with a 
management interface to enter these IDs. So, unless there is a need 
to transmit an arbitrary octet string for ID purposes, it would be 
more appropriate to constrain this to something that a user has a 
good chance of getting right.

The IKE v2 specs says (page 55)

	    "An opaque octet stream which may be used to pass an account
             name or to pass vendor-specific information necessary to do
             certain proprietary types of identification."

This hardly sounds like an arbitrary byte string.

IKE is very sloppy re choice of IDs, and this has not been fixed in 
IKEv2. for example, in addition to explicit support for e-mail 
addresses, IP addresses, and distinguished names, IOKEv2 calls for 
support of the general name construct. But, this construct already 
encompasses all of the preceding name types, plus others that seem 
very unlikely to ever be of interest in our context, e.g., EDI Party 
names! So, my suggestion is that we be a bit more restrictive with 
the supported name types. In that spirit, if we need to keep this as 
an arbitrary byte string, we ought to provide some rationale for that 
decision.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Mar 2004 14:00:16 +0200

>              certain proprietary types of identification."

Vendor-specific sounds to me like anything I simply like to put there,
including binary. Some uses for this has been proposed to support
total identity protection including active attacks, i.e. where you use
random ID_KEY_ID as your identity, and after you have connection ready
and authenticated from both ends, you run some protocol that will give
you new ID_KEY_ID to be used for the next time (this was mostly
suggested for IKEv1 aggressive mode, where ID's are in clear
otherwise).

For that kind of usage, I see no point why it should restricted to the
ASCII string. 

> This hardly sounds like an arbitrary byte string.

I think arbitrary octect string easier for multiple reasons. If we say
it is text we need to and the encoding to it (ISO 10646 UTF-8?). Doing
that causes unnecessary code on some clients and servers, which might
have the user database in latin-1 format or similar, and now they need
to convert it UTF-8 and back when sending it over the wire. Using
UTF-8 there does not help anything, as those implementations propably
do not know how to convert the strings to normal format (i.e. they do
not know how to convert a + umlauts to ä).

On the other hand the client and server will have common security
domain, which also defines the usernames, and the encoding used for
them, thus it does not cause any problems to encode the Latin-1
username string as binary latin-1 octect stream when sent inside the
IKE ID_KEY_ID. 

> names! So, my suggestion is that we be a bit more restrictive with 

If the client and server agrees that they will use the EDI Party names
(whatever that is) when identifying the each other, I do not see
problem with that. I do not think every implementation should
implement EDI Party name support though (it is not MUST)...

-- 
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 23 Mar 2004 08:10:09 -0800

At 9:35 PM -0500 3/22/04, Stephen Kent wrote:
>management interface to enter these IDs.

Fully agree.

>  So, unless there is a need to transmit an arbitrary octet string 
>for ID purposes, it would be more appropriate to constrain this to 
>something that a user has a good chance of getting right.

Also fully agree.

>This hardly sounds like an arbitrary byte string.

Fully disagree. "opaque octet stream" sounds exactly like "arbitrary 
byte string" to me.

>IKE is very sloppy re choice of IDs, and this has not been fixed in IKEv2.

Fully agree.

>  for example, in addition to explicit support for e-mail addresses, 
>IP addresses, and distinguished names, IOKEv2 calls for support of 
>the general name construct. But, this construct already encompasses 
>all of the preceding name types, plus others that seem very unlikely 
>to ever be of interest in our context, e.g., EDI Party names!

I tried to get this fixed a while back, and was shot down.

>  So, my suggestion is that we be a bit more restrictive with the 
>supported name types. In that spirit, if we need to keep this as an 
>arbitrary byte string, we ought to provide some rationale for that 
>decision.

Also fully agree. I'm happy if we change this field in IKEV to "UTF-8 
text string" (changing it to ASCII is not a reasonable option). 
However, I'm not happy with leaving IKEv2 alone and having that 
requirement (or, even worse, that assumption) come in 2401bis. If 
IKEv2 is left as it is, 2401bit should not change the interpretation 
of the field. Otherwise, boxes that follow 2401bis might fall over 
when handed a non-UTF-8 octet stream.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 11:25:09 -0500

>suggested for IKEv1 aggressive mode, where ID's are in clear

so, the problem we have is that the same ID type 
is defined to have two different uses: an account 
name, for which an IA5 or UTF-8 string would be 
appropriate, or an arbitrary byte sting, for 
which no further encoding is appropriate. I would 
be happy if we choose ONE of these two, but 
having both listed is a recipe for 
non-interoperability.

As for using a random number as an ID, note that 
this may not play well with the PAD description 
that we published.

>not know how to convert a + umlauts to ä).

I agree that IF the intent is to send an 
arbitrary byte string for a vendor-specific 
purpose, then UTF-8 encoding is inappropriate. 
However, if the intent is to send a user account 
name, then such encoding is appropriate. That's 
why I suggest that we disentangle these two 
different uses for the field.

>username string as binary latin-1 octect stream when sent inside the

I disagree. There is no reason to believe that 
there will be an appropriate management interface 
to allow for easy entry of a UTF-8 account name 
by a user or admin if the only requirement is to 
support binary values for this field.

>implement EDI Party name support though (it is not MUST)...

same argument as above, For interoperability we 
want to ensure that any ID form that either end 
may use will be easy to enter and manage by 
everyone. Unless we have some good reason to 
believe that EDI Part names, and X.400 addresses 
are appropriate ID forms for IPsec, then  we 
ought not provide a means to carry them, since 
such carriage should be matched by a requirement 
for a management interface for them in every 
IPsec implementation.

Flexibility is not free if we want 
interoperability at the same time. If we make 
provision for carriage of arbitrary strings as 
IDs in IKEv2 mandatory, then we have a 
responsibility to ensure that IPsec 
implementations have a means to make use of them 
when the arrive. Otherwise we create 
opportunities for non-interopeability.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 11:27:51 -0500

At 6:38 AM -0800 3/23/04, Joe Touch wrote:
>Stephen Kent wrote:
>>reasonable to assume that, in general, people have interacted with 
>>a management interface to enter these IDs. So, unless there is a 
>>need to transmit an arbitrary octet string for ID purposes, it 
>>would be more appropriate to constrain this to something that a 
>>user has a good chance of getting right.
>>
>"opaque" isn't particularly vague on that point ;-)
>
>It specifies an arbitrary byte string, by definition. There is no 
>semantics for the string at the IKE level, so there should be no 
>restrictions on its contents.
>
>Joe

See my response to Tero. The IKE text is schizophrenic on the 
semantics, and there are interoperability implications with viewing 
this in both ways.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 12:19:32 -0500

Paul,

I think we're in close agreement on essentially all points, including 
UTF-8, not ASCII, if the WG chooses to narrow the scope of the ID 
semantics. I would rather not have 2401bis profile IKEv2, but I also 
reluctant to have gaps, so I thin iot is good to resolve this now.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Mar 2004 12:26:53 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Kent> Since all ID's sent via IKE are used for access control, it seems
Kent> reasonable to assume that, in general, people have interacted
Kent> with a management interface to enter these IDs.

Let's rephase this so that I agree:

      When IPsec is used for access control (such as VPNs or
      RemoteAccess), then all IDs sent via IKE are used for access
      control, it seems reasonable to assume that, in general, people
      have interacted with a management interface to enter these IDs.

Maybe this is a tautology. Maybe not.
As long as there is a mapping from the ID to the access control policy,
then I don't have a problem with this statement.

    VPNC> Also fully agree. I'm happy if we change this field in IKEV to
    VPNC> "UTF-8 text string" (changing it to ASCII is not a reasonable
    VPNC> option). However, I'm not happy with leaving IKEv2 alone and
    VPNC> having that requirement (or, even worse, that assumption) come
    VPNC> in 2401bis. If IKEv2 is left as it is, 2401bit should not
    VPNC> change the interpretation of the field. Otherwise, boxes that
    VPNC> follow 2401bis might fall over when handed a non-UTF-8 octet
    VPNC> stream.

  That's fine, but I personally see Kivinen's point.
  I don't know why a UTF-8 can't go into a different ID type.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 12:19:32 -0500

Paul,

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Mar 2004 20:22:23 +0200

> name, for which an IA5 or UTF-8 string would be 

There is no text in the IKEv1 defining it to be account name. IKEv1
defined it to be "an opaque byte stream which may be used to pass
vendor-specific information necessary to identify which pre- shared
key should be used to authenticate Aggressive mode negotiations."

This account name thing was added in the IKEv2, and I do not know why
it was added.

> having both listed is a recipe for 

Do we really need account name? Why cannot be use rfc822 address? 
How about using the ID_KEY_ID to send the uid of the unix machine
(i.e. the numeric user id, as 16/32 bit number (2/4 octects)).

> As for using a random number as an ID, note that this may not play
> well with the PAD description that we published.

Why not, after the new ID has been exchanged, both the server and
client, will simply reconfigure the PAD to include the new ID. 

> different uses for the field.

We already have rfc822 address for user account name, why would we
need separate account name id? The ID_KEY_ID is also defined to be
something that is NOT matched against anything in the certificates
etc, it is only matched against the built in policy (i.e. mostly
usefull in shared-key authentication). In those case the
bit-comparison is much better. 

> support binary values for this field.

Why should there interface to allow UTF-8 account names, if the only
thing the adminstrator is going to use it, is to account names in the
policy specified format.

If my account name is Törvelä, I will encode it in the same way
in my client and in my server, as they are most likely adminstrated by
the same persons. If the adminstrator cannot enter my account name, he
will propably say, that your new account name for the VPN use will be
"Torvela". 

> for a management interface for them in every 

If I undertand correctly, the general name is there, because it can be
matched against the certificate, and in some cases people might have
setup where they allow you to login if you just happen to have valid
certificate from that certain CA, and you can use any ID that can be
found from the certificate as your ID. The pki4ipsec wg is working on
that issue.

This issue does not cover ID_KEY_ID, as it will not be in the
certificates. If we say that ID_KEY_ID is octect string, and
adminstrators must allow support for any binary string there, then we
can put configure the system to use ISO 10646 UTF-8 account names,
uid, Latin-1 account or plain ASCII account names. If the
implementator is stupid and does not include easy way to enter the ISO
10646 UTF-8 account names, it does not still affect the
interoperability, it just makes the configuration harder. 

> opportunities for non-interopeability.

If we say it is opaque octect string, and implementationtions MUST
support any binary data up to 32 bytes in it, it defines exactly an
interoperable use for the ID_KEY_ID. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Mar 2004 14:21:21 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Why wouldn't an "account name" be represented as ID_RFC822_ADDR?

Perhaps the @domain may seem redundant to some, but it certainly
doesn't hurt anyone. If it was a big problem, I'd rather relax it to
make @-part optional than say any more than ID_KEY_ID says right now.

In particular, I think that an appropriate comparison function for
ID_KEY_ID is "memcmp()", while I'm sure that ID_RFC822_ADDR needs to
be parsed in some way and then compared in a more structured fashion.

Is UTF-8 welcome in ID_FQDN, ID_RFC822_ADDR?

- --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Mar 2004 14:36:11 -0500

-----BEGIN PGP SIGNED MESSAGE-----

(mostly, "What Tero said")

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    Tero> We already have rfc822 address for user account name, why
    Tero> would we need separate account name id? The ID_KEY_ID is also
    Tero> defined to be something that is NOT matched against anything
    Tero> in the certificates etc, it is only matched against the built
    Tero> in policy (i.e. mostly usefull in shared-key
    Tero> authentication). In those case the bit-comparison is much
    Tero> better.

  The reason I can imagine (now, after reading your message) is because
the certificate (not RSA key) doesn't have that rfc822 address in it,
and the gateway isn't cable of having policy indexed by anything not in
the certificate unless it is ID_KEY_ID.  
  (I think such a gateway is totally broken, though)

- --

---

From: Paul Koning <[email-masked]>
Date: Tue, 23 Mar 2004 15:43:28 -0500

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

 Michael> -----BEGIN PGP SIGNED MESSAGE----- Why wouldn't an "account
 Michael> name" be represented as ID_RFC822_ADDR?

Because not all accounts have English names?

	paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Mar 2004 16:52:41 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Koning <[email-masked]> writes:

    Paul> Because not all accounts have English names?

  1) we have ways of encoding UTF-8 into From:/To: lines, we could
     use that.

  2) we could agree to permit UTF-8 in RFC822_ADDR.

- --

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 23 Mar 2004 15:27:34 -0800

>   1) we have ways of encoding UTF-8 into From:/To: lines, we could

No, we don't. We have ways of encoding the display name and the 
coments, but *not* the address itself (called the "addr-spec"). RFC 
822 and 2822 are completely clear on this.

>   2) we could agree to permit UTF-8 in RFC822_ADDR.

Doing so and hoping that the Applications Area Directors don't barf 
is like applications folks saying "we can just send cleartext 
passwords in the clear here" and hoping that the Security Area 
Directors don't barf.

It is reasonable to have one plain text or an opaque binary 
identifier. There is no need to mess up one of the few clear 
identifiers we have.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Tue, 23 Mar 2004 20:04:31 -0500

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

 Michael> -----BEGIN PGP SIGNED MESSAGE-----

 Michael> 1) we have ways of encoding UTF-8 into From:/To: lines, we
 Michael> could use that.

Yes, but that's a kluge to retrofit other character sets into a 7-bit
limited protocol.  We don't need to carry those things forward into
non-ancient protocols.

	    paul

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Mar 2004 02:44:58 -0600

> Because not all accounts have English names?

Subverting ID_KEY_ID to carry UTF-8 does not fix any I18N shortcommings
of subjectAltName.

I18N has to be dealt with, but stuffing possibly unstructured UTF08 text
into an OCTET STRING in context specific ways isn't going to be very
useful.

I suggest that I18N be addressed separately and that ID_KEY_ID remain as
it is: opaque.  Does this mean that ID_KEY_ID is useless, that noone
knows what to really use it for?  Is it used much?  Can its semantics be
changed?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Mar 2004 02:57:01 -0600

> >something that a user has a good chance of getting right.

Note that SSH users manage to used public keys for authorization even
though the bits in those keys are almost meaningless to them.

My point is that users can handle items that look like gibberish.  Oh, I
know, it ain't pretty, and we'd all rather use names when interacting
with access control management interfaces, but that does not mean that
access control with opaque IDs can't be done.

> Fully disagree. "opaque octet stream" sounds exactly like "arbitrary 

Yes.  Of course, presumably initiators can figure out what to use as
ID_KEY_ID values, and presumbaly they can told what to use much the same
way that access control by ID_KEY_ID can be managed.

But it would be nice if there was a simple default content type for
ID_KEY_ID, such as, say, the public key of the cert.  This would bring
the "power" (forgive me) of secure shell hostkeys/pubkey userauth to
IPsec.

[...]
> when handed a non-UTF-8 octet stream.

Agreed, except that I think ID_KEY_ID should stay an octet string.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Mar 2004 03:04:57 -0600

> tags.  (why do I know?  sshv2 bit this bullet a while ago...).  see

Nit: UTF-8 has language tags also which can do when RFC3066 language
tags are not available.

But this is besides the point, my point that is, which I just made in
separate posts, and which is that secure shell proves that access
control by IDs that are fairly meaningless to users can be done and is
done everyday, and by many.  As to the I18N issues with the other ID
types, well, shoving UTF-8 into ID_KEY_ID hardly seems like a way to
address them (besides, saying "use UTF-8" is only the beginning, then
come string prep profiles and all that other fun).

Cheers,

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Mar 2004 09:47:58 -0500

-----BEGIN PGP SIGNED MESSAGE-----

Oh, re: UTF-8 identifier.

perhaps those that care could write a draft explaining their
requirement, and perhaps they could be first user of the IANA
IKEv2 registry.

- --

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Mar 2004 09:46:48 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> No, we don't. We have ways of encoding the display name and
    VPNC> the coments, but *not* the address itself (called the
    VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this.

  Ah, good point.

    >> 2) we could agree to permit UTF-8 in RFC822_ADDR.

    VPNC> Doing so and hoping that the Applications Area Directors don't
    VPNC> barf is like 

  Fine. Point made.
  So, we need an identifier that can carry UTF-8, is known to carry
UTF-8, and isn't ID_KEY_ID.

- --

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 2004 09:53:25 -0500

>This account name thing was added in the IKEv2, and I do not know why

neither do I. I did not go back to IKEv1 to see 
how the ID type was defined there, since the 
focus of 2401bis is IKEv2, but your point is well 
taken. If the WG is comfortable changing the 
dscriptipn back to what it was in IKEv1, then I 
agree that this is an arbitrary, potentially 
binary value, and my suggestion re human 
readable, character string encoding would not be 
relevant.

>(i.e. the numeric user id, as 16/32 bit number (2/4 octects)).

If the goal is to match account names precisely, 
then 822 addresses are not an ideal choice. I 
also would not suggest the Unix UID, since that 
is clearly an OS-specific approach. The goal in 
access control systems is to provide admins with 
name forms that mimic the ones that they are 
otherwise accustomed to dealing with. That's why 
a user login ID or account name is preferable in 
many cases.

>client, will simply reconfigure the PAD to include the new ID.

We had no plans to describe the PAD as a database 
that was dynamically reconfigured, but we also 
did not plan to say anything that would prohibit 
this.

>bit-comparison is much better.

As noted above, 822 addresses may be OK, but they 
are not ideal as a way to mimic a login ID.

>thing the adminstrator is going to use it, is to account names in the

I can't parse the above sentence.

>will propably say, that your new account name for the VPN use will be

The client and server may be produced by 
different vendors, and if only one provides a 
management interface for UTF-8 ID input, then 
there is a possibility that it will not be easy 
to get the two to match.  For example, in 802.11 
nets, I have had problems getting the passwords 
that are used as keys to match on routers/access 
points and my Apple computers, precisely because 
the management interfaces were not built to any 
standard.

>found from the certificate as your ID. The pki4ipsec wg is working on

The pki4ipsec WG document that deals with this 
also excludes GN, just as 2401bis has in its 
current draft. Requiring support for GN 
duplicates what we already mandate when we 
require support for DNs, 822 addresses, and IP 
addresses, plus it adds a requirement to support 
names forms like EDI party name and X.400 
addresses. Unless we believe it is appropriate to 
support these additional name forms, not to 
mention to "free form" name types that are part 
of GN, it is a bad idea to call for GN support.

>interoperability, it just makes the configuration harder.

my experience with 801.11 passwords says 
otherwise, i.e., it was not possible to configure 
the access point and my computers to interoperate 
because of the management interface discrepancies.

>interoperable use for the ID_KEY_ID.

Agreed. But, then we should not expect this ID 
type to be used to login/account IDs, since there 
is a chance that it will be infeasible for many 
folks to configure such ID types using only a 
binary representation.

Steve

---

From: Paul Koning <[email-masked]>
Date: Wed, 24 Mar 2004 14:30:48 -0500

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> At 8:22 PM +0200 3/23/04, Tero Kivinen wrote:
 >> If my account name is TÃ¶rvelÃ¤, I will encode it in the same way in
 >> my client and in my server, as they are most likely adminstrated
 >> by the same persons. If the adminstrator cannot enter my account
 >> name, he will propably say, that your new account name for the VPN
 >> use will be "Torvela".

 Stephen> The client and server may be produced by different vendors,
 Stephen> and if only one provides a management interface for UTF-8 ID
 Stephen> input, then there is a possibility that it will not be easy
 Stephen> to get the two to match.  

Actually, that's true even if both sides know UTF-8, since there are
multiple encodings for many cases.  There are 6 encodings, I think,
for the sting Tero gave.

This is what RFC 3454 is all about.  If you really want this thing to
be a human-meaningful string, you need to say it's UTF-8 AND you have
to specify what stringprep profile applies to it.

   paul

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 24 Mar 2004 11:36:09 -0800

> UTF-8, and isn't ID_KEY_ID.
I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an
opaque way. I think this is what Paul Koning mentioned in an earlier mail.

thanks
mohan

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBQGGfVYqHRg3pndX9AQFS0gP/REqyJFEuHwEdd84mjKL7eVu8OZ94VcB3
> QXNT18Tvzt/nGAoxqUbXv6IK11TMTbqC0uqR/kKm/Opuxa4OUNSKmvMUuiujufEe
> fSPZ8LuBzoZe/xX+v6LUQsb4jky7oTxy2jFX6lg6qpc542ZpXrlZsEMYzPJFN/iA
> KPtMeVAsWX0=
> =7eGq
> -----END PGP SIGNATURE-----

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 24 Mar 2004 11:33:04 -0800

> key should be used to authenticate Aggressive mode negotiations."
This was the main reason why i raised the issue i.e ID_KEY_ID is used
to select pre-shared key and it was defined to be a opaque octet stream
in IKEv1. This in conjunction with a road warrior case where the addresses
are not known a priori, you need to use the information in ID_KEY_ID as
selector. Please see draft-ietf-pana-ipsec-02.txt as an example of how
this ID_KEY_ID is used to carry a session-ID - which is an opaque
octet stream or possibly an UTF8 string carried in an opaque way.

> client, will simply reconfigure the PAD to include the new ID.

Yes, i don't see why this is in conflict with the PAD description in 2401bis.

-mohan

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 2004 14:58:23 -0500

Mohan,

>octet stream or possibly an UTF8 string carried in an opaque way.

Let me note, again, that 2401bis assumes IKEv2, in lots of places, so 
I don't think the use of this ID type in IKEv1 is central to this 
discussion. There have been lots of good arguments why one might 
choose to view this ID type a just a byte string, and why we might 
want to add another ID type for conveying login IDs, but references 
to IKEv1 are not among those good arguments :-)

>Yes, i don't see why this is in conflict with the PAD description in 2401bis.

I said this MAY be in conflict because there is not mention of PAD 
entries being dynamically changed as a side effect of an initial IKE 
exchange.  And, as you may guess, I had not envisioned a context 
where that would be required. In 2401 we needed to consider dynamic 
SPD entries to accommodate road warriors. That is no longer the case, 
because of the SPD cache in the model, and because of the 
introduction of the PAD. I'm not claiming that there are no reasons 
to have dynamic PAD entries, but none occurred to us in writing 
2401bis.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 2004 15:00:34 -0500

>opaque way. I think this is what Paul Koning mentioned in an earlier mail.

For the reasons cited earlier, I think it is a bad idea to carry 
structured data like UTF-8 in what is described as an opaque octet 
string. there is no reason to assume that there will be management 
interfaces to facilitate entry of the data in a compatible fashion, 
even without the encoding options that Paul has pointed out.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Mar 2004 17:03:31 -0600

> even without the encoding options that Paul has pointed out.

Can you clarify whence the name of this ID?

I think that the name, ID_KEY_ID, is consistent with use of the public
key of the cert as the ID value.  But just because the name seems to
imply that doesn't mean that that was the original intention.

Nico
--

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 24 Mar 2004 15:16:51 -0800

> Let me note, again, that 2401bis assumes IKEv2, in lots of places, so 

But where possible, it should still work with IKEv1.

> to IKEv1 are not among those good arguments :-)
ID_KEY_ID was used in IKEv1 in a particular way as Tero mentioned
in the other email. One would like that to still work with IKEv2. Please
see the other draft that i mentioned. It is useful to have opaque identifiers
that are established by other means and use it as an ID to select  the
pre-shared key.

> to have dynamic PAD entries, but none occurred to us in writing 
Ok. So, to accomodate the dynamic creation of PAD entries i.e not through
an user interface, can we still include the ID_KEY_ID as specified in IKEv1 
as a selector and define a new type for login names etc. which would
also be another selector?

thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 24 Mar 2004 15:30:46 -0800

> even without the encoding options that Paul has pointed out.
ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be
carried as an opque stream of bytes where the two ends do a "memcmp" of the
opaque byte stream to match on the ID contents. Why is this not possible ?
As i mentioned in the other mail, this content may be dynamically generated. 
Perhaps we need a different ID to carry structured data like UTF8 that will be
created through mangement interfaces. At least, that is what i understood from
the emails on this topic.

-mohan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Mar 2004 09:45:00 -0500

>the emails on this topic.

My comments on management interfaces for this ID type get at the 
heart of the problem, and I'm a bit disappointed that your messages 
seem to keep ignoring that. This discussion has never been about how 
to perform a comparison of the data; it is about whether users and 
admins interacting with different vendor products will have 
appropriate management interfaces to enter the data that is sent and 
that forms the basis for checking, IF the description of the 
semantics of the data were as stated in IKEv2.

Nonetheless, I agree that a good way to resolve this is to change the 
IKE text back to the v1 version, that makes no mention of account IDs 
etc.

Then, if the WG wants, a separate ID type can be created to carriage 
of account info such as login IDs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Mar 2004 10:13:16 -0500

At 3:36 PM +0200 3/25/04, Tero Kivinen wrote:
>The unix UID was one example of IDs implementators might want to use
>for the ID_KEY_ID.

as an example it is fine.

>For example the unix kernel only knows about user IDs, it does not
>know about user logi IDs or account names, and there is no way to map
>user ID to user name (there might be multiple user names with same
>user ID). Because of that if IPsec is used between two unix machines
>belonging to the same NIS domain etc (== same UIDs) it would make
>perfect sense to use the UID as a ID inside the IKE (when creating per
>UID SAs between two hosts).

I think I'm not communicating well here. As a 
user and for most admin functions, login names 
will be used for access control, nit the internal 
UIDs that the kernel sees. My concern is that if 
we intend to represent character string IDs in an 
ID type, then it behooves us to use a suitably 
restrictive syntax for that purpose. the 
reasoning is that a vendor will offer a 
management interface appropriate for a given 
syntax and we want the management interface to be 
easy for users and admins, not only because it 
makes life easier, but because it helps avoid 
management-induced vulnerabilities.

>Again this was simply an example how the ID_KEY_ID can be used. In
>some other environment it might be used completely differently.
>
>>  to get the two to match.
>Yes, but if both ends provides way to enter binary data, it is always
>possible to make them match. You simply take the UTF-8 formatted ID
>from the server, and configure that in to the client as binary octect
>string. No problems with different ways to encode the umlauts etc in
>the login name.

no problme encoding at a low level, but a big problem entering the data.

>And the reason is, that somebody assumed that the password is plain
>ASCII, or any text. If they only way to configure it in is the
>hex-string or similar, then there would not be problems...

but the point was that vendors acted in what they 
believed was a reasonable way give a lack of 
syntactic direction. hex would be workable, but 
is often harder for a user.when Apple user ASCII, 
I could use a pass phrase as the key. when I had 
to use hex to enter the data, life became much 
harder, and it took several tries to get the same 
data into the access point and each machine. does 
anyone think that's a feature?

>That is exactly the reason I do not like the idea of UTF-8 there. It
>requires the implementators to actually do something for that. Quite
>often they say, ok, I create this dialog box, which supports any
>characters, so it simply matter of the input device if you can enter
>the name or not. And if you do not happen to have Japanese input
>support installed, there is no way, you can enter the Japanese name.

yes, this makes it harder for implementors, and 
easier for users. offering a GUI for management 
is also harder for implementors and easier for 
users. I think we have to accept the possibility 
that additional effort for implementors is 
sometimes appropriate, if it yields a better user 
interface.

>If we mandate that there must be way to insert ID_KEY_ID as binary
>octect string (either in hex or something similar, including NULs),
>then we can always enter those names to the system. It might not be
>easy, as it might require converting the name to the ISO10646 and then
>UTF-8 and then to hex, but it is possible.

yes, possible, but maybe not easy.

>Vendors are of course allowed to provide other means to input the
>item, like dialog box asking it as string.

allowed, yes, required, no. As a user I would 
like to try to make my life easier whenever 
possible.

>You again assume that vendors will only support exactly one way to
>enter the data in. Most of the implementations out there already have
>way to specify the shared-secret either in text or in hex, so the
>implementators do know how to do it... :-)

I can't comment on what most vendors do in the 
shared secret case for IPsec implementations. I 
just cited my bad experience in a different but 
equivalent context, and it was not good.

Steve

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 25 Mar 2004 11:44:19 -0800

> semantics of the data were as stated in IKEv2.
I do see your point about how if we restrict the ID_KEY_ID to account names
/login names as stated in IKEv2 will make the interactions with various
vendor products easier. But the other point that was made in this thread is
that ID_KEY_ID also has been used to select pre-shared key and it can
carry a opaque stream of bytes. The data for ID_KEY_ID itself may be
configured using some management interface or dynamically generated.
For the dynamically generated case, there is no issue  i suppose. But if
we use ID_KEY_ID for values entered through management interfaces
also, then the issue of "how different products would support this" comes up.
At least it looks like we need flexibility in one case (dynamic) and restriction
in another case (configuration through UI) to make configuration easier.
I can see how it can become a nightmare configuring product from Vendor X
using ASCII and configuring product from Vendor Y using hex for making
it communicate with each other. But at least there is a possiblity that you can get
this right by doing the right conversion. But if you restrict it to use only login names,
then the flexibility is lost. I know at least that 3GPP2 uses the ID_KEY_ID  that is
generated dynamically and communicated using RADIUS. There may be others
e.g PANA that will use ID_KEY_ID to carry session ids.

> IKE text back to the v1 version, that makes no mention of account IDs 
Will RFC 2401bis also reflect the same ?

> of account info such as login IDs.
Sounds good to me.

thanks
mohan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Mar 2004 12:44:52 -0500

At 11:56 AM +0200 3/26/04, Tero Kivinen wrote:
>All of my bad experiences are because someone thought to be user
>friendly and only created text input box where the password can be
>written. It is extremly hard (or impossible) to write binary key
>0x44f7ba0052dc29b4812d2e9b165b410d to that box, thus that laptop user
>who have only text input box will not be able to use system at all.
>Most of those who provided the hex-input also provided a way to type
>the key in as string.
>
>Thus, saying it is binary string, and you MUST offer way to put in any
>binary string (up to certain length) works better, as it will always
>offer interoperability (I agree it might not be that user friendly,
>but that is something that the vendor can fix if they feel like making
>it user friendly).

And my bad experience is that while I could create and remember a key 
in the form of a pass phrase character string, I had to write down 
the hex key I created and very carefully, manually enter it into each 
system, which was error prone (despite my care), frustrating, and a 
very poor use of my time.

I fear that you bring an implementer perspective to the problem, and 
I bring a user perspective, and it is unfortunate that the two don't 
overlap better :-)

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Mar 2004 15:36:29 +0200

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Mar 2004 15:17:36 -0500

>Will RFC 2401bis also reflect the same ?

Yes.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Mar 2004 11:56:09 +0200

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 27 Mar 2004 10:34:53 +0200

> very poor use of my time.

I have always configured those keys to my laptop, I do not enter them
after the first time ever. My laptop then have that kind of
information encrypted using the passphrase, and I only type in the
passphrase when I need any of those 10-40 character long random keys. 

> I bring a user perspective, and it is unfortunate that the two don't 

Anyways ID_KEY_ID is little bit different, I do not think people are
going to type it in, it will be configured in to their system
configuration once, and then used in the IKE. 
-- 
[email-masked]