Xref subject previous
Xref subject next

Bill Sommerfeld writes:
>    On a typical PPP or SLIP link, adding AH to TELNET keystrokes changes
>    them from about 5-byte packets (VJ compressed) to about 65-byte
>    packets.  You've got to be pretty concerned about security to put up
>    with that.
> 
> Not quite -- you just need to rev VJ-style compression to compress out
> the mostly-invariant parts of the AH, which I think is everything
> except the 16-byte MD5 hash..

Sounds good ... as soon as someone implements it.

> From: Bill Sommerfeld 
> Not quite -- you just need to rev VJ-style compression to compress out
> the mostly-invariant parts of the AH, which I think is everything
> except the 16-byte MD5 hash..
>
I already did, see draft-simpson-ipv6-hc-00.txt.

PPP Protocol 004f

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Invariants and Options Pau-Chen Cheng
Xref subject next

I had thought the text was quite clear.  Any values that "are not known
with certainty" are zeroed.

There is no need to debate as to whether any of those fields are
worthwhile for authentication.  That debate has already taken place.

We certainly could debate whether the spec is implementable.  But, we
already have an implementation, and mine should be ready next week.

IBM is wrong.  The IHL and Total Length do not change for any IP option.
It is not (and never has been) legal for a router to add an option
during transit.

The IPv4 base header fields that vary are TTL (every hop) and checksum
(every hop), and these are enumerated in the draft [p 7].  A flag
sometimes called the DEC-bit also varies, which is set by some
intermediate routers.  (gotcha!)  All others are invariant.

Authentication always takes place _after_ re-assembly [p 8].

IP Options that MUST be supported are 0, 1, and loose source route.  All
others are optional [RFC-1122, p 37].  The Security Association MUST
keep track of which other options are known at the receiver.  Nobody
said hand configuration would be easy.

IPSO must be included in the authentication.  But, again, you will need
to know that your receiver supports IPSO.  Otherwise, why send it?

My solution (since I don't support most options anyway) is that if any
options are included in the IP header, I tunnel.  Always.  That
preserves the wierdo security labels, and any other thing the
originating host sent.

Also, loose source route if present MUST NOT record any tunnel, since
the TTL is not decremented in the tunnel.

But then, I am principally concerned with routers.  The host side never
sends options, so it is not a problem for me.  Any options I receive are
zeroed, since I don't support them.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

You folks have a remarkable facility for re-hashing old arguments.  This is
supposed to be an implementors list, not another debate.

The IP Minimum Fragment (8 bytes) [RFC-0791, p 25] is too small to add
an authentication header to every fragment.

The authentication header is fragmented just like everything else.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

>We feel that one of two things should be done.  Either the IP header
>should be excluded entirely from the calculation, or -- at most --
>a transport-style pseudo-header should be used instead.  Again,
>details will appear on ipsec, either tomorrow or Friday.

Amen. Cover a pseudo-header with a well defined format and ignore the
IP header. The source and destination addresses are the only two IP
header fields that really matter. (Well, the length does too, but this
is implicit in the computation of the authenticator).

Phil

Xref subject previous
Xref subject next



> IBM is wrong.  The IHL and Total Length do not change for any IP option.
> It is not (and never has been) legal for a router to add an option
> during transit.

 Bill, thank you for the correction. Indeed I misread RFC791.
 A point, IBM is not wrong on this. It is my personal mistake.

> The IPv4 base header fields that vary are TTL (every hop) and checksum
> (every hop), and these are enumerated in the draft [p 7].  A flag
> sometimes called the DEC-bit also varies, which is set by some
> intermediate routers.  (gotcha!)  All others are invariant.

 Two questions :

   1. Which bit is DEC-bit ?

   2. I think the dest address may change if source routing is used.


Regards, Pau-Chen

Xref subject previous
Xref subject next

> It is not (and never has been) legal for a router to add an option
> during transit.

That's an interesting statement -- but I've never seen it written
down in any RFC.  It's certainly not in 791, 1122, or 1716.  And
historically, there have been a number of experiments and products
that do exactly that, especially for security reasons.  I'm thinking
of thinks like the Visa protocol and Cisco's current treatment of
the IP Security Option.

Xref subject previous
Xref subject next

>IPSEC *can't* avoid denial of service attacks.  Thus I don't think
>it's a good idea to change IPSEC to authenticate fragments -- this
>already has disadvantages, and can't render IPSEC invulnerable to
>denial of service attacks or otherwise strengthen IPSEC.

Denial-of-service attacks on the Internet come in two distinct flavors.

The one that usually comes to mind is the most general one: steering
legitimate packets into the bit bucket, or modifying them. You're right,
there's not much IPSEC can do about this.

Not everybody can mount this kind of attack. You need access to one of
the network links between the legitimate parties. This takes either an
insider at one of the networks or somebody who has hacked his way in.

But there's another, more limited kind of denial-of-service attack
that almost *anyone* can do: the blind generation of bogus
packets. Assume there are no network filters on the IP source
addresses one puts into his or her packets. (People have proposed such
filters, but I think they're an exceedingly bad idea. They break
mobile IP and various hybrid connectivity services, among other
reasons.)

Anyway, you can easily pummel a victim with packets that purport to be
from anyone you like. You may not be able to see the responses that
are routed to the host you claimed to be, but you can still have an
effect. *If* you can guess what to put into the packets to have them
accepted.

This suggests a simple protocol countermasure: the exchange of random
nonces. Even if the random values are exchanged in the clear, if
they're large and unpredictable then a blind attack like this won't
work. This is the reasoning behind the "cookie exchange" in Photuris,
and it's also a good defense against TCP sequence number spoofing.

It seems to me that if we randomize IP IDs, then a blind attacker
would have a harder time injecting bogus fragments. 16 bits isn't as
wide a nonce as you might like, but it can't hurt. But perhaps it'd be
enough to keep us from adding more complexity to an already delayed
IPSEC...

Phil

Xref subject previous

>On a typical PPP or SLIP link, adding AH to TELNET keystrokes changes
>them from about 5-byte packets (VJ compressed) to about 65-byte
>packets.

Which takes an extra 33ms over V.32bis (14.4kb/s), 16ms over V.34
(28.8), and 7.5ms over ISDN (64kb/s). As compared to typical existing
one-way propagation delays of perhaps 75-100ms for the modems and 15ms
for ISDN, due mainly to FIR equalizer delays.

So while the added overhead is not negligible, it is not nearly as
bad as it may seem at first.

Phil

Xref: Re: IPv4 option processing for AH (LSRR/SSRR/RR)  Craig Metz
Xref subject previous
Xref subject next



>>We feel that one of two things should be done.  Either the IP header 
>>should be excluded entirely from the calculation, or -- at most -- 
>>a transport-style pseudo-header should be used instead.  Again, 
>>details will appear on ipsec, either tomorrow or Friday.
>
>Amen. Cover a pseudo-header with a well defined format and ignore the 
>IP header. The source and destination addresses are the only two IP 
>header fields that really matter. (Well, the length does too, but this 
>is implicit in the computation of the authenticator).

The IPSP protecting some but not all of the IP header is going to lead to 
problems in the long run.  My preference is to protect the addresses and IP 
payload only, but if there are some options that people feel need integrity 
protection (like a label), then I suggest that a list of options be 
compiled.

Is it possible for a router to change the order of the options?  I do not 
know why an implementation would do this, but it does not seem break any 
rules.  So, if we go with the list of integrity protected options, we may 
need to state the order that the options placed for hash calculation 
purposes.  This added credibility to the pseudo-header idea.

Russ

Xref: Re: fragmentation before or after IPSEC?  Craig Metz
Xref subject next

It took me a while to remember it, but at Danvers I presented an attack
on AH if fragmentation is done before authentication.

Assume host-pair keying.  The object of the attacker is to forge a
packet for another connection from a machine he or she already has
access to.  (Given things like UDP echo, access may not be required.)

Fragmentation data cannot be included in the AH calculation, since it
can change en route.  The attacker sends a large packet with the
data to be inserted at the fragmentation boundary.  The first fragment
will have the true transport header; the second will have a phony
transport header.  This packet is recorded; a new IP header is inserted
instead, with no fragment bits, and reinjected onto the wire.  When
received, the bogus transport header will be believed, and the packet
will be delivered to another connection.

Xref subject previous


        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


In message <9508070221.AA20862@eitech.eit.com>, smb@research.att.com writes:
>Fragmentation data cannot be included in the AH calculation, since it
>can change en route.

	IMO, this is all that needs to be said. If it can change en route
in such a way that you don't know what it's going to look like at the sender,
you can't authenticate it.

	As far as the rest of the fragmentation relation to AH discussion
goes, I agree with Bill Simpson -- this is a rehash of a said-and-done
debate on the IPSEC list. We might as well move on to the real problem --
implementation.

								-Craig

Xref subject previous


        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


In message <9507068077.AA807724051@spysouth.spyrus.com>, "Housley, Russ" writes
:
>Is it possible for a router to change the order of the options?  I do not 
>know why an implementation would do this, but it does not seem break any 
>rules.  So, if we go with the list of integrity protected options, we may 
>need to state the order that the options placed for hash calculation 
>purposes.  This added credibility to the pseudo-header idea.

	As far as I have been able to work out so far in my head and in code,
some new restrictions (though backward-compatible with sane practice) will be
required in order to handle IPv4 options for IPSEC. This is mostly a result
of the lack of restrictions on IPv4 options, which IMO has a lot to do with
their little-used nature in most environments.

									-Craig

Xref subject previous

> From: smb@research.att.com
> > It is not (and never has been) legal for a router to add an option
> > during transit.
>
> That's an interesting statement -- but I've never seen it written
> down in any RFC.  It's certainly not in 791, 1122, or 1716.  And
> historically, there have been a number of experiments and products
> that do exactly that, especially for security reasons.  I'm thinking
> of thinks like the Visa protocol and Cisco's current treatment of
> the IP Security Option.
>
Oh, dear.  Cisco's _current_ treatment?  We have to make this work in
real environments, and Cisco has sold a few routers over time....

Insertion (or rearrangement) of options _will_ break the current design,
which was originally for IP-6, and made some assumptions about the
stability of the path.

If that is so, then we MUST change to a pseudo-header.  I'll call Joyce
to delay RFC publication.  It was supposed to be today.....

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Part Three: Field Variance Analysis  Craig Metz
Xref subject next


Craig, I just glanced over your 3 parts. I have not thought them over in
details
yet. But I have a simple question :

  I got the impression if a IP header field is labeled "invariant" by you,
  it does not mean it will not be changed. It means that if it is changed,
  then the packet should be considered "bad". Is my impression correct ?


Thank you.


Regards, Pau-Chen

Xref subject previous
Xref subject next


Craig, I just glanced over your 3 parts. I have not thought them over in
details
yet. But I have a simple question :

  I got the impression if a IP header field is labeled "invariant" by you,
  it does not mean it will not be changed. It means that if it is changed,
  then the packet should be considered "bad". Is my impression correct ?


Thank you.


Regards, Pau-Chen

Xref: Re: Part Three: Field Variance Analysis Pau-Chen Cheng
Xref: Re: Part Three: Field Variance Analysis Pau-Chen Cheng
Xref subject previous
Xref subject next


        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


	The second thing that I've heard that I disagree with is that the
IP header has so many more variant fields and fields that aren't critical
to security that we should just use a pseudo-header. One thing in these
arguments I disagree with is the definition of "critical to security".

	Ninth assertion: Fields that can be used for denial-of-service
attacks must be authenticated so that the denial-of-service attack can
be detected and logged.

	Even if mucking with a field can't be used to get into a system,
steal a connection, or something direct like that, it frequently has the
ability to cause other denial-of-service situations. When any denial-of-
service attack is in progress, you need to be able to know this in order
to stop it. Fields that aren't critical to system security but could be
modified to create a denial-of-service attack should still be authenticated
for the sole purpose of detecting that attack.

	Also, I'm not a cryptographer and I don't play one on TV, but it
would seem to me that known nonzero but not really important values are
probably better than zero values and should not be worse. It would seem
to me that information of that sort should be stirred into the pot just to
have some nonzero bits in the stew. Someone who knows more about cryptography
and cryptographic checksums could offer better input on this subject, but,
unless someone with more crypto experience can explain otherwise, I am
working from the assumption that nonzero fields are better than zero fields.

	Some discussion should be given to reserved fields. Currently, I
believe that reserved fields should be included in the hash for exactly
the same reason unknown option fields should be. The argument and cases
is exactly the same.

	That all said, this is what I concluded for variance:

	Legend:
		Classes:
			Invariant = If this field changes, the packet is
					not authentic
				(C) = Changed by some routers. By definition,
					however, the packet is not actually
					authentic if this field is changed
					and not changed back before the next
					AH check.
			Variant = If this field changes, the packet is
					still authentic
					(L) = Due to layering (e.g., of 
						fragmentation below AH)
					(T) = Due to transit
			Predictable = This field changes deterministically,
					so we can figure out what it will
					look like at the receiver
		Actions:
			Hash = Run straight through hash
				(R) = Redundant, i.e., should be authentic
					by virtue of getting to AH processing,
					but we still want a crypto guarantee
			Zero = Run a same-size zero block through hash
			Roll = "Roll-forward"/compute how it would look at
				the receiver after re-assembly, run result
				through hash

		Other Symbols:
			(deprecated) = Obsolete or never caught on. If I
				label your favorite option deprecated, don't
				think I'm trying to slam it. It's just that
				I don't know of any system that uses it.
				You can probably get away with not processing
				deprecated options, but I wouldn't recommend
				that you do so.
			(*)(+) = Indicate footnotes follow with more info.

==== IPv4 ====

IPv4 Header: [RFC791]

	Field		Size	Class		Action

	Version		4 bits	Invariant	Hash (R)
	IHL		4 bits	Invariant (C)	Hash (R)
	TOS		8 bits	Invariant (C)	Hash
	Total length	16 bits	Invariant (C)	Hash (R)
	Identification	16 bits	Invariant	Hash
	Flags:
	  Reserved	1 bit	Invariant	Hash
	  DF		1 bit	Invariant	Hash
	  MF		1 bit	Predictable	Roll (=Zero)
	Fragment off.	13 bits	Predictable	Roll (=Zero)
	Time to Live	8 bits	Variant (T)	Zero
	Protocol	8 bits	Invariant	Hash (R)
	Header Checksum	16 bits	Variant (L)	Zero (R)
	Source Address	32 bits	Invariant	Hash
	Destination Ad.	32 bits	Predictable(*)	Roll(*)

	(*) If a source route is present and the pointer is less than the
		length (indicating that this is not the final destination),
		the Destination Address field must be filled in with the
		last destination address in the source route's list.

IPv4 End of Option List Option: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash

IPv4 No Operation: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash

IPv4 Security Option: [RFC791] (*) (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Security (S)	16 bits	Invariant	Hash
	Compartments(C)	16 bits	Invariant	Hash
	Handling Rst(H)	16 bits	Invariant	Hash
	Trans. Ctl(TTC)	24 bits	Invariant	Hash

	(*) This option has the same type value (130) as the IPv4
		Basic Security option [RFC1108].

IPv4 Loose/Strict Source and Record Route options: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Pointer		8 bits	Predictable(*)	Roll
	Data		var.	Predictable(+)	Roll

	(*) At the final destination, the Pointer will be equal to (Length+1)
	(+) The algorithm for rolling source route data is:
		0. If Pointer > Length, don't roll (you have it already)
		1. Hash up to the octet before the one pointed to by Pointer
		2. Hash the destination address in the IP header
		3. If (Pointer + (size of dest address)) > Length, you're done
		4. Hash from Pointer to (Length - (size of the dest. address))

IPv4 Record Route option: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Pointer		8 bits	Variant		Zero
	Data		var.	Variant		Zero

IPv4 Stream Identifier option: [RFC791] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Stream ID	16 bits	Invariant	Hash

IPv4 Internet Timestamp option: [RFC791] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Pointer		8 bits	Variant		Zero
	Overflow	4 bits	Variant		Zero
	Flag		4 bits	Invariant	Hash
	Data		var.	Variant		Zero

IPv4 Probe/Reply MTU options: [RFC1063] (*) (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Value		16 bits	Variant		Zero	

	(*) RFC1700, Assigned Numbers, lists RFC1191 as being the
		current specification for these options. RFC1191 is
		the current specification for Path MTU Discovery
		and obseletes RFC1063, but it does not mention this
		option at all. RFC1063 defines the latest version
		of this options.

IPv4 Basic Security option: [RFC1108] (*)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Classification	8 bits	Invariant	Hash
	Protection Auth	var.	Invariant	Hash

	(*) This option has the same type value (130) as the IPv4
		Security option [RFC791].

IPv4 Extended Security option: [RFC1108]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Add. Info Fmt.	8 bits	Invariant	Hash
	Add. Info	var.	Invariant	Hash

IPv4 Traceroute option: [RFC1393] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	ID Number	16 bits	Invariant	Hash
	Outbound Hop C.	16 bits	Variant		Zero
	Return Hop Cnt.	16 bits	Variant		Zero
	Originator IP	32 bits	Invariant	Hash

==== IPv6 ====

IPv6 Header: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Version		4 bits	Invariant	Hash (R)
	Priority	4 bits	Invariant	Hash
	Flow Label	24 bits	Invariant	Hash
	Payload Length	16 bits	Invariant	Hash (R)
	Next Header	8 bits	Invariant	Hash (R)
	Hop Limit	8 bits	Variant (T)	Zero
	Source Address	128 bit	Invariant	Hash
	Destination Ad.	128 bit	Predictable(*)	Roll(*)

	(*) If a source route is present and the pointer is less than the
		length (indicating that this is not the final destination),
		the Destination Address field must be filled in with the
		last destination address in the source route's list.

IPv6 Hop-by-Hop/Destination Options Headers: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Hdr Ext Len	8 bits	Invariant	Hash
	Option Data	var.	var.(*)		var.(*)

	(*) If the third-highest-order bit in the Option Type is set,
		the Option Data MUST be Zeroed. If the third-highest-order
		bit in the Option Type is not set, you must either Hash
		or Roll, depending on the option.

IPv6 Pad1 Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash

IPv6 PadN Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash
	Option Length	8 bits	Invariant	Hash
	Option Data	var.	Invariant	Hash

IPv6 Jumbo Payload Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash
	Option Length	8 bits	Invariant	Hash
	Option Data	32 bits	Invariant	Hash

IPv6 Routing Header: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Routing Type	8 bits	Invariant	Hash
	(*)		(*)	(*)		(*)

	(*) More data follows depending on type.

IPv6 Routing Header Type 0: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Routing Type	8 bits	Invariant	Hash
	Num Addrs	8 bits	Invariant	Hash
	Next Addr	8 bits	Predictable(*)	Roll(*)
	Reserved	8 bits	Invariant	Hash
	Strict/Loose	24 bits	Invariant	Hash
	Addresses	var.	Predictable(+)	Roll(+)

	(*) At the final destination, the Next Addr field will be equal to
		the Num Addrs field
	(+) The algorithm for rolling source route data is:
		0. If Next Addr = Num Addrs field, don't roll (you have it)
		1. Hash Address[0] through Address[Next Addr - 1]
		2. Hash the destination address in the IPv6 header
		3. If (Next Addr + 1) > Length, you're done
		4. Hash from Address[Next Addr] through Address[Num Addrs - 2]

IPv6 Fragment Header: (*) [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Reserved	8 bits	Invariant	Hash
	Fragment Offset	13 bits	Predictable	Roll (=Zero)
	Res		2 bits	Invariant	Hash
	M flag		1 bit	Predictable	Roll (=Zero)
	Identification	32 bits	Predictable	Hash

	(*) This is academic, since you MUST not ever authenticate
		fragments except when the fragments are inside a
		tunnel (AH processing is done before fragmentation
		and after re-assembly).

==== IPv4/IPv6 Common ====

IP Authentication Header: (*) [RFC1826]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Reserved	16 bits	Invariant	Hash
	Security Param.	32 bits	Invariant	Hash
	Auth. Data	var.	Variant (L)(+)	Zero

	(*) Yes, you have to authenticate the authentication header.
	(+) You have to zero this field or you get a chicken-and-egg
		problem.

IP Encapsulating Security Payload: [RFC1827]

	Field		Size	Class		Action

	Security Associ	32 bits	Invariant	Hash
	Opaque Transfor var.	Invariant(*)	Hash(*)

	(*) Unless the authenticating point participates in the ESP
		key management, it doesn't know what the transform.
		Treating all of this data as opaque seems to be the
		most reasonable thing given the nature of the data
		and the currently defined DES-CBC transform.

        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


	I have heard several statements on this issue that I disagree
with, and now I have working (well, mostly ;) code that I can use to back
up my disagreement. 

	The first thing I've heard that I disagree with is that we should
not include IPv4 options in the IPv4 authentication computation. There are
two main reasons given:

	1. If we get an option that we can't process, we must ignore
		it (RFC1122). If we can't process it, though, we don't
		know whether the fields are invariant, so we might be
		dropping the packet solely because we can't process
		the option, which conflicts with RFC1122.

	2. Routers might insert, remove, or re-order options.

	I will discuss the latter one first. When routers mess with the
options attached to the packet, you are guaranteeing that the packet does
not have intermediate authenticity because the packet at some points along
its path of travel is not the same as the packet as sent by the sender.
Therefore, whenever routers modify the packet in any way other than the
modification of specific variant fields, you do not have intermediate
authenticity anymore at some or all points along your path. In the
context of my second example, C may legitimately insert an IPSO option,
but if E or F is the router stripping that option and restoring the packet,
the packet will not have intermediate authenticity at D because the packet
is not what A sent or what A intends B to receive.

	However, end-to-end authenticity guarantees are not mutually
exclusive with routers that modify options *as long as they put things
back the way they found them somewhere along the line*. In the context of my
second example, C may legitimately insert an IPSO option so long as D, E, or
F removes it and restores the packet to its original form. As long as it
does, B will see the packet as A intended it to be seen, and it is therefore
end-to-end authentic. If C inserts the IPSO option and no router removes it,
the packet at B is not end-to-end authentic because the packet at B is not
what A sent or intended B to see. It is important that the AH verification
procedure fail in this case exactly because the packet has been modified
in transit. AH has no concept of good or bad modifications, but it has a
strict concept of authenticity. This packet is not authentic because it has
been modified.

	One of our resident experts on routers that insert, examine, and remove
IPSO options into IPv4 packets tells me that "no known router ships configured
to perform IPSO modifications and that such modifications only happen if the
router admin actively configures the router to do so. Further, IPSO
modifications are directly security-relevant -- we do want packets with
intermediate IPSO modifications to fail end-to-end authenticity checks".

	Now to discuss the first problem. A number of interpretations of
RFC1122 have been posted in this discussion, but I would like to work from
what RFC1122 says about options you can't process:

	"The IP and transport layer MUST each interpret those IP
	 options that they understand and silently ignore the
	 others."

	The problem here is one of how we can determine whether fields of
an option are variant or not. I think that we all can agree that if we know
how to handle an option, we can presumably get some sort of consensus on what
is and isn't variant and implement that. So the question is really what
"silently ignore" means. The reason I quote the text here is because most
people have substituted the word "skip" for "silently ignore" and operated
with the assumption that this is the only legitimate interpretation. I
disagree. Consider transport headers and transport data. They're not network-
level, we have no right at the AH level to mess with them. What do we do with
them for AH computation? We run the cryptographic checksum straight over them
with no variance substitutions. Therefore, I believe that a reasonable
definition of "ignore" is also to simply run the cryptographic checksum 
straight over the options we can't handle with no variance substitutions.
Another possibility, which I don't recommend, is to zero out the options
we can't process except for their type and length fields (more on this
later).

	There are three classes of unknown options for purposes of
evaluating which definition of "silently ignore" is most reasonable.
The first are unpredictably variant options. For example, the timestamp
option. The second are invariant options. For example, the IPSO option.
The third are predictably-variant options. For example, the SSRR option.

	Fifth assertion: If both sides cannot process an option and both
sides do the same thing in cases of unknown options (either skip/omit,
zero, or blind-hash), all three methods will work. Only in the last
case, however, will the contents of the option be protected from
modification in transit. In this case, the best option is a blind-hash.

	Now we have the case, which I consider more common and more
interesting, where one side does not know how to process the option
but the other does. If you "skip over" (omit from computation) options
you can't handle, you lose for all three cases because the side that
does know how to process the option will include data, some of which
may be zeroed out, from the option at that position in its computation.

	If you zero out options you can't process except for the type and
length, you win for fields of the first class. In the case of the second class,
the field will be hashed blindly as its value, and you will lose if its value
doesn't happen to be zero. In the case of the third class, the field has a
value that is computed for authentication to match what it would look like at
the receiver -- if it doesn't happen that the value should be zero, you lose.

	If you blindly hash options you can't process, you lose for the
first class unless the values you blindly hash happen to be zero. You never
lose in the second class. You lose in the third class unless you are the
receiver, in which case the values you see and hash are also what you're
supposed to see at the receiver (because you ARE the receiver).

	Skipping over the options you can't process is clearly bad to me
because you always lose if one of the ends can process the option.
Coincidental zeros aside, you lose in two of the three cases if you
zero out the fields other than type and length. Coincidental zeros aside,
you lose in one case all the time and another if you are not the
receiver if you blindly hash the options you can't process.

	Sixth assertion: Blindly hashing the value gives you clearly better
security if both sides can't process an option and slightly better
security if one side can't process an option. It also provides for a simpler
implementation versus hashing the type and length and zeroing the rest,
which would otherwise be the next best way to handle the problem of IPv4
options you can't process.

	For purposes of processing IPv4 options when you don't know how,
keep in mind this statement from RFC1122: "For this purpose, every IP option
except NOP and END-OF-LIST will include a specification of its own length."
RFC791 says that there are two forms an IPv4 option can take: "Case 1: a
single octet of option-type. Case 2: An option-type octet, an option-length
octet, and the actual option-data octets.". 

	Seventh assertion: There are no options of case 1 that make sense
other than NOP and END-OF-LIST, which all non-brain-damaged systems can
handle. Therefore, all options that you do not know how to process will be
of case 2, and you can therefore determine the length of options you can't
handle. This allows you to get back on track when an unknown option is
followed by a known option.

	You're walking with a safety-net here -- in the event that this
assertion is not true, you will eventually either run into an option that
looks legitimate or come into a situation where you are out of option data.

	Eighth assertion: If you encounter an out-of-option-data situation
or encounter the END-OF-LIST option with more data between it and the end
of the option space data (the IP header length with the size of the base IP
header subtracted), you treat all offending data as an unknown option and,
therefore, you blindly hash it. 

	If you run into, for instance, a source route, and that source route's
length points outside the option space data length (computed as
aforementioned), something is wrong with the source route and you can't process
it properly. If you know with certainty that the option is bad, immediately
drop the packet. There is no point in computing the hash over a known-bogus
packet and/or passing it on to the next hop. 

	Padding between the END-OF-LIST option and the end of option space data
"is zero" [RFC791]. This data should be blind-hashed.

        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


	As I had mentioned on the IPsec developers' list, I had some
specific thoughts on some IP security issues that are currently being
discussed, but I wanted to wait until I had built some code before
making them known because I wanted to be sure that my ideas were
implementable. I have, it mostly works, there are no outstanding
questions as to whether something is doable or not, so I have prepared
my thoughts into three messages to form a long tirade. I am carbon-
copying this and these to the IPng list, because at some point, in order
to be IPng spec-compliant, all IPng implementations will have to do
security processing, so these issues need to be thought about by IPng
people.

	The first message I will send (part one) is some general
background discussion.

	The second message I will send (part two) is on IPv4 options
that we can't handle. IPng people may want to skip this one, but I
believe that some of the discussion is relevant.

	The third message I will send (part three) is a detailed
listing of my conclusions as to the variance/invariance/predictability
of every defined field in every IP (IPv4 and IPv6) network-level
header I could find a spec for.

	These messages are intended to prompt discussion. Please
direct this discussion to the  mailing list, NOT the
 mailing list. Unfortunately, I will not
have very good network access for the next month, so I will not be
able to participate in this discussion as much as I would like to.

							-Craig

        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


	Throughout these notes, I am assuming that we are not dealing with
fragments. Fragment processing creates wrinkles that have been discussed
previously, and I think that omitting the special case of fragmentation will
help to keep things on-track. In a nutshell, fragments cannot be subject to
intermediate network authentication unless they are passively re-assembled
(which I believe is not a good thing) because authentication processing happens
before fragmentation and after reassembly (think of AH as an ULP instead of a
network option for fragmentation/reassembly purposes).

	First, I have some background architectural points to make. I view the
IP Authentication Header as being able to provide two different types of
security assurances. The first of these is what I will call "intermediate
authenticity", which I define as having guarantees that a packet must have come
from a finite set of senders because of authentic tunnels and network
design. This is not the same as "intermediate network authentication," which I
define as a specific mid-point in a network processing the Authentication
Header in a packet to determine whether or not the packet-in-transit is
currently authentic. The second of these is guaranteed authenticity end-to-end
(i.e., at the sender and receiver). You might think of the former as implicit
security and the latter as explicit security.

	First assertion: End-to-end authenticity assurances imply intermediate
authenticity, but the reverse is not true.

	This all seems fairly obvious, but I think that some of the
subtleties might turn into "gotchas" that people need to consider. Several
of Steve Bellovin's attacks are cases where I believe these two assurance
levels have been confused.

	My first example is a simple use of the "AH Tunnel", where virtual
links between gateways are built by taking the packet in transit, encapsulating
it using IP-IP tunneling, and doing normal AH processing on the resulting
packet.  This case supports both assurances of security for A and B. It
supports end-to-end security between A and B if they use an explicit
Authentication Header in their packets. It provides intermediate authenticity
assurances for A and B because there is a finite set of possible senders. It
also supports intermediate network authentication at C and D of packets between
A and B.  Consider this fictitious network:

	A------|                     |------ B
               |----- C ===== D -----|
        I------|                     |------ J

	(Legend for this note: '=' is a configured AH tunnel, '-' is a link,
	and '|' is a network)

	B has received a packet that claims to be from A to B that carries no
Authentication Header. B has no guarantee that A really sent the packet -- any
other machine in this diagram could have forged it. If C and D have the
security policy that they only allow packets from the tunnel (and won't forward
other packets onto the nets), then, without doing any AH processing itself, B
has an intermediate authenticity guarantee: If the packet is forged, there is a
finite set of possible forgers: I, C, D, J, and B. Random machines on the
Internet, which is where we can envision the tunnel from C to D traversing,
cannot forge a packet from A to B. If D receives a packet from the tunnel, from
the end-to-end authenticity, it has a stronger guarantee: the packet presumably
from A to B that it received from the tunnel must have been sent to D by C.
This is because C and D are sending packets that carry the Authentication
Header, which gets C and D end-to-end (tunnel-end to tunnel-end, really)
assurances.

	If B wants to be guaranteed that the packet could only have come from
A, it must require that there be an authentication header on the packet as sent
by A. In this case, B will get both assurances and you will actually have two
authentication headers (as well as two IP headers) between C and D. This is,
however, the only way to provide end-to-end security in this configuration.

	My second example is more complex. Consider this fictitious network:


	A------|                                     |------ B
               |----- C ===== D ===== E ===== F -----|
        I------|                                     |------ J

	For extra fun, A is source-routing its packet to B through C, D, E, and
F. The packet goes from A to C without an Authentication Header. C encapsulates
the packet in a new IP packet and authenticates it with a C->D key. D verifies
the auth header, decapsulates the packet, processes the source route to find
the next destination E, encapsulates the packet in a new IP packet, and
authenticates it with D->E key. E does the same thing as D, though shifted
along the chain. F checks the auth header against the E->F key, decapsulates
the packet, and sends it to B without an Authentication Header.

	When B gets a packet claiming to be from A, it knows that it can only
have come from a finite set of senders because of the intermediate
authenticity: A, C, D, E, F, I, J, and B. The packet could not have been forged
between C and D, D and E, or E and F, thanks to the authenticated tunnels
between those hosts. Again, A could explicitly add an Authentication Header to
its packet to B to provide end-to-end protection, which would result in the
tunnels carrying a total of two IP headers and two AH headers on the lines
between them (one for the tunnel and one end-to-end).

	Now, let's say that B gets a packet claiming to be from E. The
set of senders who could forge that packet is F, J, and B. A, J, C, and
D cannot forge the packet assuming reasonable security policy because E
will find that its source address is on a packet it received from D and
is forwarding, which is not correct. This has the nifty property of helping
to drop packets caught in a routing loop. F, however, can guarantee using
end-to-end authentication that the packet it is receiving is from E because
it verifies it in the E->F key.

	Let's say that A sends an end-to-end authenticated packet to B over
this network. C and F can add and remove, respectively, any options it
wants from this packet so long as the packet from F->B is the same (except
for obviously variant fields that are exempt from AH processing) as the
packet from A->C. In this case, while you have end-to-end authenticity,
your packet will fail intermediate network authentication. This property has
implications for people doing real intermediate network authentication
are is beyond the scope of our current worries.

	Second assertion: Intermediate changes will not
affect end-to-end authenticity so long as they are reversed.

	This is important for routers with a reputation of mucking with packets
in transit. As long as a router puts things back the way they were before the
packet gets to the receiver, end-to-end authenticity is preserved. If a router
does not, the packet at the receiver MUST fail authentication, because it is
not end-to-end authentic -- the sender didn't send the packet that way. More
on this later.

	My third example is a recent attack scenario from Steve Bellovin:

	A-----|
	      |------B
	C-----|

	Steve's attack goes something like this: C sends B an IP-in-IP
tunneled packet (not from a configured tunnel) where the outside is
authenticated using the C->B key and the inside header claims to be from A.
B verifies the packet, marks it as authentic, decapsulates the inside packet,
and processes it, thinking that it came from A. My belief here is that
this is a case of B confusing the two assurances of authentication.
B is getting intermediate authenticity -- B knows that the "tunneled" C->B
packet is authentic, but B is not getting end-to-end authenticity -- B
doesn't know that the inside packet (that claims to be from A->B) is
authentic. This is a costly mistake.

	Third assertion: When processing a tunneled packet, outside
header authenticity is an issue of intermediate security and inside
header authenticity is an issue of end-to-end security. If you take my
second example and make F and B one system, this might become clearer.

	Fourth assertion: If your system or network policy is FUBAR, so
are your security guarantees. If your system or network policy does something
obviously drain bamaged such as depending on intermediate security to provide
end-to-end security, then your security assurances are going to be very weak.
Some sites will want to use intermediate security for performance reasons or
because they believe that only "outside" machines are a risk. These sites must
be careful not to fall into the trap of believing that they have a higher
level of authenticity assurance than they really have.

Xref: Re: Field Variance Analysis  Craig Metz
Xref subject next

> From: Craig Metz 
> 	Yes. "Invariant = If this field changes, the packet is not authentic".
> This is to say that there exists a set of fields, which I call invariant, that
> MUST be passed through the network without change in order for the packet to
> maintain authenticity. If these invariant fields are changed, then the packet
> is not authentic. Which fields fall within this definition of invariant is
> a decision that we need to make by some sort of reasonable consensus.
>
First, I will agree with Craig's statement, there are header fields that
must pass though the network unchanged.

Second, I will then utterly disagree with the remainder of his analysis!

The unspoken fundamental assumption is that it is better to throw
traffic away in the event of uncertainty.  I do not agree.  We must
design for _only_ the utmost certainty.

We are not authenticating packet headers.  We are authenticating payload
data.  The purpose is to get that data across a diverse network, not
throw as much as possible away.

Therefore, in order to promote _use_ of authentication, we need to make it
as easy and robust to _use_ as possible!  Suddenly discovering that data
stops flowing because of a change in some router somewhere that is not
under the user's control will not be a big win, folks....

                                ----

As to specific IP header fields, I have written code that is widely
deployed that changes the TOS en route.  That is not a "security"
violation, it does not affect the _DATA_, it just changes the path
characteristics....

I have worked on at least 3 routers that set the "reserved" bit in the
IP header when congestion is experienced, and every router and host that
I have worked on passes that bit transparently (even if it doesn't use
or understand it).

My current software base does not use most IP options, and certainly not
the IPSO.  I do not care about its authenticity, since it does not
affect the Security Association that I have with my peer.

In short, I am not currently working on software that could possibly
talk to Craig's software.  That is up to him.  It may be his security
policy.

But I plan on _giving_ this software away to every compatible router
vendor that I have ever worked with, and I won't design a security
policy that could cause the Internet to fragment!

                                ----

There are only a few fields that require authentication:

 - the Destination, as it is the field that together with the SPI will
   determine the Security Association.

 - the Source, since we probably want to send a response.

 - the Length, to preclude appending attacks.

There are a couple of other fields that we might as well authenticate,
as they well known to be invariant:

 - Version (has to be constant).

 - Identification (invariant end-to-end, or fragmentation would fail).

 - Protocol (it had better be ours, or processing will fail anyway).

                                ----

Here is the pseudo header that I have implemented (so far only in the
receive direction).  I beleive this is similar if not identical to what
other vendors have implemented, and hope to test this week.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |       0       |          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |0 0 0|            0            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |    Protocol   |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Source                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Destination                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Options = 0                  |  Padding = 0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The rationale is that since we can't predict rearrangement of options,
we can't verify them.  But if some router _ADDS_ or _REMOVES_ them, or
lengthens or shortens existing ones, that in itself could be a security
violation, which we can easily test for, using IHL and zero placeholders.

I am zeroing not just the Option data fields, but the lengths and types,
too.  I don't care what they are, as they have absolutely no effect on
the authenticity of the payload.  Routers can rearrange them to their
heart's content....

I never reverse LSRR, so I do not care how authentic it may be.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous


        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


In message <9508112244.AA20004@ixextra2.watson.ibm.com>, Pau-Chen Cheng writes:
>Craig, I just glanced over your 3 parts. I have not thought them over in
>details
>yet. But I have a simple question :
>
>  I got the impression if a IP header field is labeled "invariant" by you,
>  it does not mean it will not be changed. It means that if it is changed,
>  then the packet should be considered "bad". Is my impression correct ?

	Yes. "Invariant = If this field changes, the packet is not authentic".
This is to say that there exists a set of fields, which I call invariant, that
MUST be passed through the network without change in order for the packet to
maintain authenticity. If these invariant fields are changed, then the packet
is not authentic. Which fields fall within this definition of invariant is
a decision that we need to make by some sort of reasonable consensus. I
described my conclusions as a starting point for this.

									-Craig

Xref subject previous
Xref subject next


        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


In message <199508141948.AA68240@interlock.ans.net>, "William Allen Simpson" wr
ites:
>First, I will agree with Craig's statement, there are header fields that
>must pass though the network unchanged.

	Well, at least we agree here.
>
>Second, I will then utterly disagree with the remainder of his analysis!

	While I find this unfortunate, it's important that we be talking
about these things and come to some sort of consensus.

>The unspoken fundamental assumption is that it is better to throw
>traffic away in the event of uncertainty.  I do not agree.  We must
>design for _only_ the utmost certainty.

	I think that we are disagreeing as to what certainty we would like
to provide with the Authentication Header. It is my opinion that we need
to provide certainty that the packet that arrives at the receiver is what
the sender expected the receiver to receive and that the claimed sender is
the actual sender. These guarantees are at odds with certainty of packet
delivery in some cases that you have brought up. I have not seen a case
presented yet, however, in which it was not my clear opinion that the spirit,
if not the letter, of the appropriate standards and reasonable network
practice was being violated.

>We are not authenticating packet headers.  We are authenticating payload
>data.  The purpose is to get that data across a diverse network, not
>throw as much as possible away.

	This is a fundamentally important design decision. I believe that
this has already been decided. If it has not, then we better do so now
before trying to proceed, because it has a dramatic effect on further
directions.

	It is my understanding that there are basically three "checklist"
attacks that IPsec must offer reasonable protection against, and it is
my understanding that these are requirements that we either meet or pack
up and go home:

	1. TCP connection stealing
	2. Source-route attacks
	3. IPSO modifications

	The third is one that many people discount, claiming that IPSO is
just broken and shouldn't be a factor. I'm not here to judge IPSO, but
certain government organizations have a large IPSO deployed base and they
won't buy into IPsec at all if it leaves them SOL with IPSO. Both the second
and third on this list implies no alternative but to protect IPv4 options
if we are going to defend against these attacks. If we aren't going to
defend against these attacks, then we can talk in terms of not authenticating
options.

>Therefore, in order to promote _use_ of authentication, we need to make it
>as easy and robust to _use_ as possible!  Suddenly discovering that data
>stops flowing because of a change in some router somewhere that is not
>under the user's control will not be a big win, folks....

	Bill, I've been at sites that use Proxy-ARP as an IGP across multiple
buildings. I've been at sites where admins ROUTINELY assign multiple machines
the same IP address. I've been at sites where a single, massive Ethernet has
over three hundred machines directly attached (no routers, no bridges, all
gobs of big hubs). You and I can probably agree that these are three
scenarios that are examples of bad network design. In none of those cases did
the parts used to build those networks come out of the box drain bamaged --
bonehead network administrators made them that way. And they won't go and fix
it BECAUSE IT SEEMS TO WORK.

	This has a lot to do with my fundamental disagreement with you on the
Cisco/Telebit router issue. On the Ciscos, yes, you can configure them in ways
that will cause them to munge IPv4 headers. This is a configuration that is
as valid per the specs as using Proxy ARP as your IGP, and it's a configuration
that is just as dead wrong. Causing these kinds of setups to break is more of
a feature to me because it forces the admins into the realization that they
are doing something that is really brain damaged and that they better fix it.
IPsec might just provide a suitable carrot to these network admins to fix
things.

	Also, I strongly believe that sites with Cisco routers configured to
munge IPv4 headers are in the vast minority of deployed IP sites. This seems
analogous to engineering all UNIX software to run on a VAX 11/780 just
because some sites still use them. Do you want to be the person at Cisco
that tells large corporate customers who do things right that the security
guarantees they're getting from IPsec aren't as strong as they could be
because it might break some sites who are doing things that are drain
bamaged? I know that I wouldn't want to be.

	And on the NetBlazer... I've used one for a good bit of time, and I
have never noticed it messing with my TOS bits. I'd be interested in more
data on this example of yours (as with the Cisco example, you have provided
a canned conclusion as a reason for why network-level data must be all but
omitted from IPsec without much data to independently confirm or deny your
claims). RFC791 doesn't say it, but it seems to me that routers that twiddle
the TOS bits aren't conforming to the spirit of the spec even if they might
be conforming to the letter. TOS bits tell routers what kind of data the
packet is in a form that routers might be able to deal with in a very
simplistic way (i.e., low-delay, bulk-data). If a router changes the TOS bits,
the routers upstream are getting a different request for treatment than what
the sender asked, and I doubt that the router mucking with the TOS bits has
more information about the type of data being sent than the sending host.

	Please don't interpret this to mean that I'm against operating with
the installed base. This is not so. I'm for trying to push technology, in
this case, trying to push people who've been doing the wrong thing into
fixing what they've got. IPsec could provide the motivation for them to do it.

>As to specific IP header fields, I have written code that is widely
>deployed that changes the TOS en route.  That is not a "security"
>violation, it does not affect the _DATA_, it just changes the path
>characteristics....

	It remains unclear to me how a router can know more than the sending
host what kind of data is in transit.

	If we find that enough systems mess with the TOS bits, we can call
them variant and move on. Protecting the TOS bits is a Good Thing, IMO,
because it pushes people in the direction I believe is correct. The TOS
bits are mostly unusable even today because so many widely deployed
implementations have completely drain bamaged TOS processing. While I'd like
to see that get fixed, I can live with calling TOS a loss and moving on.
We all have bigger fish to fry.

>I have worked on at least 3 routers that set the "reserved" bit in the
>IP header when congestion is experienced, and every router and host that
>I have worked on passes that bit transparently (even if it doesn't use
>or understand it).

	Is it just me, or do these statements directly conflict?

>My current software base does not use most IP options, and certainly not
>the IPSO.  I do not care about its authenticity, since it does not
>affect the Security Association that I have with my peer.

	Again, these are design decisions.

>In short, I am not currently working on software that could possibly
>talk to Craig's software.  That is up to him.  It may be his security
>policy.

	As I understand it right now, we have a number of bubbles forming
of IPsec implementations that won't talk to each other. This is why we
need to come to a consensus as to what goes into the authentication soup.

>But I plan on _giving_ this software away to every compatible router
>vendor that I have ever worked with, and I won't design a security
>policy that could cause the Internet to fragment!

	Then I expect that you'll make sure to give away something that
follows the consensus that develops.

>There are only a few fields that require authentication:
>
> - the Destination, as it is the field that together with the SPI will
>   determine the Security Association.
>
> - the Source, since we probably want to send a response.

	The source is also a part of the security association nowadays. Also,
source and dest frequently are needed for transport demuxes (for instance,
finding the right TCP connection).

> - the Length, to preclude appending attacks.

	Strictly speaking, the total length isn't necessary by your logic,
since appending without also munging the checksum will cause the packet
to fail auth, and the transport has a length field in all cases I know of.

>There are a couple of other fields that we might as well authenticate,
>as they well known to be invariant:
>
> - Version (has to be constant).
>
> - Identification (invariant end-to-end, or fragmentation would fail).
>
> - Protocol (it had better be ours, or processing will fail anyway).

	How do you define this "might as well authenticate"? Could you
expand as to how you are making these conclusions? On what basis are
you classifying these fields?

>Here is the pseudo header that I have implemented (so far only in the
>receive direction).  I beleive this is similar if not identical to what
>other vendors have implemented, and hope to test this week.
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |Version|  IHL  |       0       |          Total Length         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Identification        |0 0 0|            0            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |       0       |    Protocol   |               0               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                            Source                             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                          Destination                          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                  Options = 0                  |  Padding = 0  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>The rationale is that since we can't predict rearrangement of options,
>we can't verify them.  But if some router _ADDS_ or _REMOVES_ them, or
>lengthens or shortens existing ones, that in itself could be a security
>violation, which we can easily test for, using IHL and zero placeholders.

	Again, this is a design question. I can predict that if I send a
packet over our routers, it will either get there with its options
the same way I sent them or it will get dropped because our filter got it.
We have Cisco routers. It just happens that we don't have configurations
on our routers that cause them to go munging packets. For that matter,
Bill, I've never seen a site in my entire life that has a router that
messes with IPv4 options on a packet in transit. Maybe they're more
common in your environment.

>I am zeroing not just the Option data fields, but the lengths and types,
>too.  I don't care what they are, as they have absolutely no effect on
>the authenticity of the payload.  Routers can rearrange them to their
>heart's content....

	Again, this is a design decision.

>I never reverse LSRR, so I do not care how authentic it may be.

	Personally, I could easily live without source routes. I don't like
them -- never have, never will. But there are a number of legitimate cases
in which you might need them. Do we tell people who have systems that might
process source routes that they're SOL if they use them, or do we try to
give them some guarantees through AH? I believe that source routes can be
authenticated, and I explained how I think it can be done. I have code that
has been able to authenticate IPv4 source routes. If you believe that my
method of handling source routes is in error, please elaborate. If you
believe that we shouldn't be authenticating options, as you seem to have
been indicating, then please explain this conclusion.

	We need to talk about this. Simply saying that it's not right, we
shouldn't do it because people could break, or that you don't care doesn't
seem to me to be a good alternative to putting facts on the table that back
up your conclusions.

								-Craig

        Opinions expressed are those of the author and are not
        necessarily those of the author's employer.


IP Security WG Folks,

	I've gotten permission to put a longish code fragment from the
NRL implementation of IP Authentication Header (for IPv6 & IPv4) out
for anonymous ftp at the URL below:

	ftp://ftp.nrl.navy.mil/pub/security/ipsec

	This is copyrighted but freely distributable under the license
terms included at the front of the file.  It is part of our overall
implementation of IPv6 (including ESP and AH), IPv4 ESP, and IPv4 AH
inside 4.4-lite BSD.  We anticipate that our "alpha" release of all of
this software will be available this fall under these same terms.
NRL's work on IP Security is sponsored by ARPA/CSTO and SPAWAR.

	This is the code that Craig Metz has been discussing and is
posted primarily to refute by existence-proof the idea that it is too
hard to implement IP options processing as specified in the Proposed
Standard RFC.

	The posted code works.  Not all of the IP options supported by
our AH implementation are supported by the remainder of our IPv4
stack, which serves to demonstrate that one doesn't have to add full
support for all of the IPv4 options in order to process them properly
for AH.

	I will have some other AH comments coming in a few days as I
get time.  I've been gone unexpectedly for part of the summer and have
been busy writing code for the remainder of the summer.  I have to say
that writing code is among the more pleasant ways to spend one's days.

Regards,

Ran
rja@cs.nrl.navy.mil

Xref subject previous

    Craig metz writes:
	 I recall that you were mentioning IPSO. I seem to vaguely remember
	 that CISCOs can be set to add IPSO tags to outgoing packets. This
	 would seem to be something that could screw things up. Anyone recall
	 if this is the case?

And in fact, not only CAN they be configured to mess with IPSO,
CISCO's are shipped with a DEFAULT behaviour that allows only
unclassified BSO traffic thru. To allow other IPSO (of the RFC1108
flavor) thru you have to jump thru hoops to figure out how to
configure the routers. And to this day I am not sure how to do that.

Someone obviously decided that this was proper behaviour to keep
classified data from accidently being routed to unclassified networks,
but it makes deployment of classified networks an administrative
nightmare. 

Now, having gotten that off my chest, I can get off my soapbox and 
try to add my 2 cents to the issue being discussed. 

The filtering of packets that do not meet a set of configured criteria,
such as the above, is an extreme case of (perhaps inappropriate) behaviour
on the part of a router, that can lead to connectivity problems. It relates
only tangentially to the more general isues of:

  a) Whether IPSO options should/may be modified by any router
  b) Whether IPSO options should be part of the authentication stream
  c) Whether the IPSO options should be included at all

The answer to (a) is yes in the most common deployed MLS (multi-level
security) configurations that I am aware of. In this case, however, 
the "router" in question is really an MLS gateway between networks
with differing security policies. It could, potentially, be something like
a CISCO configured to filter and add IPSO appropriately, but will often
be a B1 or B1/CMW or B2 evaluated MLS system. A configuration might
look something like this:

   Unclassified                                             Classified
   Single Level ---+ MLS     +---+ WAN +---+ MLS      +---+ Single Level
   Network           Gateway 1      +        Gateway 2      Network
                                    |
                                    |                                    
                                    |                                    
                                    +
                                  MLS +-----+ Multi-level
                                  Gateway 3   Network


In this case, the single level systems are assumed to be non-MLS systems
which generate and expect traffic with no IPSO. The MLS gateways add
IPSO with the appropriate classification and compartments before
putting it on the WAN. They strip the IPSO before forwarding packets
to the single level networks. 

The MLS gateway 3 probably just passes the IPSO on unmodified but here
there are also cases where the IPSO could be changed to reflect differing
policies. A case in point might be where the WAN has routers that only
pass RFC1108 BSO IPSO. In that case the ESO (compartments) would be
dropped before going out on the WAN.

The WAN is assumed to be reliably authenticated, possibly encrypted, 
and physically secure data link. In IPv4 this is presumably done with
special hardware. In IPv6, hopefully, the authentication features would
come into play. The caveat here of course would be that it is unlikely
that highly classified data would be routed over the big bad Internet
but certainly some of it could be. For example, unclassified and
confidential compartmented data could perhaps be routed over the Internet
with secret and top secret data going over the protected links.

So now on to (b). I see the following cases:

  1) The endpoint systems are IPv6 security aware (but not necessarily
     MLS) and do end-to-end authentication. Here, the answer is obviously
     that the IPSO CANNOT be part of the authentication stream, since the
     MLS gateways will be adding, stripping or possibly modifying them.

     This presents a problem to the gateways in that IPSO coming from
     the WAN cannot be authenticated and cannot be used reliably for
     routing/filtering decisions.

  2) The endpoint systems use unauthenticated IPv6 (or IPv4) possibly
     with IPSO in the case of the multi-level network. In this case
     the MLS gateways would add the authentication.

       (NOTE: I am assuming that this is possible. Can someone please
              tell me if it is so?)

     In this case, if we assume the routers on the WAN do not muck
     with the IPSO, the IPSO could and probably should be part of the
     authentication stream. This gives us assurance that the IPSO is what
     it says it is, but it still has the well-known flaw of putting up the
     bright red flag that says this secured data worthy of analysis.

  3) We attempt to use the Security Association features of the 
     authentication mechanism. If the S/A is strictly end-to-end
     (is this TRUE?), then the answer is simple. The endpoint
     systems (even the single level ones in my diagram) become MLS aware
     to the extent that the S/A has an implied senstivity level. The MLS
     gateways become simple routers, since they are presumably no privy
     to the S/A and cannot make routing decisions based on the
     sensitivity level.

Number (3) provides the best security and it works for deployment of new
programs with endpoint systems that use the latest technology. Unfortunately, 
in my experience, that is rarely the case. Usually, there is a VERRRYYYY 
long lag time between program inception and actual deployment and once 
deployed it is extremely difficult to inject updates. 

I suspect that the answer will probably be encapsulation, as suggested by 
Hillarie. I am not completely sure how works in gory detail, but seems
to be the only real answer in this type of configuration.

	/andy

Xref subject previous

I've been maintaining a web page with various things on it that may be
useful, especially a cross-referenced version of the developer's mailing
list.  It looks like discussion is wandering over to the ipsec list,
so maybe I'll have to expand coverage.  Anyway, it's at

	http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html

Comments, suggestions, or additiona are welcome.

Xref subject next



Ran:

I really like the idea of an implicit security label.  The security 
association can be established for one particular security label.  
Multi-level systems simply establish multiple security associations, 
protected in different keys (and maybe different algorithms), one for each 
label.  This way, all of the overhead associated with labels falls on the 
key management protocol, not each datagram.

Russ

Xref subject previous

	 

	 Ran:

	 I really like the idea of an implicit security label.  The
	 security association can be established for one particular
	 security label.  Multi-level systems simply establish multiple
	 security associations, protected in different keys (and maybe
	 different algorithms), one for each label.  This way, all of
	 the overhead associated with labels falls on the key
	 management protocol, not each datagram.

	 Russ

That's certainly my preference as well.

Xref: Re: AH code for IPv4  Craig Metz

Hi,

We, here at USC/ISI, are working on an  IPv4 implementation of the AH and
AH-MD5 specs for the SunOS 4.1.3. Also, we are implementing some alternate 
hashing algorithms, for comparison. 

The primary purpose of our implementation is to measure the performance of 
the different algorithms. Much replication of effort could be avoided if 
someone out there has a working implentation (or parts of code thereof) 
which they are willing to share with us (keeping in mind our objective).



Thanks in advance



Avneesh Sachdev


(Research Assistant)


 

In message <199509090040.AA00908@mat.isi.edu>, asachdev@ISI.EDU writes:
>We, here at USC/ISI, are working on an  IPv4 implementation of the AH and
>AH-MD5 specs for the SunOS 4.1.3. Also, we are implementing some alternate 
>hashing algorithms, for comparison. 
>
>The primary purpose of our implementation is to measure the performance of 
>the different algorithms. Much replication of effort could be avoided if 
>someone out there has a working implentation (or parts of code thereof) 
>which they are willing to share with us (keeping in mind our objective).

	I believe that Ran put up an older version of our AH code at
ftp://ftp.nrl.navy.mil/pub/security/ipsec/ipsec-ah-fragment.c -- you might
want to grab a copy of this code and play with it. I know of a few bugs in
this code, and it's definitely not canned for end users, but it should be
a good starting point for people with BSD-like kernels (read: mbufs).

									-Craig

Xref subject next

Should the end user/application who requests the creation of an SPI with a
remote host be able to specify exact algorithms (ie. ESP with DES-CBC-32IV)
or just ESP and then the system should decide which algorithms are required
for such a communication (ie. an internal network would be safe with DES-CBC,
but i want external communications with everyone else to use 3DES-CBC) ?
-Angelos

Xref: Re: Algorithm selection granularity ?  Angelos D. Keromytis
Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
> Should the end user/application who requests the creation of an SPI with a
> remote host be able to specify exact algorithms (ie. ESP with DES-CBC-32IV)
> or just ESP and then the system should decide which algorithms are required
> for such a communication (ie. an internal network would be safe with DES-CBC,
> but i want external communications with everyone else to use 3DES-CBC) ?
>
There are quite a few ways to do this.  The best that I've seen is to
split the function.  The application specifies that it needs
authentication/encryption (for example, with a sockopt), and then the
overall policy setup configuration specifies the particular policy based
on the certificate of the peer (_NOT_ the IP address).

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

In message <1459.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>There are quite a few ways to do this.  The best that I've seen is to
>split the function.  The application specifies that it needs
>authentication/encryption (for example, with a sockopt), and then the
>overall policy setup configuration specifies the particular policy based
>on the certificate of the peer (_NOT_ the IP address).
>
That's as it should be; however, selection of the I/R transform takes
place before the certificate exchange (at least in Photuris). Do we
consider the initial I/R transforms selected by both ends as temporary
transforms to be used in an ESP/AH/whatever session to exchange certificates,
and then each party issues a KEY_CHANGE where he specifies a new I/R transform ?
I consider the current draft a bit lacking in defining the exact "user"
interface.
-Angelos

Xref: Some more Photuris questions Angelos D. Keromytis
Xref subject previous

> From: "Angelos D. Keromytis" 
> That's as it should be; however, selection of the I/R transform takes
> place before the certificate exchange (at least in Photuris). Do we
> consider the initial I/R transforms selected by both ends as temporary
> transforms to be used in an ESP/AH/whatever session to exchange certificates,
> and then each party issues a KEY_CHANGE where he specifies a new I/R transform ?

That's what I expect.  If the transform is satisfactory, then no new
transform is needed.  If not, a new transform can be added, once we have
bootstrapped using Photuris..

Actually, may not need a key_change, since the signature message can add
additional attributes, if it is only those new attributes which are needed.


> I consider the current draft a bit lacking in defining the exact "user"
> interface.
>
It's a protocol specification (bits on a wire).  We don't standardize
APIs here.

However, places where things are confusing can certainly have little
implementation hints placed strategically here and there.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Some more Photuris questions Phil Karn
Xref subject next

In message <1469.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>
>Actually, may not need a key_change, since the signature message can add
>additional attributes, if it is only those new attributes which are needed.
>
I was refering to the I/R transform we'll use...we need to notify the peer
which algorithm we'll use.

Another point i wanted to clarify is on Page 7:
	When both parties initiate Photuris key establishment concurrently,
	or one party initiates more than one Photuris session, the UDP Ports
	keep the sessions separate.

Why use the ports and not the Initiator cookie ? This sentence implies that
whenever a new Photuris session starts, a new port has to be used; why not
do all the operations from one and only port ? This doesn't have to be a
fixed port, and an implementation could actually use different ports for
different sessions, but i think the cookie should be used instead of the
local port/remote port.

Also, on Page 14, 3.3:
 An incoming cookie can be verified at any time by regenerating it locally 
 from values contained in the incoming IP datagram...

I've found that the only time you actually need to do this is when the
Responder gets a KEY_REQUEST message and needs to check the Responder Cookie;
on all other occasions, the cookies can be simply cached along with the remote
IP/port and compared directly with the cookies on the packet.

There should probably be an Authentication Failed error message ?

MDx are defined also as Signature transforms; Some shared secret value is
supposedly used for this ?

Also, while RSA/DSS transforms are specified, there's no certificate defined
for them. Is this supposed to be implementation specific or no certificates
should be used with that method ?

The draft should define the format of the DSS signature (ie. which of the r, s
comes first).

For the DSS transform, i suggest we use something similar to the exponentation
groups used for DH; some strong p, q values should be available and the remote
chooses one he supports. Therefore, the DSS attribute should be (when sent to
the peer in the transforms list)

--------------------------------------
| DSS | Size | Group1 | Group2 | ... |
--------------------------------------

When sent in the S-transform field on the SIGNATURE_MESSAGE packet, the
format should be 

----------------------
| DSS | Size | Group |
----------------------   , Size = 1, Group selected from the list of groups sent

Does anyone have code that calculates strong p, q values, according to
Schneier p.309 ?

-Angelos

PS. Is there any particular reason local address/port are included in the
cookie generation process ? I'd think the local secret random value would be
enough.

Xref: Re: Some more Photuris questions  Angelos D. Keromytis
Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
> I was refering to the I/R transform we'll use...we need to notify the peer
> which algorithm we'll use.
>
I do not understand.  The I/R transform used is for the signature step.
The peer is notified in the key exchange step.


> Another point i wanted to clarify is on Page 7:
> 	When both parties initiate Photuris key establishment concurrently,
> 	or one party initiates more than one Photuris session, the UDP Ports
> 	keep the sessions separate.
>
> Why use the ports and not the Initiator cookie ? This sentence implies that
> whenever a new Photuris session starts, a new port has to be used; why not
> do all the operations from one and only port ? This doesn't have to be a
> fixed port, and an implementation could actually use different ports for
> different sessions, but i think the cookie should be used instead of the
> local port/remote port.
>
Very simply because that is not the way that UDP works.  We have chosen
to use UDP for Photuris.  There was discussion about making Photuris
another IP transport-level Protocol, but that was rejected some time ago.


> Also, on Page 14, 3.3:
>  An incoming cookie can be verified at any time by regenerating it locally
>  from values contained in the incoming IP datagram...
>
> I've found that the only time you actually need to do this is when the
> Responder gets a KEY_REQUEST message and needs to check the Responder Cookie;
> on all other occasions, the cookies can be simply cached along with the remote
> IP/port and compared directly with the cookies on the packet.
>
Nope.  The cookie "secret" is supposed to change on a regular basis,
whenever the public-key changes.  Otherwise, you'd have to keep around
the secrets, generator, public-value, private-value, etc, for long
periods of time, which violates perfect forward secrecy.

Check the cookies on every incoming message.


> There should probably be an Authentication Failed error message ?
>
Do you mean Signature?  Yes, it was mentioned in the text, but I forgot
to assign an error message number.  Fixed.


> MDx are defined also as Signature transforms; Some shared secret value is
> supposedly used for this ?
>
Yes.  In fact, that's how initial testing has been done.  Someday, we'll
have PGP or DNS-SIG working, but not yet.


> Also, while RSA/DSS transforms are specified, there's no certificate defined
> for them. Is this supposed to be implementation specific or no certificates
> should be used with that method ?
>
Actually, somebody _else_ needs to define them, in separate documents....

I just reserved some numbers for them (and for lots of others).  I won't
be documenting them if they aren't required to be supported in the
initial implementation.

It is likely that we will choose either PGP, DNS-SIG, or both as
required to be supported.


> PS. Is there any particular reason local address/port are included in the
> cookie generation process ?
>
Yes, to prevent attackers on the same MLS machine.  Obscure.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

	 Very simply because that is not the way that UDP works.  We
	 have chosen to use UDP for Photuris.  There was discussion
	 about making Photuris another IP transport-level Protocol, but
	 that was rejected some time ago.

The more I think about it, the less happy I am about using UDP, for
several reasons.

First, of course, UDP is a very poor match for firewall, and IPSEC
will do little to obviate the need for such.  Even if you don't like
firewalls -- and I'd rather not debate that here -- it will slow down
the deployment of Photuris (and hence IPSEC) if today's end systems
cannot negotiate an end-to-end key.  (There are other conflicts between
IPSEC and firewalls, but let's eliminate the easy ones first.)

Second, Photuris requires that a lot of state be kept lying around.
I don't like explicit state table lookups; they tend to be buggy.

Third, I am not persuaded by the purported immunity of UDP-based
services to certain denial of service attacks.  Any eavesdropper on
the wire can spoof the cookie -- and if there are no eavesdroppers,
we don't need ESP...

Xref subject previous
Xref subject next

In message <1484.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>I do not understand.  The I/R transform used is for the signature step.
>The peer is notified in the key exchange step.
>
The first I/R transform used is at the KEY_REQUEST, KEY_RESPONSE packets and
that one is used during for the signature. If one of the parties then decides
that the transform selected is not good enough for communication, based on the
remote's certificate, he'll have to notify the remote of the new I/R transform
he'll use, and this can only be done by a KEY_CHANGE.

>Very simply because that is not the way that UDP works.  We have chosen
>to use UDP for Photuris.  There was discussion about making Photuris
>another IP transport-level Protocol, but that was rejected some time ago.
>
Actually, my argument is why does the *local* port/address have to be in there ?
You can use the remote address/port and the Initiator cookie. This saves you
the trouble of using a new port for a new session.

>Nope.  The cookie "secret" is supposed to change on a regular basis,
>whenever the public-key changes.  Otherwise, you'd have to keep around
>the secrets, generator, public-value, private-value, etc, for long
>periods of time, which violates perfect forward secrecy.
>
>Check the cookies on every incoming message.
>
No, no. I *do* check the cookies on every incoming message. The thing is,
while a session is in progress, you don't have to cache the secret value
you used for creating the cookie but the cookie itself. I don't see how
this violates pfs.

>Do you mean Signature?  Yes, it was mentioned in the text, but I forgot
>to assign an error message number.  Fixed.

Yes, but it could refer to an unacceptable certificate, as opposed to a failure
to verify a signature.

>It is likely that we will choose either PGP, DNS-SIG, or both as
>required to be supported.
>
Well, seeing as there is already one set of S transforms with no certificates
(MDx/SHA), i suggest we use RSA/DSS without certificates as well, as an
intermediate step between MDx signatures and DNS-SIG certificates.

>Yes, to prevent attackers on the same MLS machine.  Obscure.

But on systems with more than one interface, which local address do you use ?
You probably don't know ove which interface your packets will be routed. How
did you solve this ? Also, how did you enforce UDP checksums (Page 8, 2.1) ?
-Angelos

Xref subject previous
Xref subject next

> From: smb@research.att.com
> The more I think about it, the less happy I am about using UDP, for
> several reasons.
>
We already debated all the reasons you give.  This is not the design
debate list, this is the implementation list.


> First, of course, UDP is a very poor match for firewall, and IPSEC
> will do little to obviate the need for such.  Even if you don't like
> firewalls -- and I'd rather not debate that here -- it will slow down
> the deployment of Photuris (and hence IPSEC) if today's end systems
> cannot negotiate an end-to-end key.  (There are other conflicts between
> IPSEC and firewalls, but let's eliminate the easy ones first.)
>
I completely disagree with everything you say here.  If you can't
correctly configure your firewalls to pass UDP ports, you have a lot
more problems than just Photuris.  Try another vendor.


> Second, Photuris requires that a lot of state be kept lying around.
> I don't like explicit state table lookups; they tend to be buggy.
>
I have no idea what "a lot of state" is that you refer to.  That might
be an implementation note appropriate to this list, but hard to say with
so little detail.  Phil was always concerned with keeping state to a
minimum.

You are speaking from your Photuris implementation experience?


> Third, I am not persuaded by the purported immunity of UDP-based
> services to certain denial of service attacks.  Any eavesdropper on
> the wire can spoof the cookie -- and if there are no eavesdroppers,
> we don't need ESP...
>
It bears repeating that while this is true, most attacks are from folks
_not_ on the wire.  Since this solves 90% of the problems, it is pretty
specious to argue not to have it because it doesn't universally solve
_all_ problems.  Shades of Perfect Security Research Group....

If you have a more robust and universal idea, please share it with us
(on the ipsec list).

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Since the MDx attributes will be included everywhere, i think every
implementation should support signatures using them. Should the draft
make them a requirement ?
-Angelos

Xref: Re: Some more Photuris questions  Angelos D. Keromytis
Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
>
> The first I/R transform used is at the KEY_REQUEST, KEY_RESPONSE packets and
> that one is used during for the signature. If one of the parties then decides
> that the transform selected is not good enough for communication, based on the
> remote's certificate, he'll have to notify the remote of the new I/R transform
> he'll use, and this can only be done by a KEY_CHANGE.
>
That's not a principle use of a certificate, but if you implement it
that way, I suppose you could go to all that trouble....  Why bother?

Are you really putting all of this policy in your implementation?  You
must be much farther along than the rest of us!  When will you be ready
for interoperability testing?

Let's do ESP DES-CBC testing first.  Tell us the IP address and key to use.


> Actually, my argument is why does the *local* port/address have to be in there ?
> You can use the remote address/port and the Initiator cookie. This saves you
> the trouble of using a new port for a new session.
>
Huh?  How exactly do your sockets work?

The usual "well-known-port" technique is a new port for each new session.

You have to demultiplex somehow, and it seems to me a 2-byte comparison
is a heck of a lot easier than a 16-byte comparison.

Particularly when the OS takes care of it for you!


> >Nope.  The cookie "secret" is supposed to change on a regular basis,
> >whenever the public-key changes.  Otherwise, you'd have to keep around
> >the secrets, generator, public-value, private-value, etc, for long
> >periods of time, which violates perfect forward secrecy.
> >
> >Check the cookies on every incoming message.
> >
> No, no. I *do* check the cookies on every incoming message. The thing is,
> while a session is in progress, you don't have to cache the secret value
> you used for creating the cookie but the cookie itself. I don't see how
> this violates pfs.
>
Huh?  You SHOULD NOT be "caching" the secret value!

You would have to cache all of the other things related to the secret
then, for longer periods of time than the life of the public value.
That's the violation!


> Yes, but it could refer to an unacceptable certificate, as opposed to a failure
> to verify a signature.
>
What's the difference?  If it fails, it fails!  Just like not telling
whether a login name or the password is invalid, you want to give away
as little detail as possible!


> Well, seeing as there is already one set of S transforms with no certificates
> (MDx/SHA), i suggest we use RSA/DSS without certificates as well, as an
> intermediate step between MDx signatures and DNS-SIG certificates.
>
The intermediate step is PGP.  There is already a standard for RSA.
There is already yet another standard for DSS certificates.

Are you really implementing all of them?  Again, you must be much
farther along than anyone else.  What's the IP address to test against
using PGP?

Could you send this list your PGP certificate, please.  It doesn't seem
to be in the world database.


> >Yes, to prevent attackers on the same MLS machine.  Obscure.
>
> But on systems with more than one interface, which local address do you use ?
> You probably don't know ove which interface your packets will be routed. How
> did you solve this ? Also, how did you enforce UDP checksums (Page 8, 2.1) ?
>
You don't?  I thought you were working on NetBSD?

I know which interface _my_ packets will be routed, and I have turned on
UDP checksums.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Some more Photuris questions Phil Karn
Xref subject previous
Xref subject next

In message <1504.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>That's not a principle use of a certificate, but if you implement it
>that way, I suppose you could go to all that trouble....  Why bother?
>
Now you really got me confused...didn't you suggest to use the certificate
to decide on a policy ?

>Are you really putting all of this policy in your implementation?  You
>must be much farther along than the rest of us!  When will you be ready
>for interoperability testing?
>
I thought i was ready; however, i have implemented RSA signatures with no
certificates; tell me the format of the MD5 signatures you use (which fields
you hash and in what order) and i'll have it set; i asked Phil about
interop tests, he said he has to bring his implementation up to date.

>Let's do ESP DES-CBC testing first.  Tell us the IP address and key to use.

What exactly do you mean by ESP DES-CBC testing ? I don't have any IPSP code;
i only wrote a Photuris implementation...we can run it and derive
keys/transforms and authenticate.

>
>Huh?  How exactly do your sockets work?
>
>The usual "well-known-port" technique is a new port for each new session.
>
>You have to demultiplex somehow, and it seems to me a 2-byte comparison
>is a heck of a lot easier than a 16-byte comparison.
>
>Particularly when the OS takes care of it for you!
>
That's true, but i find it easier to just bind to all known interfaces and use
a single socket for all communications, than bind to each particular interface.
And it's not a 2-byte, it's a 6-byte comparison (address included, right ?).
The thing is, when you create a cookie on a multi-interface host, you don't know
over which interface the response packets will come (and you won't know over
which interface to send your packets in the first place, but i let's suppose
standard Internet routing takes care of that).

>Huh?  You SHOULD NOT be "caching" the secret value!
>
>You would have to cache all of the other things related to the secret
>then, for longer periods of time than the life of the public value.
>That's the violation!
>
To my understanding, the Initiator cookie has to change each time you start
new session with the same host; if you use the same secret value for all cookies
as Initiator, this won't happen (not if you don't use a new port for each
session, like i do). This mean you have create a secret value for the new
session; and, naturally, you'd have to cache it, to process future requests.
Well, i just cache the cookie, instead of the secret value.

>What's the difference?  If it fails, it fails!  Just like not telling
>whether a login name or the password is invalid, you want to give away
>as little detail as possible!
>
I can see a few situations where the distinction would matter, but i'll agree
with giving as few detail as possible.

>The intermediate step is PGP.  There is already a standard for RSA.
>There is already yet another standard for DSS certificates.
>
Err, didn't you say in your previous mail that a draft has to be writen
for them ?

>Are you really implementing all of them?  Again, you must be much
>farther along than anyone else.  What's the IP address to test against
>using PGP?
>
Yes. I have RSA, and i'm halfway through DSS right now (as soon as i find the
time to write code to create strong p, q values). Unfortunately, i didn't start
using PGP certificates; it's in my todo list, but i don't see it coming RSN,
unless i convince myself to write code to handle PGP packets; i don't trust
the PGPtool stability, and i don't want to fiddle with the PGP code at all.
What did you use ?

>Could you send this list your PGP certificate, please.  It doesn't seem
>to be in the world database.
>
It's not ? It should be.
Anyway, you mean this ?
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

mQCNAi1SNpMAAAEEAK6TIbNYkNxNewYYCrWZ9fYs/LOiMXDe8iW7L4ZlxMutlz9f
4sItHwIkTDSNJMiavqW2KppSxRjQXr3XBjpOx188VEud6jvtJiyeM5uFhcqrGZSq
IMh5V4RI6b0kj3ormAEoCd1my3hxcP7zxLeQkUYuIp7wgZ/3B70pBjh2h1kFAAUR
tClBbmdlbG9zIEQuIEtlcm9teXRpcyA8a2VybWl0QGZvcnRobmV0LmdyPokAlQIF
EDAyQarPgNGHLT7q1QEBrPgD/RyPELMLIDDOPphgZh33GX0/cJqpyQy9Pf2vq5RM
KjCmHRtLJByATwaciZj8+9ZQp7vwG2rFQklDSwz3EfCMha9YCgh4sMXIRu7tHLnc
f3At2YiXywzJsHE4j7lKw/oUp4wRkJxBuYdpg/YDNo7KgXAbEYA2lDkFjD4E/Y3H
eERytCpBbmdlbG9zIEQuIEtlcm9teXRpcyA8a2VybWl0QGljcy5mb3J0aC5ncj60
KEFuZ2Vsb3MgRC4gS2Vyb215dGlzIDxrZXJtaXRAZWR1LnVjaC5ncj60KEFuZ2Vs
b3MgRC4gS2Vyb215dGlzIDxrZXJtaXRAY3NkLnVjaC5ncj4=
=n5AO
-----END PGP PUBLIC KEY BLOCK-----

>
>You don't?  I thought you were working on NetBSD?
>
SunOS 4.1.4 right now. Sorry, that's what i have available for the moment.
Besides, i didn't mean how someone turns on UDP checksums...i meant how can
*i* enforce it, from my implementation, since that's what i understood by
reading the draft.

>I know which interface _my_ packets will be routed, and I have turned on
>UDP checksums.
>
Care to explain to me how you know that ? You call the routing algorithm
directly ? I'd think this would make the session a bit unstable; not a big
loss there, since we can always drop it and start a new one, but still...
-Angelos

PS. There might be a "fast and dirty" way out of the MDx problems (decide
whether it's S, K or I/R or any combination); just add a value field in it
(1 byte would be enough), where there are OR'ed the values K_TRANS, S_TRANS,
IR_TRANS; thus someone can indicate which uses of an MDx transform he supports.
How does it sound ? It's just a minor modification IMO.

Xref: Re: Some more Photuris questions  Angelos D. Keromytis
Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
> I thought i was ready; however, i have implemented RSA signatures with no
> certificates; tell me the format of the MD5 signatures you use (which fields
> you hash and in what order) and i'll have it set; i asked Phil about
> interop tests, he said he has to bring his implementation up to date.
>
Yeah, he's several packet format versions behind.  Waited until it was
stable.  Sensible.

I'll post the draft with MD5 signature formats soon.  It's really simple.


> >Let's do ESP DES-CBC testing first.  Tell us the IP address and key to use.
>
> What exactly do you mean by ESP DES-CBC testing ? I don't have any IPSP code;
> i only wrote a Photuris implementation...we can run it and derive
> keys/transforms and authenticate.
>
WHAT?!?  The signature phase _REQUIRES_ IP Security.  It says so (p 23):
   ...
   Signature_Message to the Responder.  This message is required to be
   authenticated or encrypted, using the R-SPI Transform indicated in
   the Key_Response.
   ...
   sends a Signature_Message to the Initiator.  This message is required
   to be authenticated or encrypted, using the I-SPI Transform indicated
   in the Key_Request.

No wonder you are so far ahead!  You're working on the easy stuff first!
Well, I suppose it is good experience, and you certainly have been
enthusiastic in your feedback.

But no wonder your thought you needed to split K-tranforms and
I/R-transforms.  Sorry, for the rest of us IP-SEC comes first.


> >Particularly when the OS takes care of it for you!
> >
> That's true, but i find it easier to just bind to all known interfaces and use
> a single socket for all communications, than bind to each particular interface.

Blech!

> And it's not a 2-byte, it's a 6-byte comparison (address included, right ?).
> The thing is, when you create a cookie on a multi-interface host, you don't know
> over which interface the response packets will come (and you won't know over
> which interface to send your packets in the first place, but i let's suppose
> standard Internet routing takes care of that).
>
I just don't understand what you are talking about.  It sounds like you
are taking some shortcuts....


> To my understanding, the Initiator cookie has to change each time you start
> new session with the same host;

Yes.

> if you use the same secret value for all cookies
> as Initiator, this won't happen (not if you don't use a new port for each
> session, like i do).

the socket handler will have a damn difficult time feeding the packets to
the right UDP socket and user process.


> This mean you have create a secret value for the new
> session; and, naturally, you'd have to cache it, to process future requests.
> Well, i just cache the cookie, instead of the secret value.
>
Oh, that's for the Initiator.  Since it is implemented as a user
process, saving the initiator's secret value _is_ just like saving the
cookie itself, since it won't change.  No biggy, just an array.

The responder is the process for which checking the current secret (by
which I mean the one coupled to the public-value) and recalculating is
important, since it doesn't save state.


> >The intermediate step is PGP.  There is already a standard for RSA.
> >There is already yet another standard for DSS certificates.
> >
> Err, didn't you say in your previous mail that a draft has to be writen
> for them ?
>
Somebody does.  It's not me....

I think you are wasting your time there, too few people do straight RSA.
And I was talking to RSA yesterday, and they are doing X.509 version 3.
Sent me some text to include in the next draft, too!


> SunOS 4.1.4 right now. Sorry, that's what i have available for the moment.
> Besides, i didn't mean how someone turns on UDP checksums...i meant how can
> *i* enforce it, from my implementation, since that's what i understood by
> reading the draft.
>
I've never programmed for SunOS, but I think you'll have to turn it on
for the whole machine, and then check that it's not zero before
accepting it.


> Care to explain to me how you know that ? You call the routing algorithm
> directly ? I'd think this would make the session a bit unstable; not a big
> loss there, since we can always drop it and start a new one, but still...

What is this predilection for interface?  Just use the OS socket calls,
it fills in the address.  It isn't unstable, the address stays the same
once it is in the socket, doesn't it?  How would TCP even function
otherwise?

Maybe you aren't using sockets?  I'm not sure what they use in SunOS.


> PS. There might be a "fast and dirty" way out of the MDx problems (decide
> whether it's S, K or I/R or any combination);

No need, you were confused.  If you implement MD5 at all, you have to do
_all_ the functions.

Can somebody help this guy out on the SunOS stuff?  We've got to get him
doing at least AH-MD5, or he won't be able to talk to anybody....

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Some more Photuris questions Phil Karn
Xref subject previous
Xref subject next

In message <1509.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>
>No wonder you are so far ahead!  You're working on the easy stuff first!
>
Yeap. Actually, i was supposed to work on an IPSP implementation with Perry,
but he thought it'd be better if i wrote an implementation of Photuris. I'll
probably start working on IPSP itself soon.

>I just don't understand what you are talking about.  It sounds like you
>are taking some shortcuts....
>
Forget it. I'll just do what the draft says, even though there are shortcuts.

>Oh, that's for the Initiator.  Since it is implemented as a user
>process, saving the initiator's secret value _is_ just like saving the
>cookie itself, since it won't change.  No biggy, just an array.
>
Sorry, i was refering to the Initiator but looks like i didn't make myself
clear on that. However, the Responder can just as well cache the Responder
cookie (after he creates state).

>I think you are wasting your time there, too few people do straight RSA.

I wanted to see the delay of the whole process, so i had even made a simple
certificate and ran several sessions (20 at the same time) between the same
two hosts.

>I've never programmed for SunOS, but I think you'll have to turn it on
>for the whole machine, and then check that it's not zero before
>accepting it.
>
To my knowledge, there's no way to do that from userland; maybe patching the
kernel run time...there are more OSes than not that don't allow the user to
turn UDP checksums on/off...we have to take under consideration those as well.
On the other hand, it might be a good way to force vendors to support such
operations :)

>What is this predilection for interface?  Just use the OS socket calls,
>it fills in the address.  It isn't unstable, the address stays the same
>once it is in the socket, doesn't it?  How would TCP even function
>otherwise?
>
>Maybe you aren't using sockets?  I'm not sure what they use in SunOS.
>
Sockets alright...
Just what local address you're using on a multi-interface host for
cookie creation.

>
>No need, you were confused.  If you implement MD5 at all, you have to do
>_all_ the functions.
>
Fine. It just wasn't clear in the draft.
-Angelos

Xref subject previous
Xref subject next

>The thing is, when you create a cookie on a multi-interface host, you don't know
>over which interface the response packets will come (and you won't know over
>which interface to send your packets in the first place, but i let's suppose
>standard Internet routing takes care of that).

Hmm, this could be a problem. Years ago I solved it in KA9Q NOS by adding
a function to the API that tells you which interface will be used to reach
a given destination, and thereby the local IP address. Does anything
analogous exist in newer UNIX variants?

Phil

Xref subject previous
Xref subject next

	 >The thing is, when you create a cookie on a multi-interface host, you
	 don't know
	 >over which interface the response packets will come (and you won't kn
	ow over
	 >which interface to send your packets in the first place, but i let's 
	suppose
	 >standard Internet routing takes care of that).

	 Hmm, this could be a problem. Years ago I solved it in KA9Q NOS by add
	ing
	 a function to the API that tells you which interface will be used to r
	each
	 a given destination, and thereby the local IP address. Does anything
	 analogous exist in newer UNIX variants?

You can create sockets for all local interfaces, and use the ``right'' one.
That will ensure that the proper source address is used.  It won't, however,
say anything about which physical interface packets will be sent to or
received from.

There is a setsockopt() call to prevent packets from being routed, but
that doesn't do anything useful here, I believe.

Xref subject previous
Xref subject next

>To my knowledge, there's no way to do that from userland; maybe patching the
>kernel run time...there are more OSes than not that don't allow the user to
>turn UDP checksums on/off...we have to take under consideration those as well.
>On the other hand, it might be a good way to force vendors to support such
>operations :)

Perhaps we should just drop the language about requiring UDP
checksums.  Make it a SHOULD. There's plenty of redundancy in the
actual packets that would detect most errors. After all, they're
designed to protect against active modification attacks, and humans
are usually a lot more malicious and cunning than mother nature...

Phil

Xref subject previous
Xref subject next

In message <199509190002.DAA16358@info.forthnet.gr>, smb@research.att.com write
s:
>	 Hmm, this could be a problem. Years ago I solved it in KA9Q NOS by add
>	ing
>	 a function to the API that tells you which interface will be used to r
>	each
>	 a given destination, and thereby the local IP address. Does anything
>	 analogous exist in newer UNIX variants?
>
No such function that i know of.

>You can create sockets for all local interfaces, and use the ``right'' one.
>That will ensure that the proper source address is used.  It won't, however,
>say anything about which physical interface packets will be sent to or
>received from.
>
The problem is how you find out which is the "right" one. A simple solution
then is to use all local addresses in the cookie creation; another is to "ping"
the remote by sending a UDP packet to its echo port, and see which local
interface you get the response on, but i can see some potential for misuse on
this. Yet a third solution is just to send it over some interface and pray.
Not being a religious type of person, i'd prefer the first solution, unless
we can come up with something better.
-Angelos

Xref: Re: Some more Photuris questions  Perry E. Metzger
Xref: Re: Some more Photuris questions  Angelos D. Keromytis
Xref subject previous
Xref subject next

>	When both parties initiate Photuris key establishment concurrently,
>	or one party initiates more than one Photuris session, the UDP Ports
>	keep the sessions separate.

>Why use the ports and not the Initiator cookie ? This sentence implies that
>whenever a new Photuris session starts, a new port has to be used; why not
>do all the operations from one and only port ? This doesn't have to be a
>fixed port, and an implementation could actually use different ports for
>different sessions, but i think the cookie should be used instead of the
>local port/remote port.

Well, given the demuxing provided by most UDP implementations, if you
want to allow several instances of the Photuris initiator running at
the same time you'd best give them separate UDP source ports. You
can't have two processes bind to the same local port.

>I've found that the only time you actually need to do this is when the
>Responder gets a KEY_REQUEST message and needs to check the Responder Cookie;
>on all other occasions, the cookies can be simply cached along with the remote
>IP/port and compared directly with the cookies on the packet.

This is quite true, and it should be an implementation note in the spec.

>Does anyone have code that calculates strong p, q values, according to
>Schneier p.309 ?

Yes. I posted it some time (>1 yr) ago to the net. I guess I should add it
to my web page.

>PS. Is there any particular reason local address/port are included in the
>cookie generation process ? I'd think the local secret random value would be
>enough.

To keep an attacker from obtaining a valid cookie with a real IP address,
and then use it in a swamping attack from a variety of bogus IP addresses.

Phil

Xref: Re: Some more Photuris questions Phil Karn
Xref subject previous
Xref subject next


Phil Karn writes:
> Well, given the demuxing provided by most UDP implementations, if you
> want to allow several instances of the Photuris initiator running at
> the same time you'd best give them separate UDP source ports. You
> can't have two processes bind to the same local port.

Thats true, but personally, I'd prefer to just have one Photuris
daemon running on all my machines. Its easy enough to do -- you only
run one copy of Bind, for instance.

> >PS. Is there any particular reason local address/port are included in the
> >cookie generation process ? I'd think the local secret random value would be
> >enough.
> 
> To keep an attacker from obtaining a valid cookie with a real IP address,
> and then use it in a swamping attack from a variety of bogus IP addresses.

Now I'm confused -- I don't understand why the local address and port
are in the cookie generation; stopping swamping would work if you
included the remote address, wouldn't it? Perhaps we are swapping
"local" and "remote" in our terminology.

Perry

Xref: Re: Some more Photuris questions Tatu Ylonen
Xref: Re: Some more Photuris questions  Angelos D. Keromytis
Xref subject previous
Xref subject next

>Thats true, but personally, I'd prefer to just have one Photuris
>daemon running on all my machines. Its easy enough to do -- you only
>run one copy of Bind, for instance.

That's your choice, of course. Allowing any UDP source port covers the
general case.

>Now I'm confused -- I don't understand why the local address and port
>are in the cookie generation; stopping swamping would work if you

Oops, my fault. I was thinking about the remote IP address. I guess
you're right -- there's no particular reason to include the local
port and IP address, though it wouldn't hurt. This all falls into the
category of an implementation detail anyway.

Phil

Xref: Re: Some more Photuris questions Phil Karn
Xref subject previous
Xref subject next

> Oops, my fault. I was thinking about the remote IP address. I guess
> you're right -- there's no particular reason to include the local
> port and IP address, though it wouldn't hurt. This all falls into the
> category of an implementation detail anyway.

One issue is determining whether the remote host supports Photuris or
not - for a long time some hosts on the network will and some won't.

If you use UDP, you can get a notification (port unreachable) if the
recipient does not know about Photuris.  You can use this to
automatically revert to non-secure IP for such hosts (if the local
policy permits - and I believe this would be the case for the majority
of hosts on the internet).

If you use raw IP with unknown protocol, as far as I understand the
packet will just be dropped by the receiver, and you have no way of
determining whether the remote host supports Photuris, except by
waiting for a timeout and retrying a few times.  This is too slow to
be practical.

    Tatu Ylonen 

Xref subject previous
Xref subject next

In message <199509210418.VAA03446@servo.qualcomm.com>, Phil Karn writes:
>Well, given the demuxing provided by most UDP implementations, if you
>want to allow several instances of the Photuris initiator running at
>the same time you'd best give them separate UDP source ports. You
>can't have two processes bind to the same local port.
>
In my implementation, i have a daemon which is signalled to initiate an
exchange; i understand you have something like a library call which is
used from each program that wants to initiate a session ?

>>PS. Is there any particular reason local address/port are included in the
>>cookie generation process ? I'd think the local secret random value would be
>>enough.
>
>To keep an attacker from obtaining a valid cookie with a real IP address,
>and then use it in a swamping attack from a variety of bogus IP addresses.
>
But the remote (attacker's) IP address/port are included in the cookie
generation process; if he uses a different IP address, the cookie simply won't
be the same. Unless i completely misunderstood your statement, i don't see how
the local (our) address/port are going to help towards that end.
-Angelos

Xref subject previous
Xref subject next

In message <199509210628.XAA03706@servo.qualcomm.com>, Phil Karn writes:
>
>That's your choice, of course. Allowing any UDP source port covers the
>general case.
>
True enough, but assuming i'm using the same port to send all requests
(468), then two parallel Photuris sessions with the same host would result
in the same address/port pairs (468<->468); all i'm saying is that the cookie
should probably be used to separate the sessions, not the local port/address.

>Oops, my fault. I was thinking about the remote IP address. I guess
>you're right -- there's no particular reason to include the local
>port and IP address, though it wouldn't hurt. This all falls into the
>category of an implementation detail anyway.
>
Again, on multi-interface hosts, you don't know which local address you're
using; so either you use every local address or none (or you process the
routing table yourself).
-Angelos

Xref: Re: Some more Photuris questions Tatu Ylonen
Xref subject previous
Xref subject next

>If you use raw IP with unknown protocol, as far as I understand the
>packet will just be dropped by the receiver, and you have no way of

No, in that case the receiver should respond with an ICMP Protocol Unreachable.

Phil

Xref subject previous

> >If you use raw IP with unknown protocol, as far as I understand the
> >packet will just be dropped by the receiver, and you have no way of
> 
> No, in that case the receiver should respond with an ICMP Protocol 
> Unreachable.

In the FreeBSD kernel the symbol ICMP_UNREACH_PROTOCOL appears in the
following two places:

netinet/ip_icmp.c:                      case ICMP_UNREACH_PROTOCOL:
netinet/ip_icmp.h:#define               ICMP_UNREACH_PROTOCOL   2              /* bad protocol */

I cannot find code that would ever *send* ICMP_UNREACH_PROTOCOL.
ip_input passes unknown protocols to rip_input, which drops the packet
if there is no appropriate raw ip socket to receive it.

Unless there is some user-level daemon (which I am not aware of),
FreeBSD does *not* send ICMP Protocol Unreachables.  I would suspect
that many other systems based on the BSD stack also exhibit the same
behavior.  This might mean that there is a huge installed base of
systems that don't send it, regardless of what they are supposed to do.

    Tatu

Xref subject next

Hi. I've generated a 2047-bit "strong" prime number that I would like to
use with Diffie-Hellman key exchange. I assert that not only is this number
'p' prime, but so is (p-1)/2.

I've used the mpz_probab_prime() function in the Gnu Math Package (GMP) version
1.3.2 to test this number. This function uses the Miller-Rabin primality test.
However, to increase my confidence that this number really is a strong prime,
I'd like to ask others to confirm it with other tests. Here's the number in hex:

72a925f760b2f954ed287f1b0953f3e6aef92e456172f9fe86fdd8822241b9c9788fbc289982743e
fbcd2ccf062b242d7a567ba8bbb40d79bca7b8e0b6c05f835a5b938d985816bc648985adcff5402a
a76756b36c845a840a1d059ce02707e19cf47af0b5a882f32315c19d1b86a56c5389c5e9bee16b65
fde7b1a8d74a7675de9b707d4c5a4633c0290c95ff30a605aeb7ae864ff48370f13cf01d49adb9f2
3d19a439f753ee7703cf342d87f431105c843c78ca4df639931f3458fae8a94d1687e99a76ed99d0
ba87189f42fd31ad8262c54a8cf5914ae6c28c540d714a5f6087a171fb74f4814c6f968d72386ef3
56a05180c3bec7ddd5ef6fe76b1f717b

The generator, g, for this prime is 2.

Thanks!

Phil Karn

Xref subject previous

While you folks are poking at Phil's latest, perhaps you could verify the
others that he generated, already in the Photuris internet-draft:

A 1024-bit strong prime (p), expressed in hex:

97f6 4261 cab5 05dd 2828 e13f 1d68 b6d3
dbd0 f313 047f 40e8 56da 58cb 13b8 a1bf
2b78 3a4c 6d59 d5f9 2afc 6cff 3d69 3f78
b23d 4f31 60a9 502e 3efa f7ab 5e1a d5a6
5e55 4313 828d a83b 9ff2 d941 dee9 5689
fada ea09 36ad df19 71fe 635b 20af 4703
6460 3c2d e059 f54b 650a d8fa 0cf7 0121
c747 99d7 5871 32be 9b99 9bb9 b787 e8ab

The recommended generator (g) for this prime is 2.


A 1024-bit strong prime (p), expressed in hex:

a478 8e21 84b8 d68b fe02 690e 4dbe 485b
17a8 0bc5 f21d 680f 1a84 1313 9734 f7f2
b0db 4e25 3750 018a ad9e 86d4 9b60 04bb
bcf0 51f5 2fcb 66d0 c5fc a63f bfe6 3417
3485 bbbf 7642 e9df 9c74 b85b 6855 e942
13b8 c2d8 9162 abef f434 2435 0e96 be41
edd4 2de9 9a69 6163 8c1d ac59 8bc9 0da0
69b5 0c41 4d8e b865 2adc ff4a 270d 567f

The recommended generator (g) for this prime is 5.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

In the new draft, contrary to the old one, each party tells the other which
key transform to use to calculate the session key for each direction ? If so,
which direction's session key does this transform calculate ? Am i correct
to assume it follows the direction of privacy transform determination (ie.
the one who selects a privacy transform for a direction selects the key
transform for creating the key for that direction) ?
Or the Responder simply copies the K-transform from the SIGNATURE_MESSAGE it
receives to the SIGNATURE_MESSAGE it sends back to the Initiator ?
-Angelos

Xref subject previous

> From: "Angelos D. Keromytis" 
> In the new draft, contrary to the old one, each party tells the other which
> key transform to use to calculate the session key for each direction ? If so,
> which direction's session key does this transform calculate ? Am i correct
> to assume it follows the direction of privacy transform determination (ie.
> the one who selects a privacy transform for a direction selects the key
> transform for creating the key for that direction) ?

Yes.  It's yet another SPI attribute just like the SPI, LifeTime,
Transforms, etc.

This was requested so that different amounts of key bits could be
calculated in each direction when one direction uses a stronger
transform.  We aim to please, even though Photuris just keeps getting
more and more featuritus....


> Or the Responder simply copies the K-transform from the SIGNATURE_MESSAGE it
> receives to the SIGNATURE_MESSAGE it sends back to the Initiator ?
>
No!  (It would have said "Copied from ...")

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject next

Since we've come down to allowing different K-transforms for each direction,
i don't see why we shouldn't allow different anonymity transforms as well; it
would only mean moving the anonymity choice field from the KEY_RESPONSE packet
to the SIGNATURE_MESSAGE packet; a minor modification really.
-Angelos

Xref: Re: Privacy attribute  Angelos D. Keromytis
Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
> Since we've come down to allowing different K-transforms for each direction,
> i don't see why we shouldn't allow different anonymity transforms as well; it
> would only mean moving the anonymity choice field from the KEY_RESPONSE packet
> to the SIGNATURE_MESSAGE packet; a minor modification really.
>
Actually, I thought about that, as well as adding a separate anonymity
key generator.  That would really be general....  But there are a number
of problems with doing that.

Note that the encryption policy is chosen, not by the Initiator
(potential attacker), but by the Responder.  That seems the more prudent
approach.  Each specifying their own is asking too much.

The Signature_Message itself is encrypted, can't keep the algorithm
pointer _inside_ the encrypted data.  So, it would have to be outside.
But there is no space in the standard format, so would need to move the
fields down 64 more bits to maintain alignment.  Ugly.

And after all, it seems to me that Photuris is getting over laden with
options.  What level of flexibility are we gaining by adding even more
for the simple rarely executed step of anonymity?  This combination of
key generator and encryption would be duplicated from AH and ESP in
Photuris, making it ever bigger.

I decided that it would be better to keep the Photuris anonymity code
simpler, with only a few legal combinations of key generator and
encryption.  Enough folks think it is excessive as it is.

"A foolish consistency ...."

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

In message <1630.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>
>Note that the encryption policy is chosen, not by the Initiator
>(potential attacker), but by the Responder.  That seems the more prudent
>approach.  Each specifying their own is asking too much.
>
The purpose of the anonymity transform is to hide the identity of the
party sending the SIGNATURE_MESSAGE (hide the certificate) and either the
Initiator or the Responder might want to remain anonymous. Trusting the
Responder to select the algorithm when (in most cases) it is the Initiator
that wishes to remain anonymous just doesn't sound good to me. And of course
we might have an anonymous service provider, so we can't just let the
Initiator pick the algorithm.

>The Signature_Message itself is encrypted, can't keep the algorithm
>pointer _inside_ the encrypted data.  So, it would have to be outside.
>But there is no space in the standard format, so would need to move the
>fields down 64 more bits to maintain alignment.  Ugly.
>
This holds only as long as the privacy transform selected does not have
any value fields (ie. is only 2 bytes). If, say, RC5 was selected, the
alignment would be off anyway (assuming the signature and the certificate
and the K-transform don't throw it off alignment anyway). Sorry, i don't
think this is a strong argument.

>And after all, it seems to me that Photuris is getting over laden with
>options.  What level of flexibility are we gaining by adding even more
>for the simple rarely executed step of anonymity?  This combination of

If we're going to do it, let's do it right.

>key generator and encryption would be duplicated from AH and ESP in
>Photuris, making it ever bigger.
>
Well, i don't know about Phil's implementation, but the size of mine is
dominated by the size of the math package (270k object code out of 420k
code of the final executable, non stripped). So i wouldn't overly worry
about the additional code size of the encryption algorithms (the version of
DES which i'm using is 4830 bytes object code, Phil's implementation).
Besides, the encryption code is there anyway; the additional code to handle
an anonymity transform in the SIGNATURE_MESSAGE would be like 10-20 lines (some
of which would be removed from the KEY_RESPONSE handling segment).

>I decided that it would be better to keep the Photuris anonymity code
>simpler, with only a few legal combinations of key generator and
>encryption.  Enough folks think it is excessive as it is.
>
Simpler in what sense? All the code anyone will need to add is already in there.
It's only a matter of changing the format of KEY_RESPONSE and SIGNATURE_MESSAGE
packets. I think that the same arguments that apply to the use of different
K-transforms for each direction apply in this case as well.
-Angelos

Xref subject previous

> From: "Angelos D. Keromytis" 
> The purpose of the anonymity transform is to hide the identity of the
> party sending the SIGNATURE_MESSAGE (hide the certificate) and either the
> Initiator or the Responder might want to remain anonymous. Trusting the
> Responder to select the algorithm when (in most cases) it is the Initiator
> that wishes to remain anonymous just doesn't sound good to me. And of course
> we might have an anonymous service provider, so we can't just let the
> Initiator pick the algorithm.
>
This is correct so far.  I just don't agree with the "either".  The
parties attempts anonymity, or they don't.  I don't see how a half
anonymous exchange _enhances_ security.


> This holds only as long as the privacy transform selected does not have
> any value fields (ie. is only 2 bytes). If, say, RC5 was selected, the
> alignment would be off anyway (assuming the signature and the certificate
> and the K-transform don't throw it off alignment anyway). Sorry, i don't
> think this is a strong argument.
>
Well, I do.  You will note that RC5 doesn't throw it off (count the bytes).


> >And after all, it seems to me that Photuris is getting over laden with
> >options.  What level of flexibility are we gaining by adding even more
> >for the simple rarely executed step of anonymity?  This combination of
>
> If we're going to do it, let's do it right.
>
I agree.  I just don't think that you are right.

When designing a protocol, I try to think of all the _possible_
enhancements, and then reduce to the minimum needed to get the job done!
That's "right".


> Simpler in what sense? All the code anyone will need to add is already in there.
> It's only a matter of changing the format of KEY_RESPONSE and SIGNATURE_MESSAGE
> packets. I think that the same arguments that apply to the use of different
> K-transforms for each direction apply in this case as well.
>
They don't.  That was the result of an argument of improved _security_,
not improved _flexibility_.  Too much "flexibility" leads to bad code,
and non-interoperability.

You didn't take the hint from my previous message, probably because the
saying is English.

Anyway, show how having separate encryption and key generator in each
direction of the signature exchange can improve security.

And, show how separating the IV (by the new fields) from the "opaque"
data will work on commonly available chips and software, which usually
expect them to be cheek by jowl.

Otherwise, let's give this a rest.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Photuris alignment  Bill Sommerfeld
Xref subject next

Date: Sun, 15 Oct 95 11:40:36 IDT

In the photuris-04 draft the exchange value (note : not the exchange value
length) in the key request and the key response messages is not aligned
to 32 bits boundary. As a result a 32-bit processor accessing this field
will always have non-aligned memory accesses. 

For efficiency reasons, wouldn't it be worth while, to pad the variable length 
fields, so that the next variable length field will always begin on an odd
16-bits boundary (i.e. the variable precision number will be 32-bits alligned).

Thanks,
  Sara.

Xref subject previous
Xref subject next

> In the photuris-04 draft the exchange value (note : not the exchange value
> length) in the key request and the key response messages is not aligned
> to 32 bits boundary. As a result a 32-bit processor accessing this field
> will always have non-aligned memory accesses.
>
True.  But, that field is a _bit_ field, so in this case I wasn't
terribly concerned.  Some part of it will usually be mis-aligned.  And
byte-by-byte access will probably be the rule.


> For efficiency reasons, wouldn't it be worth while, to pad the variable length
> fields, so that the next variable length field will always begin on an odd
> 16-bits boundary (i.e. the variable precision number will be 32-bits alligned).
>
These messages are executed so infrequently that it hardly matters.  The
ModExp calculations will swamp any minor alignment issues.

I made the TLV fields (in Attributes) self-aligned for their internal
values, since certain processors (68K) won't access 16 or 32 bit
quantities correctly if they are missing alignment, and you would have
to copy them out.  OTOH, for little-endian platforms, you have to do the
copy anyway.

But I don't know of any platform that handles 256-bit quantities yet (a
common size for the ME exchange-value), odd-sized variations (155 to
310-bits for EC), or variations even larger than that.

Since the TLV fields are almost always last in the packets, they will
self-align after the big variable precision numbers.

We could do some more tuning, I suppose.  Tradeoffs, always tradeoffs.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous

-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   Date: Sun, 15 Oct 95 11:40:36 IDT
   
   In the photuris-04 draft the exchange value (note : not the exchange value
   length) in the key request and the key response messages is not aligned
   to 32 bits boundary. As a result a 32-bit processor accessing this field
   will always have non-aligned memory accesses. 

   For efficiency reasons, wouldn't it be worth while, to pad the
   variable length fields, so that the next variable length field will
   always begin on an odd 16-bits boundary (i.e. the variable
   precision number will be 32-bits aligned).

I don't think it would be worth it.

Modular exponentiation takes on the order of millions of CPU cycles.
32-bit aligning everything would save roughly the cost of a few
byte-aligned copies of a few fields in the packet -- maybe a few
hundred cycles per photuris packet?  It's a drop in the bucket.

Photuris packet processing is not in the "fast path"; it is, however,
extremely security critical.  You want a simple, easy to understand
and easy to verify implementation, not an implementation with every
spare cycle bummed out of it.

					- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBMIKd1Vpj/0M1dMJ/AQFmNwP8DQJil1kSyPHm7NchjzsbPrpzH5RN+1zp
NFgfxqUiHGyseG2ffg++PGyrj89J7XhKaosWu0VXFS5E+fufIWWfSaU1QFRNxM2B
0STcXzVEsDzRHPxVoTr00kTcv3IZLvrKkP3TC07fzOJLWUSm4EiI048LFgidOGqS
Fv2GdxL4afQ=
=CQcj
-----END PGP SIGNATURE-----

Xref: Re: Photuris Primality verification needed Hilarie Orman
Xref: Re: Photuris Primality verification needed  Perry E. Metzger
Xref subject next

Folks, I was somewhat disappointed in the response to our previous
requests for verification of the strength of the prime moduli.

Recently, someone asked for a smaller prime of only 512-bits for speed.
This is more than enough for the strength of keys needed for DES, 3DES,
MD5 and SHA.  Perhaps this would be easier to have more complete and
robust verification as well.

Here are two "important" primes for Photuris use.  If you have some
spare cycles, it would be beneficial for in-depth verification of these
strong primes.

Implementation Optional.  A 512-bit strong prime (p), expressed in hex:

   da58 3c16 d985 2289 d0e4 af75 6f4c ca92
   dd4b e533 b804 fb0f ed94 ef9c 8a44 03ed
   5746 50d3 6999 db29 d776 276b a2d3 d412
   e218 f4dd 1e08 4cf6 d800 3e7c 4774 e833

The recommended generator (g) for this prime is 2.


Implementation Required.  A 1024-bit strong prime (p), expressed in hex:

   97f6 4261 cab5 05dd 2828 e13f 1d68 b6d3
   dbd0 f313 047f 40e8 56da 58cb 13b8 a1bf
   2b78 3a4c 6d59 d5f9 2afc 6cff 3d69 3f78
   b23d 4f31 60a9 502e 3efa f7ab 5e1a d5a6

   5e55 4313 828d a83b 9ff2 d941 dee9 5689
   fada ea09 36ad df19 71fe 635b 20af 4703
   6460 3c2d e059 f54b 650a d8fa 0cf7 0121
   c747 99d7 5871 32be 9b99 9bb9 b787 e8ab

The recommended generator (g) for this prime is 2.


> From: Phil Karn 
> I've used the mpz_probab_prime() function in the Gnu Math Package (GMP) version
> 1.3.2 to test this number. This function uses the Miller-Rabin primality test.
> However, to increase my confidence that this number really is a strong prime,
> I'd like to ask others to confirm it with other tests.
>

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

>  Recently, someone asked for a smaller prime of only 512-bits for speed.
>  This is more than enough for the strength of keys needed for DES, 3DES,
>  MD5 and SHA.  Perhaps this would be easier to have more complete and
>  robust verification as well.

Depending on what you think of the strength of those algorithms, the 512-bit
mod p system may not be strong enough.

The *strength* of 512-bit mod p DH systems is only about 56 bits.  You need
1024-bit primes for a *strength* of 80 bits.

In contrast, the 155-bit elliptic curve in the Photuris draft has a
strength of about 76 bits.

Xref: Re: Photuris Primality verification needed Brian A. LaMacchia
Xref subject previous
Xref subject next


"William Allen Simpson" writes:
> Folks, I was somewhat disappointed in the response to our previous
> requests for verification of the strength of the prime moduli.
> 
> Recently, someone asked for a smaller prime of only 512-bits for speed.
> This is more than enough for the strength of keys needed for DES, 3DES,
> MD5 and SHA.  Perhaps this would be easier to have more complete and
> robust verification as well.

I think that this is a very large mistake. Allow me to explain why.

La Macchia (sp?) and Odlyzko (sp?) have a very nice result which shows
that once you've done enough precalculation on a particular modulus,
you can break any subsequent Diffie-Hellman operation performed on
that modulus with (for our purposes) no effort. 512 bits is, from what
I can tell, not far out of the realm of possibility for what someone
could try to crack with current machines given enough effort.

[Sorry about the spelling. I'm tired, and don't have time to look up
your names. I know that Brian at least reads this list and I'm sorry
about likely misspelling your name.]

Perry

Xref subject previous
Xref subject next

   X-Authentication-Warning: jekyll.piermont.com: Host localhost didn't use HELO protocol
   Cc: cypherpunks@toad.com, ipsec-dev@eit.com
   Reply-To: perry@piermont.com
   X-Reposting-Policy: redistribute only with permission
   Date: Sun, 05 Nov 1995 11:07:25 -0500
   From: "Perry E. Metzger" 
   Sender: owner-cypherpunks@toad.com
   Precedence: bulk

   "William Allen Simpson" writes:
   > Folks, I was somewhat disappointed in the response to our previous
   > requests for verification of the strength of the prime moduli.
   > 
   > Recently, someone asked for a smaller prime of only 512-bits for speed.
   > This is more than enough for the strength of keys needed for DES, 3DES,
   > MD5 and SHA.  Perhaps this would be easier to have more complete and
   > robust verification as well.

   I think that this is a very large mistake. Allow me to explain why.

   La Macchia (sp?) and Odlyzko (sp?) have a very nice result which shows
   that once you've done enough precalculation on a particular modulus,
   you can break any subsequent Diffie-Hellman operation performed on
   that modulus with (for our purposes) no effort. 512 bits is, from what
   I can tell, not far out of the realm of possibility for what someone
   could try to crack with current machines given enough effort.

Perry is correct; allow me to add some details.  The discrete log
problem is "brittle": for a given prime modulus p you have to spend a
lot of effort to calculate the first discrete log modulo p, but
subsequent discrete logs modulo p are easy to find.  Basically, you (a)
do a lot of precomputation to compute discrete logs for a set of
small(-ish) primes, and then (b) you combine these to find the
particular discrete log you're interested in.  For the second (and
subsequent) discrete logs modulo p you only have to do part (b), which
is pretty easy.

Our practical experiences with discrete logs suggests that the effort
required to perform the discrete log precomputations in (a) is slightly
more difficult than factoring a composite of the same size in bits.  In
1990-91 we estimated that performing (a) for a k-bit prime modulus was
about as hard as factoring a k+32-bit composite.  [Recent factoring work
has probably changed this a bit, but it's still a good estimate.]

Finally, remember that if the modulus in your appliation is public and
fixed (as it usually is) then you've got a very tempting target for me
to attack.  Once I do the precomputations I can break/subvert/read any
particular D-H exchange I want for little additional effort.  You have
to consider the amount of effort someone might bring to bear against
your entire system, not only against a particular transaction.  Breaking
a particular 512-bit RSA key might not be worth the effort if it just
gets me your encrypted e-mail (or whatever), but a 512-bit D-H modulus
in a widely deployed system is ripe for attack.

See our paper (available from http://www-swiss.ai.mit.edu/~bal/) for all
the juicy details.

					--bal

Xref: Re: Photuris Primality verification needed  Perry E. Metzger
Xref: Re: Photuris Primality verification needed Phil Karn
Xref: Re: Photuris Primality verification needed Phil Karn
Xref subject previous
Xref subject next

> From: "Brian A. LaMacchia" 
>    > Recently, someone asked for a smaller prime of only 512-bits for speed.
>    > This is more than enough for the strength of keys needed for DES, 3DES,
>    > MD5 and SHA.  Perhaps this would be easier to have more complete and
>    > robust verification as well.
>
> Our practical experiences with discrete logs suggests that the effort
> required to perform the discrete log precomputations in (a) is slightly
> more difficult than factoring a composite of the same size in bits.  In
> 1990-91 we estimated that performing (a) for a k-bit prime modulus was
> about as hard as factoring a k+32-bit composite.  [Recent factoring work
> has probably changed this a bit, but it's still a good estimate.]
>
Thanks.  I have added the [from Schneier] estimate

   e ** ((ln p)**1/2 * (ln (ln p))**1/2)

and number field sieve estimate

   e ** ((ln p)**1/3 * (ln (ln p))**2/3)

to the Photuris draft, with a small amount of explanation.

Hilarie Orman posted that 512-bits only gives an order of 56-bits
strength, 1024-bits yeilds 80-bits strength, and 2048 yields 112-bits
strength.  I do not have the facilities to verify her numbers.

As most of us agree that 56-bits is not enough (DES), the 512-bit prime
seems a waste of time and a tempting target.  I'd like to drop it, but
Phil is inclined to keep it with a disclaimer.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

I wish to roundly thank all those that responded to our need for
verification.  We had several excellent responses.  The primes have now
been better verified using Miller-Rabin with different platforms, and
with separately coded math libraries.  More exhaustive testing is
ongoing.

Thanks are due to Wei Dai and Frank A Stevenson, as well as independent
math libraries by Rich Schroeppel and Eric Young.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next


"William Allen Simpson" writes:
> As most of us agree that 56-bits is not enough (DES), the 512-bit prime
> seems a waste of time and a tempting target.  I'd like to drop it, but
> Phil is inclined to keep it with a disclaimer.

I agree with your approach, Bill -- it seems worth dropping. Something
this dangerous isn't worth leaving around for people to accidently
use.

Perry

Xref: Re: Photuris Primality verification needed Brian A. LaMacchia
Xref subject previous
Xref subject next

> Our practical experiences with discrete logs suggests that the effort
> required to perform the discrete log precomputations in (a) is slightly
> more difficult than factoring a composite of the same size in bits.  In
> 1990-91 we estimated that performing (a) for a k-bit prime modulus was
> about as hard as factoring a k+32-bit composite.  [Recent factoring work
> has probably changed this a bit, but it's still a good estimate.]

This is also my understanding, which I got from you in the first
place.  I take it there have been no dramatic breakthroughs in the
last few years in the discrete log problem? How heavily has it been
studied in comparison with factoring?

Yes, in theory once an attacker spends enough time precomputing a
table for a particular modulus he can then attack individual DH key
exchanges with ease. This seems entirely analogous to attacking
RSA. If you spend the time up front to factor my public RSA key, then
you can also easily attack individual messages to me.

So if I am willing to rely on a PGP key of, say, 1024 bits then I
should be equally willing to rely on a 1024-bit DH modulus.

Now there is admittedly a practical difference here -- people *can*
change their PGP RSA keys occasionally, though this is hard to do when
you have a lot of signatures.  And each user has his/her own PGP RSA
key, and cracking that gives you only the traffic to that user.  A
public DH modulus will be shared by many more people -- making it a
much more tempting target.

Still, requiring support of a fixed modulus for shared public use is
important to promote a basic level of interoperability. This has its
risks, but it should be okay *provided* it's a strong prime of
sufficient strength to preclude the precomputation of the discrete log
tables by even a highly motivated and resourceful attacker. And as a
backup the protocol should provide for the optional use of private
moduli between consenting parties. Sound reasonable?

Phil

Xref: Re: Photuris Primality verification needed Hilarie Orman
Xref: Re: Photuris Primality verification needed Tatu Ylonen
Xref subject previous
Xref subject next

>Hilarie Orman posted that 512-bits only gives an order of 56-bits
>strength, 1024-bits yeilds 80-bits strength, and 2048 yields 112-bits
>strength.  I do not have the facilities to verify her numbers.

>As most of us agree that 56-bits is not enough (DES), the 512-bit prime
>seems a waste of time and a tempting target.  I'd like to drop it, but
>Phil is inclined to keep it with a disclaimer.

Well, since we already require 56-bit DES in ESP in the interests of
promoting basic interoperability, wouldn't a 512-bit prime be
similarly sufficient?

Again, I'm *not* going to recommend that people use it, only provide it
for those who simply cannot use larger moduli for whatever reason (export
controls or CPU limits).

Phil

Xref subject previous
Xref subject next

>  Well, since we already require 56-bit DES in ESP in the interests of
>  promoting basic interoperability, wouldn't a 512-bit prime be
>  similarly sufficient?

If you are willing to accept that in all likelihood, one year from
now, some group will announce that can "crack" all key exchanges that
using the published modulus, then sure, call it sufficient.  There is
certainly precedent; it was my understanding that Sun did not change
their SecureRPC modulus when informed of LaMacchia and Odlyzko's work.

Xref: Re: Interop Phil Karn
Xref: Re: Interop  Perry E. Metzger
Xref subject next

Will anyone have a working implementation of Photuris based on draft 6 before
the meeting for interoperability testing ?
-Angelos

Xref subject previous
Xref subject next

>Will anyone have a working implementation of Photuris based on draft 6 before
>the meeting for interoperability testing ?

I'm working on it under NOS...we'll see...

Phil

Xref: Re: Interop  Angelos D. Keromytis
Xref subject previous
Xref subject next


"Angelos D. Keromytis" writes:
> Will anyone have a working implementation of Photuris based on draft 6 before
> the meeting for interoperability testing ?

An interesting question -- it would be a good thing for people to do.

Who is currently working on implementation?

.pm

Xref: Re: Interop  Hilarie Orman
Xref subject previous
Xref subject next

In message <199511081517.KAA00354@jekyll.piermont.com>, "Perry E. Metzger" writ
es:
>
>An interesting question -- it would be a good thing for people to do.
>
>Who is currently working on implementation?
>
Actually, i don't have a complete working implementation for Draft 6 yet,
mainly because there's no pressure to have one; i can easily have it ready
for the meeting if there's someone i can do testing with. Otherwise it'll be
ready sometime late December.
-Angelos

Xref subject previous
Xref subject next

   Date: Tue, 7 Nov 1995 17:43:49 -0800 (PST)
   From: Phil Karn 
   Cc: cypherpunks@toad.com, ipsec-dev@eit.COM

   > Our practical experiences with discrete logs suggests that the effort
   > required to perform the discrete log precomputations in (a) is slightly
   > more difficult than factoring a composite of the same size in bits.  In
   > 1990-91 we estimated that performing (a) for a k-bit prime modulus was
   > about as hard as factoring a k+32-bit composite.  [Recent factoring work
   > has probably changed this a bit, but it's still a good estimate.]

   This is also my understanding, which I got from you in the first
   place.  I take it there have been no dramatic breakthroughs in the
   last few years in the discrete log problem? How heavily has it been
   studied in comparison with factoring?

Factoring has received more attention than discrete log; certainly when
it comes to net-wide computations it's all factoring.  But that's partly
due, I think, to a lack of targets to attack.  

   Still, requiring support of a fixed modulus for shared public use is
   important to promote a basic level of interoperability. This has its
   risks, but it should be okay *provided* it's a strong prime of
   sufficient strength to preclude the precomputation of the discrete log
   tables by even a highly motivated and resourceful attacker. And as a
   backup the protocol should provide for the optional use of private
   moduli between consenting parties. Sound reasonable?

You definitely should allow any modulus between consenting parties.  As
for what moduli the standard says "must be" (vs. "should be") supported,
I don't know.  Maybe the right thing to do is require conforming
implementations to support a large modulus but include recommended
smaller moduli.  Then Alice can always force Bob to use the large
modulus but, if both agree, they can use something smaller from the
standard or even their own home-grown modulus.

					--bal

Xref: Re: Photuris Primality verification needed Phil Karn
Xref subject previous
Xref subject next

> Well, since we already require 56-bit DES in ESP in the interests of
> promoting basic interoperability, wouldn't a 512-bit prime be
> similarly sufficient?

*NO*, because you have to break the 56-bit DES separately every time,
whereas doing the precomputation for the 512 bit prime is a one-time
job.  Once anyone has done the precomputation, *all* communications
will be open to whoever is in possession of the database.

I think there is good reason to believe that if the 512 bit prime is
allowed, it will be widely used, and even if it is found breakable, it
will not be easily changed (just think about the experience with Sun's
"secure" rpc, and how quickly their primes have been changed - and it
still has much narrower deployment than what is hoped for ipsec).

Let me include below a message I sent to Bill Simpson.  

> If it is kept, the commercial vendors will probably start using it
> as default because it is faster than the others, and the state
> department will pressure them to do so.  Then we are again left with
> too weak aprotections (in other words, pseudo-security which makes
> people believe they have protection, when they actually don't).
> After the precomputation, it is apparently cheap enough to crack the
> exchange that it can be done on a mass scale to all exchanges
> between a very large number of hosts.  I find this very harmful, as
> it again provides no protection against mass surveillance.  We are
> already too close to an Orwellian society.

The remarks there apply equally well to organized criminals, large
corporations, and hostile governments.  Or, suppose some group manages
to get access to enough idle time, computes the database, and posts it
on the Internet.  I for one would be willing to contribute CPU time on
machines where I have access to help such a group, because I think it
is better that it is widely known and publicized when there is little
security and privacy.

Including the provision for the 512 bit prime is *HARMFUL* and
*DANGEROUS*.  Export control is not really an issue here, because if
companies in the United States cannot provide secure networking,
there are other companies in the world that can.

    Tatu Ylonen 

Xref subject previous
Xref subject next

We might have a minimal implementation (no change messages, simple MD5
"signatures" with preset keys, takes first available algorithm and it
better be MD5 or DES), we'll see.

Xref: Re: Interop Phil Karn
Xref: Re: Interop Phil Karn
Xref subject previous
Xref subject next

At the San Jose IPSEC WG meeting, the group discussed having an ESP/AH bake off
at the Dallas IETF. Although I do not think this will occur in the official sense,
I would like to know if anyone is interested in bringing their design to Dallas.
We could try two tests. We could connect some laptops together. We could also
connect them in the terminal and communicate with our respective test sites.
It can be argued that manual keying is trivial, but I believe that this
demonstration is still needed. I am sure the tests will be much more
complicated than I describe too.

We plan to demonstrate our ESP/AH prototype at Dallas and would prefer to test
with others. To do this, I would want to test with you before then. If you are
interested in arranging some tests, please contact me. 

I have included this message to ipsec mailing list for those who may be interested
in seeing the demonstrations. I expect them to be informative and not very colorful.
I also expect most queries from the developer's list.

Regards
-Mike Oehler

Xref subject previous
Xref subject next

At the San Jose IPSEC WG meeting, the group discussed having an ESP/AH bake off
at the Dallas IETF. Although I do not think this will occur in the official sense,
I would like to know if anyone is interested in bringing their design to Dallas.
We could try two tests. We could connect some laptops together. We could also
connect them in the terminal and communicate with our respective test sites.
It can be argued that manual keying is trivial, but I believe that this
demonstration is still needed. I am sure the tests will be much more
complicated than I describe too.

We plan to demonstrate our ESP/AH prototype at Dallas and would prefer to test
with others. To do this, I would want to test with you before then. If you are
interested in arranging some tests, please contact me. 

I have included this message to ipsec mailing list for those who may be interested
in seeing the demonstrations. I expect them to be informative and not very colorful.
I also expect most queries from the developer's list.

Regards
-Mike Oehler

Xref subject previous
Xref subject next

> From: "Angelos D. Keromytis" 
> >Who is currently working on implementation?
> >
> Actually, i don't have a complete working implementation for Draft 6 yet,
> mainly because there's no pressure to have one; i can easily have it ready
> for the meeting if there's someone i can do testing with. Otherwise it'll be
> ready sometime late December.
>
Ah, how about being ready Monday of next week?

Do you have AH and ESP running?

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref subject previous
Xref subject next

> From: mjo@tycho.ncsc.mil (Michael J. Oehler)
> At the San Jose IPSEC WG meeting, the group discussed having an ESP/AH bake off
> at the Dallas IETF. Although I do not think this will occur in the official sense,
> I would like to know if anyone is interested in bringing their design to Dallas.

There will be a whole room full of implementations.


> We could try two tests. We could connect some laptops together. We could also
> connect them in the terminal and communicate with our respective test sites.

Yep.  That's the plan.  Also, it is my understanding that RSA will have
a suite upstairs with firewall vendors.


> We plan to demonstrate our ESP/AH prototype at Dallas and would prefer to test
> with others. To do this, I would want to test with you before then. If you are
> interested in arranging some tests, please contact me.
>
Send email to karl@morningstar.com for manual keys to test ping.

Everyone (so far) is testing against morningstar; they were first, and
have been shipping since July.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2

Xref: Re: Photuris Primality verification needed Adam Shostack
Xref: Re: Photuris Primality verification needed  Perry E. Metzger
Xref: Re: Photuris Primality verification needed Andreas Bogk
Xref subject previous
Xref subject next

>I don't know.  Maybe the right thing to do is require conforming
>implementations to support a large modulus but include recommended
>smaller moduli.  Then Alice can always force Bob to use the large
>modulus but, if both agree, they can use something smaller from the
>standard or even their own home-grown modulus.

Thanks. That's pretty much what we are doing -- requiring a particular
1024-bit modulus but recommending several others as options. There's a
2048 bit optional modulus and may even be a 4096-bit option if I can
find one in reasonable time. There was going to be a 512-bit optional
modulus but the group has reacted so strongly to it that I'm willing to
withdraw it.

Phil

Xref subject previous
Xref subject next

>Including the provision for the 512 bit prime is *HARMFUL* and
>*DANGEROUS*.  Export control is not really an issue here, because if
>companies in the United States cannot provide secure networking,
>there are other companies in the world that can.

You've convinced me. I remove my proposal to include a recommended 512-bit
modulus. The smallest standard modulus will remain 1024-bits.

Phil

Xref: Re: Photuris Primality verification needed Phil Karn
Xref subject previous
Xref subject next

You might want to offer a number of strong moduli in the 1024-1500 bit
range.  Having multiple strong moduli in the same size (speed) range
reduces the value of going after a particular one.  We all know how
security software tends to stay deployed longer than it really should.

Adam

Phil Karn wrote:

| Thanks. That's pretty much what we are doing -- requiring a particular
| 1024-bit modulus but recommending several others as options. There's a
| 2048 bit optional modulus and may even be a 4096-bit option if I can
| find one in reasonable time. There was going to be a 512-bit optional
| modulus but the group has reacted so strongly to it that I'm willing to
| withdraw it.

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Xref subject previous
Xref subject next

I plan to have my ESP/AH implementation in hand at Dallas, so I'd like to
participate. It's part of my KA9Q NOS implementation that runs under DOS,
so we can run it on my laptop.

Phil

Xref subject previous
Xref subject next

I plan to have my ESP/AH implementation in hand at Dallas, so I'd like to
participate. It's part of my KA9Q NOS implementation that runs under DOS,
so we can run it on my laptop.

Phil

Xref subject previous
Xref subject next

>You might want to offer a number of strong moduli in the 1024-1500 bit
>range.  Having multiple strong moduli in the same size (speed) range

We already have a secondary 1024-bit modulus in the spec. The question is
whether the problem is better solved by allowing parties to use private
moduli rather than by filling up the spec with additional moduli. Remember
that the original reason for specifying a particular modulus as "required"
is to guarantee some minimum degree of interoperability, not to meet every
possible threat.

Phil

Xref subject previous
Xref subject next

In message <4563.bsimpson@morningstar.com>, "William Allen Simpson" writes:
>Ah, how about being ready Monday of next week?
>
I can be ready by then.

>Do you have AH and ESP running?
>
Getting there.
-Angelos

Xref: Re: Photuris Primality verification needed Phil Karn
Xref subject previous
Xref subject next

At 07:47 PM 11/8/95 -0800, you wrote:
>>Including the provision for the 512 bit prime is *HARMFUL* and
>>*DANGEROUS*.  Export control is not really an issue here, because if
>>companies in the United States cannot provide secure networking,
>>there are other companies in the world that can.
>
>You've convinced me. I remove my proposal to include a recommended 512-bit
>modulus. The smallest standard modulus will remain 1024-bits.

If speed is really a concern, you could do a 640 or 768 bit modulus
("Hey, back when we wrote that, everybody assumed 640 would be enough for
everybody!"), or alternatively, let people use 512-bit private modulus values -
they're still short, but they're not a target if everybody's got their own
(which also means that popular applications shouldn't ship with a
built-in 512-bit prime; if Windows 97 did that, it'd be about the same
as putting it in the spec, so really short primes should probably require
user-generation, which may contradict the desire to use short numbers
to save time.)

One question is how to conveniently let the standard offer negotiation for
the modulus length and value without adding a lot of handshake steps
        -> WILL MODLENGTH 512PRIV 768 1024 1024ALT 2048
        <- DO MODLENGTH 512PRIV
        -> WILL MODULUS
8758432798573409875098347509834750983745098348584395984357908347509843750984
3750983
        <- 404 HEY, THAT'S NOT A STRONG PRIME!



#--
#				Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

Xref subject previous
Xref subject next

At 04:06 PM 11/8/95 EST, Michael J. Oehler wrote:
>
>I have included this message to ipsec mailing list for those who may be
interested
>in seeing the demonstrations. I expect them to be informative and not very
colorful.
>I also expect most queries from the developer's list.

I want to see the demonstrations.  Please inform the list as to the when and
where.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous

At 04:06 PM 11/8/95 EST, Michael J. Oehler wrote:
>
>I have included this message to ipsec mailing list for those who may be
interested
>in seeing the demonstrations. I expect them to be informative and not very
colorful.
>I also expect most queries from the developer's list.

I want to see the demonstrations.  Please inform the list as to the when and
where.

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

Xref subject previous
Xref subject next


Phil Karn writes:
> >I don't know.  Maybe the right thing to do is require conforming
> >implementations to support a large modulus but include recommended
> >smaller moduli.  Then Alice can always force Bob to use the large
> >modulus but, if both agree, they can use something smaller from the
> >standard or even their own home-grown modulus.
> 
> Thanks. That's pretty much what we are doing -- requiring a particular
> 1024-bit modulus but recommending several others as options.

I think Brian is also suggesting that it would be good if people could
negotiate new and previously unheard of modulii if they wanted to.

Perry

Xref subject previous
Xref subject next

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Phil" == Phil Karn  writes:

    Phil> as options. There's a 2048 bit optional modulus and may even
    Phil> be a 4096-bit option if I can find one in reasonable
    Phil> time. There was going to be a 512-bit optional modulus but

I'd like to see the 4096 bit modulus. Let me know if I can help you by
donating computation power. We have a SGI Onyx with 4 processors and
several smaller SGI computers.

Andreas


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBMKIUdEyjTSyISdw9AQGEawP9FUG9X5t8n/w0BRcWVTPv6LeERgY78WHc
mBNG4ScvbRZK6o4ZoQuEr10v4eDqKQtHD3lkdV5HJO2+oBrNkLOLKyVR8sr0Yh+3
wKyOeF8BUKqwILteJGT8UQnznFnHha0m9HxlHOIUrx6SOGIMc6t6N4DFCRzOis0h
dc0pgYN2S/Y=
=QKwE
-----END PGP SIGNATURE-----

Xref subject previous

>If speed is really a concern, you could do a 640 or 768 bit modulus

Hilarie suggested exactly this in private mail, and I've agreed. I'm
going to generate a 768-bit optional modulus.

Bill has also suggested a killer 4096-bit modulus for the truly
paranoid. Not sure my poor 32MB P90 can handle that without thrashing
its guts out, but I'll give it a try.

Phil