Subject: draft minutes from IETF57 secure shell meeting.

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Aug 2003 16:03:11 -0400

Send comments/corrections/etc to me by next week..

					- Bill

Secure Shell WG Meeting - IETF 57 - 7/16/2003

Chair: Bill Sommerfeld

Summary of IETF57 Secure Shell WG meeting.

The actual meeting was short, mostly largely of document status
updates.  Attendance was very light.  There was brief discussion of
open issues with several of the documents.  One document is now in the
IESG's hands: draft-ietf-secsh-dns-04.txt (SSH key fingerprints in
DNS).  The core draft update to resolve IESG issues missed publication
deadline for this meeting, but editing is now done and the documents
should reappear shortly.  This will hopefully break the logjam and get
the rest of the documents moving.

There are few open issues at present -- mostly editorial nits.

Starting with this IETF, the AD has requested that I list the actions
expected before the next IETF meeting (November 9-14, 2003, in
Minneapolis).

Expected within next month:			  [responsible party]
	Creation of issue tracking database for the WG.	 [chair]

	core drafts reissued with revised sec-cons	 [moffat]

	draft-ietf-secsh-dh-group-exchange-04.txt	 [provos/friedl]
		reissued with nit fixed		         [provos/friedl]
		to AD for IETF-wide Last Call		 [chair]

	core drafts back to IESG review.		 [chair]
	
	Completion of WG last call period on
		draft-ietf-secsh-gsskeyex-06.txt	 [jhutz]
		draft-ietf-secsh-auth-kbdinteract-05.txt [cusack/forssen]

Expected before next IETF:

	Reissue of extensions drafts with WG chair's nits fixed, and
	run WG last call:

		draft-ietf-secsh-break-00.txt		 [galbraith/remaker]
		draft-ietf-secsh-filexfer-04.txt	 [galbraith]	
		draft-ietf-secsh-fingerprint-01.txt	 [friedl]
		draft-ietf-secsh-publickeyfile-03.txt	 [galbraith]

	Discussion and resolution of technical issues with extension drafts:

		draft-ietf-secsh-agent-01		 [lehtinen]

			Issue: moving keys to root agent vs. moving
			requests to keys.

		draft-ietf-secsh-newmodes-00.txt 	 [kohno]

			Issue: Tweak/prune algorithm list?

	Discussion of whether to accept individual submissions as WG items:

		draft-galb-secsh-publickey-subsystem-01.txt [mcclure]

Detailed minutes:

WG Chair Bill Sommerfeld opened the meeting with the traditional agenda
bashing/blue sheet dispersal.

Bill said that he sent a flurry of email out last night, saying that
he believes most of the documents are ready for the IESG.

General items:

	- WG Chair was busy since the last IETF.
	- Chair would like to use an issue tracking system (if anyone has
	  preferences, let him know) 
	[Subsequent to this, we adopted RT, at rt.psg.com]
	- Flurry of notes last night included various nits.

Recent active discussions

	- File Transfer Performance (mostly resolved)
	  - Pipelining the requests
	  - Use large channel windows

	- GSS Key Exchange Nits
	  - Comments from the document author? (none)

General nits for all drafts:

	- References split (normative/nonnormative)
	  - Claim is that this helps documents move faster once they leave
	    the IESG (this helps out RFC editor).

	- Security considerations section
	  - Looks REALLY lame if the security area forgets that
	  - IESG has gotten really picky lately.

	- IANA Considerations sections

	- ID Nits - see ID-Nits web page

	- IPR references if made need to follow 2026
	  - IETF dos not make judgements on IPR claims
	  - BAD: There is a patent/trademark
	  - GOOD: "There may be IPR claims"

Core Drafts:

	- Bounced from IESG for security considerations work

	- Revised sections drafted and last-called

	- Just missed deadline for this IETF (DSL failure delayed them)

	- All five sent out late Monday
	  (one bounced, will be resent)

	- One more nit found (X11 cookies)

	- Will be sent to IESG once remaining items are cleaned up.

draft-ietf-secsh-dns-04.txt

	- Survived IETF-wide Last Call

	- Stuck somewhere in IESG - unjammed by AD

Other extensions drafts revised to fix nits:

	Keyboard-interactive
	- Now has a security-considerations section
	- Started WGLC last night

	GSSAPI - Started WGLC

	DH Group Exchange
	- Lost somewhere in the wash before last IETF
	- Needed references split, done by authors

Still in need of revisions:

	Public key file format - missing security considerations

	SSH Fingerprint Format

	Agent Forwarding - Should be implementable, and the usual nits

	File Transfer - Usual nits, and vaguer IPR text

Issue tracking:

	Several systems out there being used successfully:

	- Bugzilla (Chair believes that is too complex)
	- RT (run by Randy Bush)
	- Roundup
	  - Seems to use termology that matches IETF process, might be
	    worth a closer look

	Strong options/preferences, please notify WG chair.

	Jeff Hutzelman: Noted that KRB-WG tried to use RT for issue
	tracking, and we fell flat on our face.  Needs strong direction
	from WG leadership

	Sam H: Note that if your process is already working, an issue tracker
	may slow you down.

	Paul Hoffman: In IPsec, one person controls the issue tracker,
	instead of document authors, and it works well.

	Bill notes that part of the motivation is to give him a list of
	things to bug document authors.

New modes/transport fixes:

	- draft-ietf-secsh-newmodes-00.txt

	- Submitted by Tadayoshi Kohno ([email-masked])

	- Usual nits, needs a respin

	- Opinions of working group: Should we go this way? (lots of
	  algorithms versus few).  WG members should send comments
	  to the list.

	Jeff Hutzelman notes that a lot of algorithms are recommended:
	do we really need all of them?

GSSAPI:

	Document author thinks it's done, so WGLC has been started.

	Significant keyex discussion (claimed problems with gss-keyex
	negotiation and keyex and in general).

	Jeff H: Admits that he's been lame and hasn't followed the
	discussion.

	Bill: Sounds like a task for Jeff for next time.

File Transfer:

	Significant discussion of performance problems; seems like that's
	been resolved, so this is getting close.

Agent forwarding:

	If you do agent forwarding to a remote host, it pushes the long-term
	public key to the remote system.  Draft is silent on this issue.
	Bill says at the very least the draft should talk about this
	issue.

"Please send draft":

	X509/PKIX support: Steve Hanna
	Line mode - Thor Simon
	Performance analysis - Bill Squier

With no further comments, Bill closed the meeting.

---

From: Love <[email-masked]>
Date: Fri, 22 Aug 2003 16:06:27 +0200

I've pointed out this to the authors privatly, so I'll repeat this
publicly. I consider gss userauth to be broken since it doesn't verify the
session id (using either mic or a channel bindings (like in CCM)).

Love

---

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 22 Aug 2003 12:45:24 -0400

> session id (using either mic or a channel bindings (like in CCM)).

I'd not previously realized this, having not read that section of the
gss spec, but that does appear to me to be true, and I do agree that
it is something that should be fixed.

(I'm sending this message primarily because my understanding is that
``me toos'' are useful in determining what the working group consensus
is.)

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 22 Aug 2003 14:41:38 -0700

I'm in favor of using channel bindings for this purpose.  

CCM could be one approach to do this. 
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

At first glance it seems a little complex, but I need to actaully read
the spec.  

Joe

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joel N. Weber II
> Sent: Friday, August 22, 2003 9:45 AM
> To: Love
> Cc: [email-masked]
> Subject: Re: gss userauth
> 
> 
> > publicly. I consider gss userauth to be broken since it 
> doesn't verify 
> > the session id (using either mic or a channel bindings 
> (like in CCM)).
> 
> I'd not previously realized this, having not read that 
> section of the gss spec, but that does appear to me to be 
> true, and I do agree that it is something that should be fixed.
> 
> (I'm sending this message primarily because my understanding 
> is that ``me toos'' are useful in determining what the 
> working group consensus
> is.)
> 
> 
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Aug 2003 19:22:18 -0400

> At first glance it seems a little complex, but I need to actaully read

CCM actually isn't what we want.  It's a way of taking an app that uses 
GSSAPI's integrity and/or encryption features, and a mechanism that 
provides them, and essentially ripping out the mechanism's authentication 
and encryption and replacing them with that provided by some lower-layer 
protocol such as IPsec, on the theory that hardware acceleration is more 
likely to be available there.  We don't need that functionality -- we don't 
ever use GSSAPI encryption features, and we currently send exactly one 
integrity-protected message (during key exchange).

What we need is a way to bind user authentication to our application 
protocol's existing cryptographic context, not to some lower-layer 
protocol.  We don't need a special GSS mechanism for that -- all we need to 
to require the client to send an integrity-protected copy (or checksum) of 
the exchange hash, just as we do in other user auth mechanisms, and as we 
do in the reverse direction during key exchange.

I can think of two ways of doing this:
(1) Use GSSAPI channel bindings.  Unfortunately, some mechanisms require 
bindings to take a particular format, as described in RFC2744 section 3.11. 
In our case, we would want to use address types of GSS_C_AF_NULLADDR, since 
we very much do _not_ want to bind this authentication to network protocol 
addresses (that would gain nothing, and make it not work through NAT's). 
We could then include the session ID as "application data".

(2) Add an additional step in which the client is required to send a MIC of 
the session ID before authentication can succeed.  This is essentially the 
same as what we do in key exchange, but in the reverse direction.

I find myself preferring option (2) for several reasons:
- By my reading, RFC2743 does not appear to actually require that GSSAPI 
mechanisms _do_ anything with channel bindings.  A mechanism could just 
choose to ignore them.
- RFC2743 _does_ allow mechanisms to require bindings to take a particular, 
mechanism-dependent form.  It does not specify what the behaviour might be 
if the provided bindings are not in a format acceptable to the mechanism.
- Some mechanism might be unable or unwilling to provide integrity 
protection for channel bindings, and there is no way for them to signal 
this to the application.  While it may be the case that a mechanism cannot 
support gss_get_mic, at least there is a flag to indicate that, and we can 
write appropriate requirements.
- Using a separate message means we can maintain some amount of backward 
compatibility for sites that have already deployed earlier versions of this 
draft.  Particularly, it allows for situations in which the client 
implements the new message, but the server does not.

-- Jeff

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 22 Aug 2003 17:02:50 -0700

Hi Jeff,

Okay, You reminded me of all the reasons why I don't like GSSAPI channel
bindings.  My only issue with MIC is that it might add an extra round
trip. I think that this is outweighed by the fact that MIC would
probably lead to more consistent implementations.  

In any case I agree that we do not want to bind addresses.

Joe

> [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
> Sent: Friday, August 22, 2003 4:22 PM
> To: [email-masked]
> Cc: 'Love'
> Subject: RE: gss userauth
> 
>

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 23 Aug 2003 00:09:46 -0400

It is desireable, I think, to avoid increasing the requirements that
gss userauth places on gssapi mechanisms.  I think having the same
requirements as key exchange is very much a good thing.

I also think that making it as much like pubkey userauth as possible
in terms of what data it signs would probably be a good thing,
although pubkey probably signs more random data fields than there is
any actual need to sign.  I think the crucial key is that the session
ID gets signed, and it is probably a good idea to include some other
random data so that session key signatures used for different purposes
sign different data.

---

From: Love <[email-masked]>
Date: Sat, 23 Aug 2003 11:55:38 +0200

"Joseph Salowey" <[email-masked]> writes:

Hi Josepha and Jeff,

> In any case I agree that we do not want to bind addresses.

I'm fine with that, using GSS_C_AF_NULLADDRs and stuff the session
identifier in the application_data fields, the later is what CCM proposes,
would work for all mechs that have working channel bindings would save you
From the extra round trip. But then, channel bindings are useless (for ssh
gssuserauth) because they are optional for the gss mechs.

If the MIC is set with the last gss exchange packet, you would have 0 or 1
extra packets. 0 in the case where the last exchange packets is from the
client and 1 when the last exchange packet is from the server. So I would
argue that its not a extra roundtrip, but rather none (with more data) or a
half.

I would very much like to see mutual auth in the gss userauth layer, but
sending MIC from client to server is ok with me.

Love

---

From: "Joel N. Weber II" <[email-masked]>
Date: Sat, 23 Aug 2003 07:55:26 -0400

> argue that its not a extra roundtrip, but rather none (with more data) or a

I think with the way GSSAPI userauth happens to be defined, you can
just piggyback the data on this packet that already gets sent anyway,
and you never add round trips vs what the protocol already does:

           byte      SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 23 Aug 2003 13:53:17 -0400 (EDT)

> gssuserauth) because they are optional for the gss mechs.

Using channel bindings would also destroy backward-compatibility, in both
directions.  A client which sends channel bindings would not be able to
establish a security context with a server that is not expecting to accept
them.

> argue that its not a extra roundtrip, but rather none (with more data) or a

In the gssapi userauth method we have defined, the last message is always
sent by the client.  Thus, we can define an alternate version of this
message (currently always SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which
contains the MIC.

> sending MIC from client to server is ok with me.

Why?  The userauth layer isn't about authenticating the server to the
client; we've already done that.  Performing mutual auth in the userauth
layer would restrict us to GSSAPI mechanisms that can _do_ mutual auth.
I don't see any gain that justifies that restriction.

-- Jeff

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 25 Aug 2003 09:00:54 -0600

> establish a security context with a server that is not expecting to accept

I'm a little concerned about compatability at these
point-- I've got a shipping version -- which perhaps
wasn't wise as we hadn't completed last call, but,
never-the-less, I've got one.

When we originally wrote the draft we talked about
something like this but elected not to do it so that
userauth wouldn't require integrity and mutual auth
as the kex method does.

I'm sure I'm being niave (or I just drove all night
and my brain isn't working correctly yet), but, assuming
the SSH layer is secure (and if you want to secure the
SSH layer using gss, you can use the kex method), what
attack does this prevent?

Also, I don't think Microsoft supports channel bindings--
so I would definitely prefer not to require these.

> message (currently always SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which

If this feature is required to prevent an attack, I
would definitely prefer this solution.

In fact, to prevent downgrade attacks based on
compatibility with old versions, we might want
to define "gssapi-2", which is identical to
"gssapi" in all ways, except that
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains
the MIC.

> I don't see any gain that justifies that restriction.

I definitely agree.  One of the major reasons for having
a userauth method is that it isn't as demanding on the
capabilities of the gss mech as key exchange is.

- Joseph

---

From: Markus Friedl <[email-masked]>
Date: Mon, 25 Aug 2003 17:45:32 +0200

> attack does this prevent?

i don't know GSS API, but for pubkey auth the session id is used
to 'bind' the signature to the connection.

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 25 Aug 2003 11:57:16 -0700

> From: Joseph Galbraith [mailto:[email-masked]] 
> Sent: Monday, August 25, 2003 8:01 AM
> To: Jeffrey Hutzelman; Love
> Cc: Joseph Salowey; [email-masked]
> > > would work for all mechs that have working channel bindings would 
> > > save
> you
> > > From the extra round trip. But then, channel bindings are useless 
> > > (for
> ssh
> > Using channel bindings would also destroy 
> backward-compatibility, in 
> > both directions.  A client which sends channel bindings 
> would not be 
> > able to establish a security context with a server that is not 
> > expecting to accept them.
> 

[Joe] If the GSSAPI exchange is not bound to the session then you do not
have assurance that the client actually was performing the GSSAPI
exchange to authenticate itself to the SSH server.  The client may
actually be trying to authenticate to some other service in some other
context and his authentication may be proxied by a third party.  Part of
the problem is that the target name suggested is "host@" which can be
used by multiple services on a host.  

> > > If the MIC is set with the last gss exchange packet, you 
> would have 
> > > 0 or
> 1
> > > extra packets. 0 in the case where the last exchange 
> packets is from 
> > > the client and 1 when the last exchange packet is from 
> the server. 
> > > So I
> would
> > > argue that its not a extra roundtrip, but rather none (with more 
> > > data)
> or a
> > > half.
> >
> > In the gssapi userauth method we have defined, the last message is 
> > always sent by the client.  Thus, we can define an 
> alternate version 
> > of this message (currently always 
> > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which contains the MIC.
> 
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains the MIC.
> 
> > > I would very much like to see mutual auth in the gss 
> userauth layer, 
> > > but sending MIC from client to server is ok with me.
> >
> > client; we've already done that.  Performing mutual auth in the 
> > userauth layer would restrict us to GSSAPI mechanisms that can _do_ 
> > mutual auth. I don't see any gain that justifies that restriction.
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Aug 2003 16:43:27 -0400

> userauth wouldn't require integrity and mutual auth

Right.  In a very early version of the userauth draft, before we merged 
userauth and keyex into one document, we had a requirement that the server 
send a MIC of the host key (or was it the session ID?  I forget) to the 
client.  The point of this was to "increase confidence" in the correctness 
of the host key.  We dropped it because there was relatively little 
percieved gain, and we wanted not to have to require integrity and mutual 
auth from the underlying GSSAPI mechanism.

What we're talking about now is similar, but different.  The current 
proposal is to require the _client_ to send the _server_ a MIC of the 
session ID.  This proves to the server that the client which has just 
authenticated to it is the same client that started the ssh connection, and 
not some intermediate attacker.  I believe this is a real problem and worth 
solving; I also believe there is a solution which is quite trivial and does 
not break backward compatibility.

> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains

I don't think it should actually be necessary to do this; it should be 
sufficient to use a new final message in place of the existing one.  A new 
client would always send the new message, and fall back to sending the old 
one if it gets a SSH_MSG_UNIMPLEMENTED.  This isn't really a "downgrade" as 
far as the client is concerned, since the only difference is that the "old" 
version causes the client to send _less_ data.  A new server can choose to 
accept the old message or not, depending on a local policy decision about a 
tradeoff between security and compatibility with old clients.  This 
approach gives us complete interoperability between old and new 
implementations, except in the case where a new server chooses not to 
support old clients for security reasons.

-- Jeff

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 26 Aug 2003 20:59:11 +0200

> session id (using either mic or a channel bindings (like in CCM)).

So I would like to propose adding the following text (marked with !) in 3.5
in draft-ietf-secsh-gsskeyex. I knowlingly break backward compability
because I think the problem is important enough to (possibly) break
backward compability.

I've had a long chat with Jeff Hutzelman, and the solution that he and Sam
Hartmans are talking about might be better then mine. I'm proposing this
for a simple alternative solution to the problem.

Love

3.4  GSSAPI session

[...]

!  The client MUST use the integ_avail in calls to
!  GSS_Init_sec_context() to request credential and verify the flag
!  is set then the negotiation is done.

[...]

3.5 Client acknowledgement

   It is possible for the server to successfully complete the GSSAPI
   method and the client to fail.  If the server simply assumed success
   on the part of the client and completed the authentication service,
   it is possible that the client would fail to complete the
   authentication method, but not be able to retry other methods
   because the server had already moved on.

   Therefore, the client MUST send the following message when it has
   successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE:

!          string    MIC

   This message MUST be sent if and only if GSS_Init_sec_context()
   returned GSS_S_COMPLETE.  If a token is returned then the
   SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.

!  The MIC is the result of the gss_get_mic over the following data, in the
!  following order:
!
!    string    session identifier
!    byte      SSH_MSG_USERAUTH_REQUEST
!    string    user name (in ISO-10646 UTF-8 encoding)
!    string    service name (in US-ASCII)
!    string    "gssapi" (US-ASCII method name)
!    uint32    n, the number of mechanism OIDs client supports
!    string[n] mechanism OIDs

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Aug 2003 15:22:00 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> So I would like to propose adding the following text (marked
    Love> with !) in 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly
    Love> break backward compability because I think the problem is
    Love> important enough to (possibly) break backward compability.

Not surprisingly, I'd prefer not to break backward compatibility.

My reason is simple.  I don't really see this as a new vulnerability
so much as an apparent decision on the part of the WG to change the
threat model.

When we originally wrote this draft, we invisioned the GSSAPI userauth
mechanism would be used with some mechanisms that did not support
mutual authentication or integrity protection.

The mechanism does as good of a job as it can for such cases.  In such
cases, GSSAPI tokens are like one-time passwords.  We know that if an
attacker manages to tunnel them or otherwise get ahold of the token
before the token reaches the server (and the server's replay cache),
then the token can be used by the attacker.

It's reasonable for us to now decide that we want to expand the threat
model and to forbid use of GSSAPI mechanisms that support integrity.
It's also reasonable to allow mechanisms that do not support
integrity, but to use the integrity protection when it is available.
I'm happy with either of these decisions.

But people have deployed code based on our previous approach.  If they
believe that there threat model is acceptable--if they believe that
one-time-password style mechanisms are acceptable to them--then we
should at least provide them an upgrade path.

I don't actually have an opinion on whether we should allow GSSAPI
mechanisms without integrity.  I do strongly agree that we should move
to an environment where integrity protection is better.

--Sam

---

From: Love <[email-masked]>
Date: Tue, 26 Aug 2003 22:39:29 +0200

> then the token can be used by the attacker.

It could do better if it did channel bindings with session identifier in
application data using GSS_C_AF_NULLADDRs.

Then gss mechs without integrity support but with (in gss spec optional)
channel binding support would not be vulnerable to tunneling.

But then again, this (also) would break backward compability.

Love

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Aug 2003 17:02:58 -0400

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> Sam Hartman <[email-masked]> writes:

    >> The mechanism does as good of a job as it can for such cases.
    >> In such cases, GSSAPI tokens are like one-time passwords.  We
    >> know that if an attacker manages to tunnel them or otherwise
    >> get ahold of the token before the token reaches the server (and
    >> the server's replay cache), then the token can be used by the
    >> attacker.

    Love> It could do better if it did channel bindings with session
    Love> identifier in application data using GSS_C_AF_NULLADDRs.

    Love> Then gss mechs without integrity support but with (in gss
    Love> spec optional) channel binding support would not be
    Love> vulnerable to tunneling.

It could do that.  I wonder if it would work.  I am sufficiently
uncomfortable with GSS channel bindings to refrain from recommending
their use until CCM becomes much more mature.

Right now, I think that depending on channel bindings would delay our
solution.  If we believe we want to break backward compatability, I'd
rather choose one of the other approaches.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 13:56:18 -0700

> integrity-protected message (during key exchange).

Yes and no.  Raw channel bindings would suffice for this purpose, so CCM
is not applicable, but you could have used CCM (if it'd been available
then and you'd really wanted to and you assumed channel bindings support
everywhere).

(CCM has other benefits besides leveraging IPsec HW acceleration, such
 as reducing the number of active crypto contexts needed on NFS file
 servers.  But that's another story.)

> We could then include the session ID as "application data".

Yes.  But you can't do this now w/o breaking compatibility and not all
GSS-API implementations, nor all mechanisms, for that matter, support
channel bindings.

> same as what we do in key exchange, but in the reverse direction.

This MIC can be sent as soon as the context is GSS_C_PROT_READY, on
whichever side it's PROT_READY first.  Though, it may be easiest to fit
it into the last message from the client.

> mechanisms _do_ anything with channel bindings.  A mechanism could just

Right.

> if the provided bindings are not in a format acceptable to the mechanism.

We've seen this as a flaw in RFC2743 and the RFC2744/RFC1964 description
has to be the standard.  SPKM, for example, says nothing about how
channel bindings are built, so CCM proposes that the rfc1964
construction be used with CCM.

> implements the new message, but the server does not.

Yep, and yep.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 Aug 2003 17:14:28 -0400

On Tuesday, August 26, 2003 13:56:18 -0700 Nicolas Williams 
<[email-masked]> wrote:

>> (2) Add an additional step in which the client is required to send a MIC
>> of the session ID before authentication can succeed.  This is
>> essentially the same as what we do in key exchange, but in the reverse
>> direction.
>

No; the direction actually matters.  A MIC sent from the server to the 
client does not serve to bind the session to the client's identity, and 
thus does not solve the problem we are trying to address.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 26 Aug 2003 15:16:16 -0600

Jeffrey Hutzelman wrote:

> authenticated to it is the same client that started the ssh connection, 
> and not some intermediate attacker.  I believe this is a real problem 
> and worth solving; I also believe there is a solution which is quite 
> trivial and does not break backward compatibility.

Ah.  I see the difference.

> sufficient to use a new final message in place of the existing one.  A 
> new client would always send the new message, and fall back to sending 
> the old one if it gets a SSH_MSG_UNIMPLEMENTED.  This isn't really a 
> "downgrade" as far as the client is concerned, since the only difference 
> is that the "old" version causes the client to send _less_ data.  A new 
> server can choose to accept the old message or not, depending on a local 
> policy decision about a tradeoff between security and compatibility with 
> old clients.  This approach gives us complete interoperability between 
> old and new implementations, except in the case where a new server 
> chooses not to support old clients for security reasons.

Hmmm...

I would still prefer to see a new auth method-- I think
it is cleaner.

SSH_MSG_UNIMPLEMENTED is clearly doable, but it is messy.
Because SSH_MSG_UNIMPLEMENTED only includes the packet
sequence number, telling exactly what was unimplemented
is difficult at best.  In retrospect, it would have been nice
to include the packet type that was unimplemented in
the UNIMPLEMENTED message.

As long as all UNIMPLEMENTED messages are sent at
mutually exclusive times, things aren't too bad, but...
what if we do the kex init extension that has
been kicked around.  It isn't technically impossible
for re-key to occur during user auth.

Now, to support both of these, I have to start keeping
a map of sequence-number to packet types sent so I
can map back and figure out which packet I sent was
unimplemented, so I know what to do about it.

Now, the scenerio I've painted (re-key during userauth)
is unlikely.  But every time we depend on
SSH_MSG_UNIMPLEMENTED, we increase the risk that we
will run into a case where it will be unclear to
the receiver of SSH_MSG_UNIMPLEMENTED which packet
they sent was unimplemented.

I think using SSH_MSG_UNIMPLEMENTED should be a last ditch
solution.

So I still prefer a new method name; we can define
this method, and then include a note that "gssapi"
is an obsolete method that differs only in it's
last packet.  I'm not sure about a name though.
"gssapi-2" or "gssapi-mic" come to mind, but there
might be better choices.

- Joseph

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 16:21:55 -0500

On Tue, Aug 26, 2003 at 02:20:35PM -0700, Nicolas Williams wrote:
> On Tue, Aug 26, 2003 at 05:14:28PM -0400, Jeffrey Hutzelman wrote:
> Sure it does.  If the client and server have established a GSS-API
> security context then any MIC made with it will be bound to that
> context and the initiator and/or acceptor names authenticated by the
> context's establishment.

Argh, sorry, you're right, the server needs to verify a MIC from the
client to have the client prove that the context is bound to the session
ID.

My bad.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 14:20:35 -0700

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 Aug 2003 18:27:03 -0400

On Tuesday, August 26, 2003 20:59:11 +0200 Love Hörnquist Åstrand 
<[email-masked]> wrote:

>> publicly. I consider gss userauth to be broken since it doesn't verify
>> the session id (using either mic or a channel bindings (like in CCM)).
>
> So I would like to propose adding the following text (marked with !) in
> 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly break backward compability

I actually have two potential proposals.  The first is a modification of 
what Love just described, which could allow it to be deployed in a 
backwards-compatible manner.  However, it depends on existing server 
implementations behaving properly when sent messages they don't understand 
(i.e. they send SSH_MSG_UNIMPLEMENTED and otherwise do nothing). 
Unfortunately, I think we've already demonstrated that we may not be able 
to depend on existing implementations to handle this correctly in all 
cases.  I do find it saddening that even when we go out of our way to 
provide a proper extensibility mechanism, it turns out to be pretty useless.

That said, I'm going to describe the solution that Love makes reference to 
above.  This idea was originally proposed by Sam Hartman; I've filled in a 
few details and made some minor changes.  Love thinks I should post some 
actual text as it might appear in the draft; I'll try to do that later, but 
I wanted to get the discussion rolling on this.  I'd like to come to some 
concensus on how to address this issue in the near future, so that it can 
be incorporated in the next version of the draft.

The basic idea is to define a new userauth method, which for the sake of 
this discussion we'll call "gssapi-mic" (I know Joseph Galbraith just used 
this name to describe something else, but I chose it first, so too bad). 
The new method would consist of a single request message, containing the 
usual method-independent fields and a MIC resulting from gss_getmic:

  byte    SSH_MSG_USERAUTH_REQUEST
  string  user name
  string  service
  string  "gssapi-mic"
  string context-id
  string  MIC

MIC is obtained by calling gss_getmic over the following:
  string  session identifier
  byte    SSH_MSG_USERAUTH_REQUEST
  string  user name
  string  service
  string  "gssapi-mic"
  string context-id

In these messages, context-id is a string identifying the particular GSSAPI 
context to be used with gss_getmic and gss_verifymic to generate and verify 
the MIC.  For now, the string "userauth" means that the context used is 
that established during the most recent exchange using the "gssapi" 
userauth method which terminated with SSH_MSG_USERAUTH_FAILURE with the 
partial success flag set.  I'll describe another possible value later.

A "new" server desiring to support GSS userauth with session id binding 
should first advertise "gssapi" as a valid userauth method, as before. 
Upon receiving the SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE message at the 
end of a successful exchange, the server should return 
SSH_MSG_USERAUTH_FAILURE with the partial success flag set, and include 
"gssapi-mic" in the set of acceptable methods.  A client supporting the new 
protocol can then complete the authentication process using the gssapi-mic 
method.

This method provides complete compatibility between new clients and old 
servers; with an old server, the gssapi method will simply return 
SSH_MSG_USERAUTH_SUCCESS.  It also allows new server implementations to 
support old clients, by behaving as an old server would (return complete 
success instead of partial success).  A new server can also decide which 
behaviour to use based on whether integrity is supported by the context; 
this means it is possible to require the MIC with those GSSAPI mechanisms 
which can support it, but still allow the use of mechanisms which do not.

There is also an additional advantage to this approach, which is that the 
same "gssapi-mic" userauth method can be used as an enhanced version of the 
"external-keyx" method which provides better binding of the user's identity 
to the session.  In this usage, the context-id would be the string 
"keyexchange", indicating that the GSSAPI context to be used is that 
resulting from the successful gss-* key exchange used to establish the 
session.

-- Jeff

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 26 Aug 2003 17:11:07 -0600

> this discussion we'll call "gssapi-mic" (I know Joseph Galbraith just 
> used this name to describe something else, but I chose it first, so too 

I surrender the name to you :-)

> bad). The new method would consist of a single request message, 
> containing the usual method-independent fields and a MIC resulting from 
> gss_getmic:
> 

I think this is a better proposal than mine.
I like this-- I think it maintains the backward
combatibility I need and fills the hole that
Love pointed out quite nicely.

- Joseph

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 26 Aug 2003 23:42:52 -0400

I dislike the partial authentication approach.  I believe it adds
significant complexity to an implementation.

If we don't want to rely on SSH_MSG_UNIMPLEMENTED, I'd be inclined to
suggest that we consider the following:

The spec starts with a set of a definition of messages
SSH_MSG_USERAUTH_REQUEST, SSH_MSG_USERAUTH_GSSAPI_RESPONSE,
SSH_MSG_USERAUTH_GSSAPI_TOKEN,
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, and
SSH_MSG_USERAUTH_GSSAPI_MIC, plus the error messages that are
currently defined.

Then it would describe three userauth methods in terms of those
messages:

The gssapi userauth method uses the same set of messages it does now,
for backwards compatibility and for methods that don't support
integrity that someone someday might want to use for authentication.

We add a new gssapi-mic userauth method, which is like gssapi but uses
SSH_MSG_USERAUTH_GSSAPI_MIC instead of
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE.

We define another new userauth method gssapi-keyex, which uses the
context from key exchange, and involves the client sending
SSH_MSG_USERAUTH_REQUEST followed by SSH_MSG_USERAUTH_GSSAPI_MIC.

This probably makes it easier for code to continue to use the sorts of
abstractions that code is likely to already be using (note that last I
checked, openssh didn't support partial userauth at all), and it
should be straightforward to share code between the userauth methods
as needed.

I'm willing to write up precise proposed text for this at some point
tomorrow (probably fairly late in the day, realistically) if that
would help.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 21:34:07 -0700

> so much as an apparent decision on the part of the WG to change the

Not only that, there is an alternative that does the right thing:
gsskeyex.

I think a warning about gss userauth not being bound to the session ID
and the resulting weakness, along with text explaining gss userauth's
utility with gss mechs that don't provide integrity protection ought to
suffice.  We have other userauths that also don't bind authentication to
the session ID (password, keyboard-interactive), so gss userauth's
failure to bind authentication to the session ID is acceptable,
particularly given that gsskeyex does (plus it has other benefits).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 21:39:35 -0700

> their use until CCM becomes much more mature.

Why are you uncomfortable with GSS channel bindings?  We know that they
work, from experience, where they are supported.  The lack of support
for channel bindings across the board is definitely one good reason to
be uncomfortable with using that facility to tackle this problem.

> rather choose one of the other approaches.

On the argument that support for channel bindings is not pervasive I
agree.  But I'm not sure that we have to solve this problem since, after
all, gss keyex does not have this problem and it is more useful that gss
userauth anyways (for mechs that provide integrity protection services).

We could just say that gss keyex is for mechs that provide mutual
authentication and integrity services and gss userauth is for mechs
that do not provide either or both of those.

Cheers,

Nico
--

---

From: Markus Friedl <[email-masked]>
Date: Wed, 27 Aug 2003 11:27:55 +0200

> the session ID (password, keyboard-interactive), so gss userauth's

so both are weak forms of authentication.

> failure to bind authentication to the session ID is acceptable,

so gss userauth should be weak as well?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 07:46:03 -0700

> so gss userauth should be weak as well?

It has to be weak in that way for mechanisms that don't provide
integrity protection.  For mechanisms that support integrity protection
there is gss keyex, which does not have this weakness.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 27 Aug 2003 12:42:51 -0400

> be uncomfortable with using that facility to tackle this problem.

So, is there any deployed software anywhere that uses GSS channel
bindings with krb5 gssapi?  Or with gsi gssapi?  If so, is there more
than one independent implementation with demonstrated
interoperability?

I strongly believe we should pick an approach that involves the use of
a MIC.

And I also don't see that channel bindings really buy us anything.
There are ways to do a MIC that will allow an old client to
interoperate with a new server, and vice versa.  Do channel bindings
ever allow the problems to be solved without upgrading both the client
and server?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 09:39:38 -0700

> be incorporated in the next version of the draft.

[description of new userauth and use of partial userauth failure removed]

I approve of and support this additional userauth w/ gss userauth
partial failure approach.

I just posted on the openssh-dev-unix list about a simple partial
userauth implementation.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 27 Aug 2003 12:47:00 -0400

So, what goals do we have in mind with changes to the spec?  I think
the requirements we have are basically:

1) stronger bindings

2) backwards compatibility

3) a preference toward ease of implementation

I think we can get 1 and 2 quite easily using either a mic or channel
bindings.  I think 3 favors a mic, because it's not at all clear that
channel bindings are particularily mature, and we don't want to have
to create a lot of infrastructure to be able to solve this problem if
there's a simpler fix.

Nico, were there other goals you had in mind?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 09:49:37 -0700

> than one independent implementation with demonstrated

MIT krb5's ftp/ftpd used to require the use of channel bindings using
network addresses as the bindings.  Of course, that created problems
with NAT, but that's another story and wouldn't apply to this case.

Did Heimdal ever support channel bindings?  I don't know.

There are also MIT-based implementations that interop with MIT.

SSPI doesn't.

> I strongly believe we should pick an approach that involves the use of

Actually, I agree, not because of issues with channel bindings but
because Jeff Hutzelman's proposal of using partial userauth with an
additional userauth that has the client send the MIC is better, from a
backwards compatibility point of view.

> ever allow the problems to be solved without upgrading both the client

I had already agreed that channel bindings wouldn't be the solution now
- I was asking Sam why he was uncomfortable with channel bindings as I
had the strong impression that he meant that generally, not specifically
in this context (the quote was "I am sufficiently uncomfortable with GSS
channel bindings to refrain from recommending their use until CCM
becomes much more mature").

Cheers,

Nico
--

---

From: Love <[email-masked]>
Date: Wed, 27 Aug 2003 18:54:53 +0200

> be uncomfortable with using that facility to tackle this problem.

How about adding a boolean flag to the gss exchange that the client sets to
tell the server it used bindings.

This way we don't need require channel bindings today. And servers can be
configured to accept gss exchange that doesn't support integrity but
channel binding.

There is the issue how the server tells the client it needs to use channel
bindings for that mech it just tried, but that I'm sure can be solved.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 09:52:31 -0700

> Nico, were there other goals you had in mind?

Security. :)

I don't think we can get all those goals with channel bindings _now_ -
we could have, much earlier, but not now that implementations have been
deployed.

As it is I think Jeff's proposal (partial userauth + a new useruath that
has the client send a GSS MIC) is the best approach that obtains all of
these goals.

Cheers,

Nico
--

---

From: Love <[email-masked]>
Date: Wed, 27 Aug 2003 18:58:43 +0200

> Did Heimdal ever support channel bindings?  I don't know.

We do.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 10:01:43 -0700

> tell the server it used bindings.

If we were starting from scratch we could just require the use of
channel bindings and be done.  (One can always build a pseudo-mech that
supports channel bindings from one that does not but which does support
integrity protection).

As it is we can't introduce a channel bindings requirement, though we
could introduce CCM to negotiate the use channel bindings.  But even so
Jeff's latest proposal sounds much easier to implement (to me) and blah
blah blah (see my other posts today).

> bindings for that mech it just tried, but that I'm sure can be solved.

See CCM.  CCM is a proposed pseudo-mechanism that enables negotiation of
the use of channel bindings (it itself does not do the negotiation, but
it allows protocols that negotiate GSS-API mechanisms to negotiate the
use of channel bindings).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Aug 2003 13:16:29 -0400

Love> Nicolas Williams <[email-masked]> writes:

    >>> It could do that.  I wonder if it would work.  I am
    >>> sufficiently uncomfortable with GSS channel bindings to
    >>> refrain from recommending their use until CCM becomes much
    >>> more mature.
    >>  Why are you uncomfortable with GSS channel bindings?  We know
    >> that they work, from experience, where they are supported.  The
    >> lack of support for channel bindings across the board is
    >> definitely one good reason to be uncomfortable with using that
    >> facility to tackle this problem.

    Love> How about adding a boolean flag to the gss exchange that the
    Love> client sets to tell the server it used bindings.

    Love> This way we don't need require channel bindings today. And
    Love> servers can be configured to accept gss exchange that
    Love> doesn't support integrity but channel binding.

We can do anything we can get with channel bindings with a MIC.  Why
are we going down the channel bindings rathole?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 Aug 2003 10:20:31 -0700

> significant complexity to an implementation.

I disagree.

First off, partial userauth is generally supported on the client side.

Second, if you look at OpenSSH you'll see that it makes the list of
userauth methods to offer to the client by pulling into the list all
enabled userauth methods.  You can see that manipulating the list of
methods that will be produced on partial failure is easy: just
manipulate the per-userauth method enabled/disabled flag.  Partial
failuer indication can be done by setting a flag on the userauth
structure or by having a third value that can be returned by a method
(failure, success, partial failure/success).  (You may want to have to
enabled/disabled flags: one to represent the configuration setting, the
other to represent whether a method can be included in the list of
methods that can continue after partial failure.)

I think that some uses of partial userauth failure are easy to implement
on the server side, others are not.  This particular use of partial
failure (Jeff's proposal) is easy to implement.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 28 Aug 2003 23:26:42 -0400

So, having actually implemented the partial userauth approach so I
could decide how painful it was, I've concluded that I don't really
object to it.

I'm not sure exactly where that leaves us on trying to reach
consensus.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 Aug 2003 00:00:44 -0400 (EDT)

> I'm not sure exactly where that leaves us on trying to reach

Since I am not the chair, my judgement doesn't really count.  However, I
think it makes us pretty close.  I believe you were the only person
advocating a different approach to addressing this without breaking
backward compatibility.

Given that, I will work up some specific text describing this approach,
send it to the list, and prepare the next version of the draft for
submission over the weekend.

-- Jeff