RE: [security-services] Metadata for 1.1 Web Browser SSO Profile, Draft 06, 1 May 2003

["Jahan Moreh" <jmoreh@sigaba.com>]

Tim -
I will add this to an appendix and will publish a new version later today.
I believe this is a specific case that falls under the general category of
metadata exchange protocol. This write-up is very timely in that I hope it
will engender further discussions on the general topic.


I have made some of the changes you suggested a couple of weeks ago in
http://www.oasis-open.org/archives/security-services/200307/msg00020.html,
but not the main change (i.e., signing the metadata with the signature key
whose corresponding verification key is in the metadata itself). I am
struggling with the verbiage for lines 277-281. Could you send me a draft of
what your are thinking should replace these lines?

Thanks,
Jahan

----------------
Jahan Moreh
Chief Security Architect
310.286.3070

> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: Wednesday, July 23, 2003 7:26 AM
> To: 'jmoreh@sigaba.com'
> Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> Profile, Draft 06, 1 May 2003
>
>
> Jahan - Apologies.  I didn't proof reading the text properly.  The first
> paragraph of the section on "Validation string calculation"
> should read ...
>
> The validation string SHALL be calculated from the metadata by operating
> upon it with the SHA-1 hash algorithm.  The calculation shall be performed
> over the <EntityDescriptor> element, starting with the "<"
> character of the> start tag and finishing with the ">" character of the
end tag..  The
> right-most 4 bytes of the resulting digest are discarded.  The left-most 3
> bits of each of the remaining 16 bytes are discarded.  The
> remaining sixteen
> 5-bit values are represented as alphanumeric characters according to the
> following table.
>
> Sorry for the inconvenience.  All the best.  Tim.
>
> -----Original Message-----
> From: Tim Moses [mailto:tim.moses@entrust.com]
> Sent: Wednesday, July 23, 2003 10:08 AM
> To: 'jmoreh@sigaba.com'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> Profile, Draft 06, 1 May 2003
>
>
> Jahan - I would like to encourage debate of a standard technique for
> validating metadata exchanged over an untrusted channel.  As an initial
> step, could you add the following description as an appendix to
> the metadata
> draft?  I hope this will spark an informed and valuable debate on the list
> and/or in subsequent teleconferences.  Thanks a lot.  All the best.  Tim.
>
>
> Out-of-band validation
>
> Introduction
>
> In the case that the metadata is not communicated between the source and
> destination over an authentic channel, the destination's copy of the
> metadata is not trustworthy.  Yet, the trustworthiness of all subsequent
> communications between the source and destination depends upon the
> trustworthiness of the metadata.  Therefore, a technique is required to
> validate the destination's copy of the metadata.
>
> Metadata validation MUST be performed using an alternative authentic
> channel, such as a telephone call or facsimile transmission, company
> letterhead, business card or face-to-face exchange.  In order to minimize
> the cost of communicating and validating metadata, it MUST be possible to
> validate metadata verbally and reliably in a telephone call.
>
> Procedure
>
> The following procedure is RECOMMENDED.
>
> 1.	The source SHALL calculate a validation string for the metadata
> according to the procedure described below.
> 2.	The source SHALL communicate the validation string over an authentic
> channel to the destination.
> 3.	The source SHALL communicate the metadata over an untrusted channel
> to the destination.
> 4.	The destination SHALL calculate the validation string for the
> received metadata according to the procedure described below.
> 5.	If the validation string calculated by the destination is identical
> to the validation string received from the source, then the
> destination MAY
> install and rely upon the metadata, otherwise it MUST NOT rely on the
> metadata.
>
> Validation string calculation
>
> The validation string SHALL be calculated from the binary form of the
> authority's self-signed certificate by operating upon it with the
> SHA-1 hash
> algorithm.  The right-most 4 bytes of the resulting digest are discarded.
> The left-most 3 bits of each of the remaining 16 bytes are discarded.  The
> remaining sixteen 5-bit values are represented as alphanumeric characters
> according to the following table.
>
> 00000 > A
> 00001 > B
> ... omitting I
> 11000 > Z
> 11001 > 3
> 11010 > 4
> ...
> 11111 > 9
>
> Finally, the alphanumeric string is divided into four sub-strings, each of
> four characters, and the sub-strings are separated by hyphens.
> For example:
>
> A4HY-8KLN-9T3M-7GK4
>
> Note that hyphens are inserted to assist in dictation.  Note also that the
> ambiguities between I and 1, O and 0 and Z and 2 are eliminated.
> Also, note
> that the ambiguity between upper and lower-case letters is eliminated.
>
>
>
>
>
>
> -----Original Message-----
> From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> Sent: Thursday, July 10, 2003 11:16 AM
> To: Frederick.Hirsch@nokia.com; tim.moses@entrust.com; cantor.2@osu.edu;
> security-services@lists.oasis-open.org
> Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> Profile, Draft 06, 1 May 2003
>
>
> Fredrick -
>
> I think the correct and accurate language is:
> "That is, the public key in the metadata document, as described in Section
> 2.1.5.5 SHOULD only be used for verifying assertions, requests, and
> responses."
> Thanks,
> Jahan
>
>
> ----------------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
>
> > -----Original Message-----
> > From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> > Sent: Thursday, July 10, 2003 7:22 AM
> > To: tim.moses@entrust.com; jmoreh@sigaba.com; cantor.2@osu.edu;
> > security-services@lists.oasis-open.org
> > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> > Profile, Draft 06, 1 May 2003
> >
> >
> > Shouldn't it say at line [279] private key instead of public?
> >
> > "That is, the  private key corresponding to the public key in the
> > metadata document,
> > as described in Section 2.1.5.5 SHOULD only be used for signing
> > assertions, requests, and responses."
> >
> >
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia Mobile Phones
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ext Tim Moses [mailto:tim.moses@entrust.com]
> > > Sent: Wednesday, July 09, 2003 4:14 PM
> > > To: 'jmoreh@sigaba.com'; Tim Moses; 'Scott Cantor';
> > > security-services@lists.oasis-open.org
> > > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> > > Profile, Draft 06, 1 May 2003
> > >
> > >
> > > Jahan - I am thinking of lines 277-281.  From a quick glance,
> > > I don't see
> > > any other reference to this topic.  All the best. Tim.
> > >
> > > PS.  Also look on lines 103, 138 and 164 for typos.
> > >
> > > -----Original Message-----
> > > From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> > > Sent: Wednesday, July 09, 2003 3:36 PM
> > > To: Tim Moses; 'Scott Cantor'; security-services@lists.oasis-open.org
> > > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> > > Profile, Draft 06, 1 May 2003
> > >
> > >
> > > I'll look at the language of this draft and make the
> > > necessary corrections
> > > once we all agree (it seems that we do).
> > >
> > > Tim - can you point to specific line numbers in draft 06?
> > >
> > > Thanks,
> > > Jahan
> > >
> > > ----------------
> > > Jahan Moreh
> > > Chief Security Architect
> > > 310.286.3070
> > >
> > > > -----Original Message-----
> > > > From: Tim Moses [mailto:tim.moses@entrust.com]
> > > > Sent: Wednesday, July 09, 2003 12:28 PM
> > > > To: 'Scott Cantor'; Tim Moses;
> > > security-services@lists.oasis-open.org
> > > > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> > > > Profile, Draft 06, 1 May 2003
> > > >
> > > >
> > > > Scott - We agree. The current draft makes it mandatory to
> > > use a different
> > > > key.  I am arguing that the same key should be permitted.
> > > >
> > > > I am also arguing that a non-keyed digest procedure that results
> > > > in a string
> > > > that can be unambiguously recited over the telephone is
> > > called for.  This
> > > > means that it should have only upper-case letters and numbers, be
> > > > separated
> > > > into chunks of 3 or 4 characters (like a North American phone
> > > > number) and be
> > > > no longer than (say) 16 characters.
> > > >
> > > > All the best.  Tim.
> > > >
> > > > -----Original Message-----
> > > > From: Scott Cantor [mailto:cantor.2@osu.edu]
> > > > Sent: Wednesday, July 09, 2003 11:20 AM
> > > > To: 'Tim Moses'; security-services@lists.oasis-open.org
> > > > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO
> > > > Profile, Draft 06, 1 May 2003
> > > >
> > > >
> > > > > In the case where the key distributed with the metadata is a
> > > > > public signature-verification key, it is acceptable,
> > > > > desirable and conventional to sign the metadata using the
> > > > > corresponding private key.  This is common practice for X.509
> > > > > certificates.  In addition, it allows the integrity of the
> > > > > metadata to be confirmed using an out-of-band "digest".
> > > >
> > > > It shouldn't be mandatory to use the same key, since that
> > > basically only
> > > > permits point to point trust.
> > > >
> > > > > As currently required, the integrity of the metadata has to
> > > > > be protected with a separate key.  Presumably, it too has
> > > > > associated metadata that has to be distributed, protected
> > > > > with another key, which (in-turn) has metadata. Allowing the
> > > > > enclosed key to confirm the integrity of the metadata, breaks
> > > > > this cycle.
> > > >
> > > > PKI always has an arbitrary stopping point somewhere. It's ok to
> > > > allow it to
> > > > be self-signed, but we shouldn't insist on it.
> > > >
> > > > > Here is a suggestion for a digest procedure:
> > > >
> > > > Umm, why not XML signature?
> > > >
> > > > -- Scott
> > > >
> > > > You may leave a Technical Committee at any time by visiting
> > > http://www.oasis-open.org/apps/org/workgroup/security-services
> > /members/leave
> > _workgroup.php
> >
> > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/security-services/mem
> bers/leave_workgroup.php
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/security-services/mem
bers/leave
_workgroup.php

You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php