Re: Two more thoughts about credentials download protocols

Hi Radia,

> The second thought is about the issue someone brought up about how if
> you get out of sync with typing name and password, you could wind up
> sending your password over the wire in the clear. Charlie suggested
> a low-tech fix to that, which is that the password be required to
> contain a character which is illegal in a name. For instance, if
> "=" isn't legal in a name, and the user's
> password is "mypassword", the user could be required to type ==mypassword.
> And this might make a good user interface for putting in a hint. If
> the hint is, say, "J", then the user could either type
> =J=mypassword (which includes the hint), or ==mypassword (no hint)

First, I do kind of like the idea, however, I'm not sure that 
its easy to enforce, given I18N. Also if == is always prepended
then s/w will likely be developed that automatically enters 
that, which defeats the purpose. Finally its not that user friendly
to reqiure additional crud to be typed (even if its just a few 
characters).

I'd be interested in what others think about the requirement and
especially other ideas for (possibly partly) solving the problem.

Stephen.

--

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716

final minutes...

Hi & happy new year all,

No corrections having been received these are now the final
minutes for the San Diego meeting.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell <at> baltimore.ie
Ireland                             http://www.baltimore.com

SACRED WG, Thursday, 14 December 2000, 147 attendees.
Minutes collected by John Linn (RSA Laboratories).

INTRODUCTION

Stephen Farrell (Baltimore) opened the meeting, which was the group's first
meeting as a WG. SACRED WG contact information is available on the IETF web
page. Co-chair Magnus Nystrom (RSA Security) was unavailable for the meeting
because of a schedule conflict. Stephen outlined the following WG goals
intended between now and the next meeting: get the requirements document
suitable for WG Last-Call, and issue a next-to-last draft for the framework
document. Before/during/after next meeting, intended work items include

Re: Two more thoughts about credentials download protocols

> I'd be interested in what others think about the requirement and
> especially other ideas for (possibly partly) solving the problem.

My thoughts on this are that this is a user interface design problem and really
isn't
anything to do with the protocol.  If an application on the client side sends
the users
password across in the "username" part of the protcol then it is because the UI
of
that client was unable to present information in a sufficiently clear maner to
the user
to get the correct data.

Thats not to say it isn't an interesting problem, I just don't think it is one
that can
be solved at a protocol layer.

--
Darren J Moffat

Re: Two more thoughts about credentials download protocols

Perhaps I misunderstand the problem, but...  While I agree that this is
mostly a user interface issue, not a protocol issue, shouldn't the
username transmission be encrypted anyway?  It's my understanding that the
protocol should be authentication-type agnostic, and therefor whatever is
being sent should be encrypted as a whole, irrespective of if it's a
username, password, private key, or whatever.

  -Mike Bertsch

On Wed, 3 Jan 2001, Darren Moffat wrote:

> 
> 
> > I'd be interested in what others think about the requirement and
> > especially other ideas for (possibly partly) solving the problem.
> 
> My thoughts on this are that this is a user interface design problem and really
> isn't
> anything to do with the protocol.  If an application on the client side sends
> the users
> password across in the "username" part of the protcol then it is because the UI
> of
> that client was unable to present information in a sufficiently clear maner to
> the user
> to get the correct data.
> 
> Thats not to say it isn't an interesting problem, I just don't think it is one
> that can
> be solved at a protocol layer.
> 

RE: Two more thoughts about credentials download protocols

Further SACRED requirements comments

> I'd like to offer a few further comments about the SACRED requirements
> document, over and beyond those raised in prior list discussion and noted
> in the San Diego discussion minutes.  
> 
> Regarding treatment of the serverless case, it seems (a) that it's
> suitably motivated within the requirements document but (b) that there's
> not as much current momentum or constituency to carry it forward into
> lower-level documents.  If this situation persists, I suggest keeping the
> requirements-level discussion as is but narrowing the framework scope to
> "Securely Available Credentials - Framework with Credential Servers" or
> some such.  This would allow the serverless case to be pursued in a
> parallel framework document at a later date. 
> 
> In the requirements document, #F4 might usefully be restated "The details
> of the actual credential type or format MUST be opaque to the protocol,
> though not to processing within the protocol's peers. The protocol MUST
> NOT depend on the internal structure of any credential type or format."
> 
> If #G3 and #G4 (authentication and integrity protection for transferred
> credential data) are necessarily to be accomplished by the protocol,
> rather than within the credential objects themselves, suggest rewording to
> "The protocol <SHOULD|MUST> provide ...", consistent with subsequent
> requirements.  More broadly, just what does it mean to authenticate a
> credential, vs. authenticating a protocol peer?  In the case of a
> download, e.g., the originator of the credential may well have signed the
> credential object at some point in the past, enabling its authenticity to
> be verified, but won't generally be its source from the perspective of the
> transfer protocol.  Does the original object signing satisfy the intended
> requirement, or is this intended to concern connection-level
> authentication of the credential provider (e.g., via TLS)?
> 
> Re #G7, it seems somewhat strange to specify support for a particular
> credential format (an opaque object transported by the protocol) under the
> heading of a protocol conformance requirement; by analogy, it would be as
> if conformance to the TCP specification required support for HTTP (or for
> any other specific protocol which layers over TCP).  This may be an
> interoperability requirement, but it seems outside the scope of protocol
> conformance. 
> 
> Requirements #S6 and #S7 mesh a bit oddly to me.  I can see value in
> authenticating the server to the client for download, primarily as an aid
> to determining that the most current version of a credential is being
> obtained.  (I'd expect that a wholly invalid credential would probably be
> detected based on integrity facilities within the credential format.)  I'm
> not sure that this is necessarily a MUST for all cases, but don't think
> that its value depends on whether or not the server authentication can be
> verified before the credential crosses the wire.  If, e.g., a
> correctly-formed credential carried data which could be used as one of the
> inputs applied to cross-check the server's authenticity after the fact,
> this could be OK (as long as the client didn't overwrite any existing
> credentials before these steps were performed).  Would it be reasonable to
> place server authentication upon download as a general SHOULD, independent
> of whether or not that authentication occurs prior to the download
> operation?
> 
> --jl
> 
> 

fyi: US6154543: Public key cryptosystem with roaming user capability

I haven't examined this..

  http://www.delphion.com/details?pn=US06154543__

..in detail (it has 59 claims; plus IANAL), but it seems it ought to be of 
interest to this group, specifically w.r.t. the "Client/Server Credential 
Exchange" in draft-ietf-sacred-framework-00.txt (aka "credential server" 
approach in draft-ietf-sacred-reqs-00.txt).

In glancing at US06154543, it seems it might be written generally and broadly 
enough to apply to at least some aspects of sacred's work, but it also might 
be too specific in particulars such that it can be sidestepped.

Also, perhaps it is moot if there is indeed relevant prior art as suggested 
below.

In any case, someone(s) with more expertise will have to take a look. 

JeffH

------- Forwarded Message

Date: Mon, 08 Jan 2001 14:04:25 -0500
From: Rich Salz <rsalz <at> caveosystems.com>
To: cryptography <at> c2.net
Subject: Hush Communications gets silly patent

"DUBLIN, Ireland--(BUSINESS WIRE)--Jan. 8, 2001-- Hush Communications
(www.hush.com), a leading global provider of managed security solutions
and encryption key serving technology, today announced it has been
granted a patent for its revolutionary key pair management technology
that enables personal computer users to send and receive fully encrypted
electronic communications. Hush Communications, the category leader in
key pair management technology, now has the exclusive intellectual
ownership of its core technology, the Hush Encryption Engine(TM). " 
Full PR in http://biz.yahoo.com/bw/010108/hush_commu.html

US Patent 6154543.  It seems to be nothing more than store the private
key on a server,
give it out when the user presents the hash of their initial passphrase.

Similar technology was part of DCE in 1996, cf
http://www.opengroup.org/rfc/mirror-rfc/rfc94.1.txt

Sigh...
	/r$

------- End of Forwarded Message

RE: Further SACRED requirements comments

John,

	Thanks for your as-always-well-thought-out comments.  My responses 
in-line, prefaced by my initials, "AWA"..

-----Original Message-----
From:	Linn, John [SMTP:jlinn <at> rsasecurity.com]
Sent:	Monday, January 08, 2001 12:49 PM
To:	'ietf-sacred <at> imc.org'
Subject:	Further SACRED requirements comments

> I'd like to offer a few further comments about the SACRED requirements
> document, over and beyond those raised in prior list discussion and noted
> in the San Diego discussion minutes.
>
> Regarding treatment of the serverless case, it seems (a) that it's
> suitably motivated within the requirements document but (b) that there's
> not as much current momentum or constituency to carry it forward into
> lower-level documents.  If this situation persists, I suggest keeping the
> requirements-level discussion as is but narrowing the framework scope to
> "Securely Available Credentials - Framework with Credential Servers" or
> some such.  This would allow the serverless case to be pursued in a
> parallel framework document at a later date.

AWA:  I think that that's a reasonable approach.  If I get time, I'm going 
to start pushing harder on the serverless case, since that's the one of 
most direct importance to me, but these days "if I get time" equates 
roughly to "if the Sahara Desert or other very warm place freezes over ". 


>
> In the requirements document, #F4 might usefully be restated "The details
> of the actual credential type or format MUST be opaque to the protocol,
> though not to processing within the protocol's peers. The protocol MUST
> NOT depend on the internal structure of any credential type or format."
>

AWA:  Okay, I'm not exactly sure what you mean by the new clause "...though 
not to processing within the protocol's peers..."  Is your intent to convey 
that the entities that execute the SCACRE protocol in question might also 
be expected to process the credential at some point, or is there some other 
point that I'm missing?

> If #G3 and #G4 (authentication and integrity protection for transferred
> credential data) are necessarily to be accomplished by the protocol,
> rather than within the credential objects themselves, suggest rewording 
to
> "The protocol <SHOULD|MUST> provide ...", consistent with subsequent
> requirements.  More broadly, just what does it mean to authenticate a
> credential, vs. authenticating a protocol peer?  In the case of a
> download, e.g., the originator of the credential may well have signed the
> credential object at some point in the past, enabling its authenticity to
> be verified, but won't generally be its source from the perspective of 
the
> transfer protocol.  Does the original object signing satisfy the intended
> requirement, or is this intended to concern connection-level
> authentication of the credential provider (e.g., via TLS)?
>

AWA:  Well, my intent was that the actual credential itself SHOULD/MUST 
have been (signed/MACed/...), and that e.g. signature on the original 
object meets these requirements.  These were not intended to be 
requirements that the entities executing the protocol provide such 
protection for the credential while in transit.  Why, you might ask? 
Because to me it seems more important that the original object be protected 
from original "creation" point until delivered to the user than merely 
protected in transit.  E.g., the fact that a key was transferred over a TLS 
session is nice, but it doesn't say anything about what happened to that 
key PRIOR to the fact of it being transferred, while imposing the 
requirements on the original object does say something powerful.

That's my .02, but we welcome comments from others on this issue.

> Re #G7, it seems somewhat strange to specify support for a particular
> credential format (an opaque object transported by the protocol) under 
the
> heading of a protocol conformance requirement; by analogy, it would be as
> if conformance to the TCP specification required support for HTTP (or for
> any other specific protocol which layers over TCP).  This may be an
> interoperability requirement, but it seems outside the scope of protocol
> conformance.
>

AWA: G6 and G7 really go together on this.  I'll look around and see if 
there's a better place to put those two requirements.  I'd sort of like to 
leave them in the document somewhere, though.

> Requirements #S6 and #S7 mesh a bit oddly to me.  I can see value in
> authenticating the server to the client for download, primarily as an aid
> to determining that the most current version of a credential is being
> obtained.  (I'd expect that a wholly invalid credential would probably be
> detected based on integrity facilities within the credential format.) 
 I'm
> not sure that this is necessarily a MUST for all cases, but don't think
> that its value depends on whether or not the server authentication can be
> verified before the credential crosses the wire.  If, e.g., a
> correctly-formed credential carried data which could be used as one of 
the
> inputs applied to cross-check the server's authenticity after the fact,
> this could be OK (as long as the client didn't overwrite any existing
> credentials before these steps were performed).  Would it be reasonable 
to
> place server authentication upon download as a general SHOULD, 
independent
> of whether or not that authentication occurs prior to the download
> operation?
>

AWA:  I can live with that suggestion.  It's sort of interesting now that I 
look at it again that we say "... MUST... if the user is able to verify..." 
I think a SHOULD would be okay, here.

> --jl
>
>

Al Arsenault

RE: Further SACRED requirements comments

Al, all, re:

>
> In the requirements document, #F4 might usefully be restated "The details
> of the actual credential type or format MUST be opaque to the protocol,
> though not to processing within the protocol's peers. The protocol MUST
> NOT depend on the internal structure of any credential type or format."
> >
> 
> AWA:  Okay, I'm not exactly sure what you mean by the new 
> clause "...though 
> not to processing within the protocol's peers..."  Is your 
> intent to convey 
> that the entities that execute the SCACRE protocol in 
> question might also 
> be expected to process the credential at some point, or is 
> there some other 
> point that I'm missing?

I was trying to draw out the point that, while a credential format may be
opaque to the protocol per se, it still needs to be recognized and processed
within the end entities.  This may be stating the obvious, but (mindful also
of some discussion at the San Diego session about distinctions between
SACRED protocol requirements vs. end-entity requirements), I thought it
might be a clarifying point to add here.

> If #G3 and #G4 (authentication and integrity protection for transferred
> credential data) are necessarily to be accomplished by the protocol,
> rather than within the credential objects themselves, suggest rewording to
> "The protocol <SHOULD|MUST> provide ...", consistent with subsequent
> requirements.  More broadly, just what does it mean to authenticate a
> credential, vs. authenticating a protocol peer?  In the case of a
> download, e.g., the originator of the credential may well have signed the
> credential object at some point in the past, enabling its authenticity to
> be verified, but won't generally be its source from the perspective of the
> transfer protocol.  Does the original object signing satisfy the intended
> requirement, or is this intended to concern connection-level
> authentication of the credential provider (e.g., via TLS)?
>
>
> AWA:  Well, my intent was that the actual credential itself 
> SHOULD/MUST 
> have been (signed/MACed/...), and that e.g. signature on the original 
> object meets these requirements.  These were not intended to be 
> requirements that the entities executing the protocol provide such 
> protection for the credential while in transit.  Why, you might ask? 
> Because to me it seems more important that the original 
> object be protected 
> from original "creation" point until delivered to the user 
> than merely 
> protected in transit.  E.g., the fact that a key was 
> transferred over a TLS 
> session is nice, but it doesn't say anything about what 
> happened to that 
> key PRIOR to the fact of it being transferred, while imposing the 
> requirements on the original object does say something powerful.
> 
> That's my .02, but we welcome comments from others on this issue.

I fully agree.  I think that the authenticity and integrity protection
spanning from credential generation to usage, at the level of the credential
object, is of primary importance (even though not strictly a part of the
SACRED protocol); applying the same services at the connection level offers
incremental value but doesn't replace the benefits of object-level
protection.  It seems like a classic end-to-end security argument; if it's
possible to abstract away trust in intermediaries, it's usually good to do
so. 

--jl 

Some SACRED blasphemy

SACRED persons, I hope that I may be forgiven a minor blasphemy ....

Both the SACRED requirements document and the SACRED framework document make
reference to
"entities" that use credentials.  In reading through the documents though,
they seem to be
making the assumption that an entity is a "user" who wants to make the
credentials
that are available to her in the context of some device environment, also
available to
her in a different device environment.

I think a little broader view is potentially useful.  

Some set of Authorization Entities (e.g. humans and/or devices) wishes, upon
satisfaction of 
some particular authorization policy, to make available to some set of
Destination Entities 
(e.g. humans and/or devices) some credentials supplied by some set of Source
Entities
(e.g. humans and/or devices). 

So what the heck does that mean?

Well, the applications that I have in mind are:

*   Key backup
*   Key escrow
*   Key distribution

where the Authorization Entities may be users, security administrators,
escrow agents or certification
authorities, and the Source Entities may include CA systems, key generation
devices, escrow agents, 
security administrators, and users, and the Destination Entities may include
users, security administrators,
VPN devices, and security administrators.

This view separates the authorization of the credential transfer from the
source of the credentials and the destination of the credentials.  Among
other situations, this addresses the case in which a device operator
(e.g. VPN installer, firewall administrator, server administrator)
authorizes credential transfers between two 
devices, the source device and the using device. 

The policies for some of the cases may involve multi-party authorization.
In that case, it would be
necessary to have some means for correlating the authorization warrants from
two or more Authorization
Entities.  At the least, this might involve including some sort of
Transaction ID in the SACRED protocol.
A more elaborate version of the protocol might involve communications among
Authorization Entities to 
solicit a quorum for a particular transaction.

Just some heretical thoughts .....

- Carlin Covey
  Cylink Corp.