headers
The IESG | 7 Nov 2002 21:11
Picon
Favicon

Note Well Statement


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 5 Nov 2002 19:25
Picon

SSHv2 GSS spec issue wrt gss error tokens

GSS_Accept_sec_context() can produce tokens when its major status code
is neither GSS_S_COMPLETE nor GSS_S_CONTINUE_NEEDED. RFC2743 doesn't
state this anywhere but by not prohibiting this it implies the
behaviour.

The Kerberos GSS mechanism (RFC1964) defines error tokens; it does not
state that gss_accept_sec_context() can produce these but strongly
implies it. RFC1964 also does not specify numeric forms of minor codes.

The MIT implementation of GSS-API and the Kerberos GSS mechanism *does*
produce error tokens in some circumstances.

The gsskeyex draft does not specify what to do with error tokens, though
it does provide an optional SSH_MSG_KEXGSS_ERROR message for transmitting
GSS error information to the client. The result of this and the fact
that RFC2743 does not specify major status codes for certain conditions
(leaving one to use GSS_S_FAILURE) is that there is no interoperable way
of communicating to the client certain GSS-API error conditions
occurring on the server side.

It turns out that sending the acceptor's major and minor status codes is
not an appropriate alternative to sending the actual error token to the
initiator. For one, RFC1964 does not define numeric forms of its minor
status codes (and MIT's implementations liberally uses codes not defined
in RFC1964 and not called KG_...). Second, in some cases the
major/minor codes produced by gss_accept_sec_context() may be different
from those produced by gss_init_sec_context() upon receipt of an error
token. GSS status codes, major and minor, are API-level concepts and
should really not be used on the wire - that's what the gss error tokens
are for, though, admittedly, if gss_accept_sec_context() returns an
(Continue reading)

Permalink | Reply | 12 comments |
headers
Darren J Moffat | 7 Nov 2002 16:17
Picon

draft-ietf-secsh-dns-01.txt Fingerprint digest alg

3.1.2 Fingerprint type specification

The only digest algorithm listed is SHA1. I think this is inconsistant with
draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as
the fingerprint digest algorithm.

While we are on the subject is there an update to
draft-ietf-secsh-fingerprint-01.txt expected since it has now been removed
from the IETF site.

--

-- 
Darren J Moffat
Permalink | Reply | 6 comments |
headers
Jakob Schlyter | 7 Nov 2002 16:25
Picon

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, 7 Nov 2002, Darren J Moffat wrote:

> The only digest algorithm listed is SHA1. I think this is inconsistant with
> draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as
> the fingerprint digest algorithm.

yes, that is intentional - I can not see any reason for using md5.

	jakob

--

-- 
Jakob Schlyter <jakob <at> crt.se>                Network Analyst
Phone:  +46 31 701 42 13, +46 70 595 07 94   Carlstedt Research & Technology
Permalink | Reply | 4 comments |
headers
jon | 7 Nov 2002 16:37
Favicon
Gravatar

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, 7 Nov 2002, Jakob Schlyter wrote:

> On Thu, 7 Nov 2002, Darren J Moffat wrote:
> 
> > The only digest algorithm listed is SHA1. I think this is inconsistant with
> > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as
> > the fingerprint digest algorithm.
> 
> yes, that is intentional - I can not see any reason for using md5.

Wouldn't backwards compatibility be better served by requiring SHA1 and
additionally recommending MD5 be provided?  Better to allow users to check 
key fingerprints using a slightly less secure algorithm than prevent them 
from checking key fingerprints against servers who aren't yet up to date 
with the latest and greatest, no?

--

-- 
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com
Permalink | Reply | 1 comment |
headers
Jakob Schlyter | 7 Nov 2002 16:43
Picon

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, 7 Nov 2002 jon <at> siliconcircus.com wrote:

> Wouldn't backwards compatibility be better served by requiring SHA1 and
> additionally recommending MD5 be provided?

there is nothing to be backwards compatible with since sshfp isn't yet
deployed.

users will not verify the fingerprints distributed with sshfp themselves,
their software will. why? since without dnssec validation, sshfp is
practically useless and verifying the dnssec signature of the sshfp
manually isn't doable.

	jakob

--

-- 
Jakob Schlyter <jakob <at> crt.se>                Network Analyst
Phone:  +46 31 701 42 13, +46 70 595 07 94   Carlstedt Research & Technology
Permalink | Reply | 0 comments |
headers
The IESG | 7 Nov 2002 21:11
Picon
Favicon

Note Well Statement


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus Friedl | 7 Nov 2002 22:27
Picon
Favicon

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, Nov 07, 2002 at 04:25:57PM +0100, Jakob Schlyter wrote:
> On Thu, 7 Nov 2002, Darren J Moffat wrote:
> 
> > The only digest algorithm listed is SHA1. I think this is inconsistant with
> > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as
> > the fingerprint digest algorithm.
> 
> yes, that is intentional - I can not see any reason for using md5.

well we've been using md5 in openssh forever. it's because ossh
only had md5 support and not sha1.
Permalink | Reply | 1 comment |
headers
Markus Friedl | 7 Nov 2002 22:27
Picon
Favicon

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, Nov 07, 2002 at 07:17:10AM -0800, Darren J Moffat wrote:
> While we are on the subject is there an update to
> draft-ietf-secsh-fingerprint-01.txt expected since it has now been removed
> from the IETF site.

i can update the drafts, but i think it's too late for the next ietf meeting.
Permalink | Reply | 0 comments |
headers
Jakob Schlyter | 7 Nov 2002 22:30
Picon

Re: draft-ietf-secsh-dns-01.txt Fingerprint digest alg

On Thu, 7 Nov 2002, Markus Friedl wrote:

> On Thu, Nov 07, 2002 at 04:25:57PM +0100, Jakob Schlyter wrote:
> > On Thu, 7 Nov 2002, Darren J Moffat wrote:
> >
> > > The only digest algorithm listed is SHA1. I think this is inconsistant with
> > > draft-ietf-secsh-fingerprint-01.txt (expired) which specified MD5 as
> > > the fingerprint digest algorithm.
> >
> > yes, that is intentional - I can not see any reason for using md5.
>
> well we've been using md5 in openssh forever. it's because ossh
> only had md5 support and not sha1.

let me clarify this; I can not see any reason for using md5 in sshfp. I
can of course change my mind if the wg strongly believes that md5 should
be an option.

	jakob
Permalink | Reply | 0 comments |

Gmane