headers
Chris Lonvick | 6 Jul 2004 21:42
Picon
Favicon

[psg.com #440] IANA - Architecture - Registries

Hi Folks,

Issue 440 deals with the IANA Considerations Section in [ARCH].  An IANA
reviewer asked if they were existing, new, or a combination. I made a
quick change from -15 to -16 stating that the "IANA Considerations"
section in [ARCH] is there only for reference and that the _real_ IANA
assignments are to be found in [NUMBERS].  Does anyone object to this?
The alternative is to remove any information from this section in [ARCH]
and simply state that all information is in [NUMBERS].  This may not be a
bad alternative as most of the information in the IANA Considerations
section of [ARCH] is already discussed elsewhere in [ARCH].  Can I get
some consensus here:

A. (default)  Keep the information in [ARCH] along with the statement in
   [ARCH] saying that the information is reference material only and that
   the real info is in [NUMBERS].

B. Remove the information in [ARCH] and only point to [NUMBERS].

Thanks,
Chris
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 7 Jul 2004 17:41
Picon
Favicon

[psg.com #441] IESG - Architecture - atsign

Hi Folks,

Let's revist the discussion of the " <at> ".  The IESG notes were relevent to
the "IANA Considerations" Section in [ARCH].  However, Ticket 440 (my note
from yesterday) is a request from an IANA reviewer to plainly state what
parts of [ARCH] are to be used to form the initial IANA Registry.  I've
taken care of that by adding a note that the information in the "IANA
Considerations" section of [ARCH] is there only for reference and that the
_real_ IANA information is in [NUMBERS].  However, nothing about the use
of " <at> " is actually mentioned in [NUMBERS].  I'll get that in there but I
need some clarification.

The discussion in [ARCH] is about algorithm names.  In [NUMBERS] many of
the sections prevent the use of the " <at> " and "," symbols with no further
explanation.  Are the locally defined extensions applicable to:
 - Service Names
   - Authentication Methods
   - Connection Protocol Channel Names
   - Connection Protocol Global Request Names
   - Connection Protocol Channel Request Names
 - Key Exchange Method Names
 - Assigned Algorithm Names
   - Encryption Algorithm Names
   - MAC Algorithm Names
   - Public Key Algorithm Names
   - Compression Algorithm Names

If _ALL_ of these Names are locally extensible, then I can state quickly
state that.  Essentially, I'll add a section in [NUMBERS] that will state
that the IANA will not accept anything with " <at> ", but that the use of " <at> "
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joseph Galbraith | 7 Jul 2004 18:21
Favicon

Re: [psg.com #441] IESG - Architecture - atsign

I believe all of these are locally extensible.

Thanks,

- Joseph

Chris Lonvick wrote:

> Hi Folks,
> 
> Let's revist the discussion of the " <at> ".  The IESG notes were relevent to
> the "IANA Considerations" Section in [ARCH].  However, Ticket 440 (my note
> from yesterday) is a request from an IANA reviewer to plainly state what
> parts of [ARCH] are to be used to form the initial IANA Registry.  I've
> taken care of that by adding a note that the information in the "IANA
> Considerations" section of [ARCH] is there only for reference and that the
> _real_ IANA information is in [NUMBERS].  However, nothing about the use
> of " <at> " is actually mentioned in [NUMBERS].  I'll get that in there but I
> need some clarification.
> 
> The discussion in [ARCH] is about algorithm names.  In [NUMBERS] many of
> the sections prevent the use of the " <at> " and "," symbols with no further
> explanation.  Are the locally defined extensions applicable to:
>  - Service Names
>    - Authentication Methods
>    - Connection Protocol Channel Names
>    - Connection Protocol Global Request Names
>    - Connection Protocol Channel Request Names
>  - Key Exchange Method Names
>  - Assigned Algorithm Names
(Continue reading)

Permalink | Reply | 0 comments |
headers
der Mouse | 7 Jul 2004 18:30
Picon

Re: [psg.com #441] IESG - Architecture - atsign

> Are the locally defined extensions applicable to:
>  - Service Names
>    - Authentication Methods
>    - Connection Protocol Channel Names
>    - Connection Protocol Global Request Names
>    - Connection Protocol Channel Request Names
>  - Key Exchange Method Names
>  - Assigned Algorithm Names
>    - Encryption Algorithm Names
>    - MAC Algorithm Names
>    - Public Key Algorithm Names
>    - Compression Algorithm Names

> If _ALL_ of these Names are locally extensible,

I think they are, and if they're not, whatever necessary should be
changed so that they are.

Certainly when writing my code I've been assuming they are, and in some
cases it's difficult to see any good stubstitute if they're not.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Simon Tatham | 7 Jul 2004 18:23
Picon
Favicon

Re: [psg.com #441] IESG - Architecture - atsign

Chris Lonvick  <clonvick <at> cisco.com> wrote:
> If _ALL_ of these Names are locally extensible, then I can state quickly
> state that.

I believe that is (or should be) correct. The only purpose in using
string identifiers _at all_, with their extra space cost, is so that
they can be conveniently extensible in a way that pure 32-bit
integers are not. Therefore, anywhere the protocol defines a string
identifier, it should be extensible using the  <at>  mechanism.

Cheers,
Simon
--

-- 
Simon Tatham         "Every person has a thinking part that wonders what
<anakin <at> pobox.com>    the part that isn't thinking isn't thinking about."
Permalink | Reply | 0 comments |
headers
Niels Möller | 11 Jul 2004 21:14
Picon
Picon
Picon
Favicon

Re: [psg.com #441] IESG - Architecture - atsign

Chris Lonvick <clonvick <at> cisco.com> writes:

> If _ALL_ of these Names are locally extensible, then I can state quickly
> state that.

My understanding of the specs have always been that *all* the names
are locally extendable.

/Niels
Permalink | Reply | 0 comments |
headers
Chris Lonvick | 20 Jul 2004 20:29
Picon
Favicon

Message Numbers and Disconnect Codes

Hi Folks,

I'm working on adding the " <at> "-extension rules into [NUMBERS] and have some
questions.

The "Message Numbers" section allocates the ranges of numbers to specific
payload types - e.g.,
  1 - 19 for Transport layer generic
 20 - 29 for Algorithm negotiation
etc.
It then goes on to RESERVE the values [128..191], and then allocates
[192..255] for "Local Extensions".

However, the subsequent subsection on "Disconnect Codes" just has a
sequential list of codes with no instructions for range allocation.

My questions:

- How are the Local Extension Message Numbers going to be used?
If implementor A defines 200 as SSH_MSG_just_use_xor and implementor B
defines 200 as SSH_MSG_Luke__use_the_Force, then there could be some
problems if they meet each other in the wild.  There doesn't appear to be
any way to say 200 <at> careless.org or 200 <at> deathstar.gov as is defined with
the non-numbered Local Extensions.

- If we resolve that one, should we declare a range of Disconnect Codes
for Local Extensions?

Is anyone using the Local Extension Message Numbers and can they state how
they are trying to avoid interoperability problems?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Internet-Drafts | 20 Jul 2004 22:23
Picon
Favicon

I-D ACTION:draft-ietf-secsh-gsskeyex-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: GSSAPI Authentication and Key Exchange for the Secure Shell Protocol
	Author(s)	: J. Hutzelman, et al.
	Filename	: draft-ietf-secsh-gsskeyex-08.txt
	Pages		: 34
	Date		: 2004-7-20
	
The Secure Shell protocol (SSH) is a protocol for secure remote
   login and other secure network services over an insecure network.

   The Generic Security Service Application Program Interface (GSS-API)
   [GSSAPI] provides security services to callers in a
   mechanism-independent fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-gsskeyex-08.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Nevins | 21 Jul 2004 00:50
Picon

Re: Data transfer during key re-exchange

Joseph Galbraith writes:
> Jacob Nevins wrote:
> > What happens to "application data" (connection protocol etc) during a
> > key re-exchange is still not specified by the current transport draft
> > (transport-18).
    [snip my suggestion]
> > If anyone has objections, this issue should at least go in the issue
> > tracker, so it doesn't get lost again.
> 
> Every time this discussion has come up before I've looked for
> the language that I knew was there in section 7.1, and then
> found it in section 7.3 (which really is quite clear, if misplaced)
  [snip]
> And in section 9,
  [snip]
> I've never quite understood the confusion on this issue... however,
> I don't object to the new text.  I do object to it's proposed
> location though... I think it should go in Section 7.1 and section
> 7.3 could be condensed a little bit to remove redunancy.

Fair enough.

> If a re-enforcing sentance is needed in section 9 (processed identically
> including valid packet restrictions) I wouldn't mind that.
> 
> I would strike the final paragraph of section 9-- it is wrong (key
> exchanges _does_ affect the protocols because we stop sending their
> data for the duration) and only introduces confusion about an issue that
> is pretty well specified otherwise.  I guess we could reword it as our
> re-enforcing sentance:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeffrey Hutzelman | 21 Jul 2004 03:38
Picon
Favicon

Re: Data transfer during key re-exchange


On Tuesday, July 20, 2004 23:50:43 +0100 Jacob Nevins 
<jacobn+secsh <at> chiark.greenend.org.uk> wrote:

> At the end of Section 7.1, add the following two paragraphs:
>
>    Once a party has sent a KEXINIT message for key exchange or
>    re-exchange, it MUST NOT send any messages other than key exchange
>    method specific messages (message numbers 30 to 49); NEWKEYS; and
>    DISCONNECT, IGNORE, and DEBUG; until it has sent a NEWKEYS message
>    (Section 7.3).  Implementations MUST NOT accept messages other than
>    these between receiving KEXINIT and NEWKEYS messages.

Uh, what's wrong with SSH_MSG_UNINPLEMENTED?
And what's wrong with other (not yet defined) messages in the 20-29 range?
Without these, it will become difficult to extend algorithm negotiation, 
which I know we've discussed in the past.

For that matter, I'm not convinced that the not-yet-defined messages in the 
1-19 range should be excluded either.  All of the defined messages in this 
range have meaning at the lowest layer, independent of key exchange state. 
Why do we think any future messages in this range won't have the same 
property?

I'd say permit any messages in the 1-49 range, with the possible exception 
of SSH_MSG_KEXINIT itself.  Note that this must be handled carefully - once 
you send a KEXINIT, you're not allowed to _send_ another one, but you 
certainly are allowed to _receive_ one if you haven't seen it yet.  The 
text you propose seems clear enough to me in this regard; an implementation 
that gets this wrong won't be able to rekey at all!
(Continue reading)

Permalink | Reply | 6 comments |

Gmane